Semantics
Model your organization's business domain as a shared ontology of concepts and relationships, and link those concepts to the data products and data contracts that implement them.
Semantics gives you a single place to define what an Order, a Customer, or Monthly Recurring Revenue actually means in your organization, independent of any particular system or schema. Once a concept is defined, every data contract field that represents that concept can link to it. This makes data discoverable by meaning (not just by table name), keeps definitions consistent across teams, and powers semantic search and AI-driven querying.
Semantics replaces Business Definitions. If you are currently using business definitions, plan to migrate them to semantic concepts. Business definitions remain available through the API for backwards compatibility, but new work should use Semantics.

Enable Semantics
Semantics is disabled by default and controlled per installation via a feature flag.
- Entropy Data Cloud: contact support to enable Semantics for your organization.
- Self-Hosted: set the environment variable
APPLICATION_SEMANTICS_ENABLED=true(equivalent property:application.semantics.enabled=true) and restart the application.
When the feature is enabled, a Semantics entry appears in the marketplace and studio navigation.
Quickstart: Import an Industry Standard
To get started fast, open Studio > Semantics and use the Add > Import Industry Standard action. Entropy Data ships with ready-to-import ontologies for several industries:
- GoodRelations (E-Commerce)
- FIBO (Finance)
- EBU Core Plus (Media)
- CGMES (Energy)
- IDMP (Pharma)
- EPCIS (Supply Chain)
- IATA ONE Record (Air Cargo)
- TM Forum SID (Telco)
You can also upload your own RDF/OWL files (Turtle, OWL, RDF/XML, N-Triples, N3, JSON-LD).
Semantic Concepts
A semantic concept is a named, reusable definition of something that exists in your business domain. Each concept lives in a namespace (the default is main), has a stable external ID, a human-readable name, a description, and an IRI that allows it to be referenced from RDF tools.
Concepts come in four kinds:
- Entity: A real-world thing your business cares about. Examples: Customer, Order, Article, Invoice. Entities are the nouns of your domain.
- Shared Property: A reusable attribute with a primitive data type that can be attached to one or more entities. Examples: Email Address, Order Status, SKU, IBAN. Shared properties are the right choice when the same definition is reused across multiple entities and you want a single source of truth for it.
- Metric: A measurable, often aggregated quantity used to track business performance. Metrics carry additional attributes such as a unit (e.g.
EUR,count), a "better when" direction (higher,lower), and an optional formula. Examples: Monthly Recurring Revenue, Active Users, Order Conversion Rate. - Group: A container used to organize concepts into logical sets, for example by domain, subject area, or initiative. Groups have no schema of their own; they exist purely for navigation and filtering.
In addition to shared properties, an entity can declare inline properties directly on itself. Inline properties are attributes that are not meant to be reused outside the parent entity (for example a one-off internal_note field on Customer). They are shown on the entity's detail page rather than as standalone entries in the concept list.
Each concept can also carry extended metadata: data type, classification (e.g. PII), required/unique flags, examples, allowed enum values, regex patterns, and free-form tags.

Relationships
Concepts gain meaning through their relationships with other concepts. A relationship is a directed, typed edge from a source concept to a target concept.
Common relationship types:
- hasProperty: An entity has a particular property or shared property. Customer hasProperty Email Address.
- isA: A specialization or inheritance relationship. Premium Customer isA Customer.
- memberOf: A concept belongs to a group. Customer memberOf Sales Group.
- measures: A metric measures an entity or another concept. Monthly Recurring Revenue measures Subscription.
- derived_from: A concept (typically a metric) is derived from one or more other concepts via a formula.
- relatedTo: A generic association used when no more specific type applies.
Relationships are visible on the detail page of every concept, split into outgoing and incoming edges, so you can navigate the ontology in either direction.
Diagram View
In addition to the searchable list view, Semantics provides a Diagram view that renders the concepts and their relationships as an interactive graph. Use the List / Diagram toggle at the top of the namespace page to switch.
The diagram is useful for:
- Getting an overview of how an area of the domain is structured.
- Spotting concepts that have no relationships yet (orphans).
- Communicating the model to stakeholders without exposing them to YAML.
You can pan, zoom, and click any node to jump to the corresponding concept's detail page.

Connect Data Products and Data Contracts to Concepts
Concepts only become useful when the data that implements them is linked back to them. Entropy Data uses authoritative definitions to express these links.
You can link a concept at three levels:
- Data product (in the ODPS specification): the data product as a whole represents the concept.
- Data contract (root or per-schema-object): the contract or one of its tables/models represents the concept.
- Field / property (inside a data contract schema): a specific column represents the concept.
Linking from the Data Contract Editor
Open a data contract and go to the Schemas tab. On every schema object and every property, use the Add from Definition button to open the Find Definition picker:

The picker lets you browse all namespaces and concepts, search by name, and pick the right element. Selecting a concept inserts an authoritativeDefinitions entry pointing to the concept's IRI, and the link becomes visible (and clickable) on the data contract page.
YAML Example
The same link can be added by editing the data contract YAML directly:
description:
authoritativeDefinitions:
- type: semantics
url: https://app.entropy-data.com/<org>/semantics/main/customer
schema:
- name: CUSTOMERS
type: table
authoritativeDefinitions:
- type: semantics
url: https://app.entropy-data.com/<org>/semantics/main/customer
properties:
- name: EMAIL
logicalType: string
authoritativeDefinitions:
- type: semantics
url: https://app.entropy-data.com/<org>/semantics/main/email-address
The type: semantics marker tells Entropy Data that the URL points to a semantic concept and should be resolved (and rendered) accordingly.
Linking from a Data Product (ODPS)
In a data product that uses the Open Data Product Standard, attach authoritativeDefinitions to the data product itself or to any output port:
authoritativeDefinitions:
- type: semantics
url: https://app.entropy-data.com/<org>/semantics/main/customer-360
Reverse Lookup
On every concept's detail page, Entropy Data shows all data products and data contracts that link to that concept. This makes it easy to answer questions like "which datasets contain customer email addresses?" or "who owns the source of truth for our MRR metric?"
Editing Concepts as YAML
The whole namespace can be edited as a single YAML file via the YAML Editor action on the namespace page. This is convenient for bulk edits, code review, and storing the ontology in Git. Individual concepts also have a per-concept YAML editor.
For a programmatic interface, use the SPARQL endpoint at /api/semantics/sparql or the experimental REST API under /api/semantics/experimental/.