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.

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), a required flag, 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:

1. Data product (in the ODPS specification): the data product as a whole represents the concept.
2. Data contract (root or per-schema-object): the contract or one of its tables/models represents the concept.
3. 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.

Suggest Semantics for All Properties (AI)

Instead of linking each property by hand, you can let Entropy Data analyze an entire data contract and propose a semantic concept for every unlinked property in one pass.

From a data contract, choose Suggest semantics for all properties. A short wizard first asks which namespaces (vocabularies) the suggestions should draw from — all are selected by default; narrow the selection to keep recommendations from mixing concepts across unrelated ontologies. Entropy Data then starts a background analysis and opens a review screen listing every property, grouped by schema object. As the analysis runs, each row fills in with its suggested concept and a short reason, or is marked as having no confident match.

Each property is presented the same way as on the data contract's schema — business name, technical name, type, and description — so the list reads familiarly. Properties that are already linked to a concept are shown too, as read-only context, so you review the whole contract rather than only the gaps; a toggle hides them when you want to focus on the unlinked ones.

On the review screen you can:

• select or deselect individual suggestions,
• open any linked or suggested concept to see its full details in a side panel,
• replace a suggested concept with a different one — or create a new concept (an entity, or a property under an existing entity) from the same picker, for a property that has no good match yet.

Applying your selection links all chosen concepts in a single save: one new contract version and one audit entry for the whole batch, rather than one per property. Applying suggestions requires edit permission on the contract.

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/.