Feature

Semantik: Business mit Datenprodukten verbinden

Jochen Christ

Co-Founder & CTO, Entropy Data · 2026-04-16

Ein Schema sagt dir, wie Daten gespeichert sind. Ein Semantic Layer sagt dir, was sie bedeuten. Diese Seite erklärt, was ein Semantic Layer ist, wie die Semantik-Funktion von Entropy Data ihn modelliert und wie die entstehende Ontologie mit Datenprodukten und Data Contracts verbunden ist.

Das Problem

Die meisten Datenplattformen können dir gut sagen, in welcher Tabelle, in welcher Spalte und in welchem Typ Daten liegen. Schlechter beantworten sie die Frage, was das alles bedeutet. Die Fragen, die Teams ausbremsen, gehören meist zur zweiten Sorte:

• Drei Teams haben eine Spalte customer_id. Beziehen sie sich auf dieselben Kunden? Sind Gast-Checkouts enthalten?
• Finance und Product melden beide Gross Merchandise Value. Die Zahlen stimmen nicht überein. Welche Formel ist verbindlich?
• Eine neue Analystin braucht Sendungsverfolgungsdaten. Die Suche nach „Shipment“ über ein Dutzend Schemata liefert vierzig Spalten. Welche davon sind kanonisch?

Das sind semantische Probleme, keine Schema-Probleme, und sie skalieren schlecht, wenn die Zahl der Datenprodukte, Teams und KI-Tools wächst.

Was ein Semantic Layer ist

Ein Semantic Layer ist eine benannte, gesteuerte Definition deiner Domäne, unabhängig von einer konkreten Tabelle oder einem System. Er besteht aus zwei Hauptelementen:

• Konzepte: die Dinge in deinem Business, also Entitäten, Properties und Metriken.
• Beziehungen: wie diese Konzepte miteinander und mit Data-Contract-Feldern verbunden sind.

Konzepte

Jedes Konzept hat eine stabile ID, einen menschenlesbaren Namen, eine Beschreibung und eine IRI, damit es aus externen Tools referenziert werden kann. Das Konzept Editorial Object aus EBU Core Plus hat zum Beispiel die IRI:

http://www.ebu.ch/metadata/ontologies/ebucoreplus#EditorialObject

Konzepte leben in Namespaces (Standard ist main) und gibt es in vier Ausprägungen:

• Entity (EntityType): die Substantive deiner Domäne. Customer, Order, Article, Shipment.
• Property (ValueType): ein Attribut mit einem primitiven Typ. Mit shared: true markiert wird es zu einer wiederverwendbaren Shared Property, die an eine oder mehrere Entitäten gehängt wird: Customer Email, SKU, Order ID. Einmal definiert, an mehreren Stellen referenziert.
• Metric (MetricType): eine messbare Größe mit Einheit, einer „Better-When“-Richtung und einer optionalen Formel. Gross Merchandise Value, Conversion Rate, Order Fulfillment Time.
• Group (GroupType): ein Container, um Konzepte nach Domäne oder Themengebiet zu organisieren. Sales, Fulfillment, Catalog, Controlling.

Konzepte tragen die Metadaten, auf die Governance und KI-Tooling angewiesen sind: Datentyp, Klassifizierung (zum Beispiel PII, sensitiv, restricted), Required- und Unique-Flags, Beispiele, Enums, Regex-Patterns, mehrsprachige Namen und Beschreibungen sowie Tags.

Konzepte als YAML

Die vollständige Ontologie kann als YAML bearbeitet werden, praktisch für Bulk-Edits, Code Review und um die Ontologie in Git zu halten. Einzelne Konzepte haben außerdem einen Pro-Konzept-YAML-Editor. Das Format folgt der Ontology-Spezifikation von Apache Ossie. Ein Auszug aus der Retail-Demo-Ontologie:

version: 0.2.0.dev0
name: main
ontology:
  - concept: Order
    id: order
    type: EntityType
    group: Sales
    description: A confirmed purchase placed by a customer in the online shop.
    custom_properties:
      owl:equivalentClass: http://schema.org/Order
    relationships:
      - name: order_id
        type: hasProperty
        roles:
          - concept: Order ID
      - name: customer_id
        type: hasProperty
        roles:
          - concept: Customer ID
      - name: order_status
        type: hasProperty
        roles:
          - concept: order_status
      - name: currency
        type: hasProperty
        roles:
          - concept: currency
  - concept: order_status
    id: order.order-status
    type: ValueType
    extends:
      - String
    description: Lifecycle state of the order.
    enum: [pending, confirmed, shipped, delivered, cancelled, returned]
  - concept: currency
    id: order.currency
    type: ValueType
    extends:
      - String
    description: ISO 4217 currency code of the order total.
    pattern: ^[A-Z]{3}$
    examples: [EUR, USD]

Drei Details lohnen einen Hinweis. Eine Entität referenziert ihre Properties über hasProperty-Beziehungen: Order ID und Customer ID sind Shared Properties, einmal mit shared: true definiert und über Entitäten hinweg wiederverwendet, während order_status und currency Properties der Bestellung sind, jede als eigene ValueType-Komponente. Eine Property drückt ihren Datentyp aus, indem sie einen eingebauten Value Type wie String, Decimal oder DateTime erweitert. Und der Eintrag owl:equivalentClass in custom_properties richtet das Konzept an einer externen Ontologie aus (in diesem Fall schema.org). So bleibt das interne Modell mit Standards wie GoodRelations oder FIBO interoperabel.

Metriken mit Formeln

Eine Metrik hält ihre Einheit fest, die Richtung, in die sie sich verbessert, und wie sie berechnet wird. Damit haben Finance, Product und KI-Tools eine einzige Definition, auf die sie sich einigen können.

ontology:
  - concept: Gross Merchandise Value
    id: gmv
    type: MetricType
    group: Controlling
    description: Total value of all placed orders before refunds, returns, and discounts.
    unit: EUR
    better_when: higher
    formula: "SUM(order.total_amount)"

  - concept: Average Order Value
    id: average_order_value
    type: MetricType
    group: Sales
    unit: EUR
    better_when: higher
    formula: "SUM(order.total_amount) / COUNT(DISTINCT order.id)"

Beziehungen

Konzepte sind über gerichtete, typisierte Beziehungen miteinander verbunden. Häufige Typen sind hasProperty, relatedTo, measures und derived_from; Subtypen werden über extends ausgedrückt. Eine Beziehung wird an dem Konzept definiert, das ihre erste Rolle spielt, dieses Konzept ist also implizit: roles listet nur die übrigen Beteiligten, und verbalizes enthält natürlichsprachliche Muster, die KI-Agenten nutzen können.

ontology:
  - concept: Customer
    relationships:
      - id: customer_places_order
        name: places
        type: relatedTo
        roles:
          - concept: Order
        multiplicity: OneToMany
        verbalizes:
          - "{Customer} places {Order}"

  - concept: Average Order Value
    relationships:
      - id: aov_derived_from_gmv
        name: derived_from
        type: derived_from
        roles:
          - concept: Gross Merchandise Value
        verbalizes:
          - "{Average Order Value} derived from {Gross Merchandise Value}"

Jede Konzeptseite zeigt eingehende und ausgehende Kanten, sodass du durch die Ontologie in beide Richtungen navigieren kannst. Die Diagrammansicht oben auf dieser Seite rendert denselben Namespace als interaktiven Graphen, mit Pan, Zoom und Click-Through von jedem Knoten zur Konzeptseite.

Übersetzungen in mehreren Sprachen

Jedes Konzept, jede Property und jede Beziehung kann Übersetzungen ihres Namens und ihrer Beschreibung in beliebig vielen Sprachen tragen. Übersetzungen werden als sprachgetaggte custom_properties-Einträge wie name@de oder description@fr gespeichert, über den SPARQL-Endpoint exponiert und in der UI je nach Spracheinstellung des Users angezeigt. Eine einzige Ontologie kann englischsprachige Analysten, französischsprachige Product Manager und deutschsprachige Auditoren aus derselben Quelle bedienen.

ontology:
  - concept: Customer
    id: customer
    type: EntityType
    group: Customers
    description: A natural person who places orders in the online shop.
    custom_properties:
      name@de: Kunde
      name@fr: Client
      description@de: Eine natürliche Person, die Bestellungen im Online-Shop aufgibt.
      description@fr: Une personne physique qui passe des commandes dans la boutique en ligne.

Die Industrieontologien, die Entropy Data mitliefert, sind out of the box übersetzt. EBU Core Plus zum Beispiel kommt mit englischen, deutschen und französischen Labels und Beschreibungen für jede Klasse und Property.

Datenprodukte und Data Contracts verknüpfen

Ein Semantic Layer ist nur dann nützlich, wenn die Daten, die ihn implementieren, auf ihn zurückverweisen. Entropy Data nutzt den Mechanismus authoritativeDefinitions aus dem Open Data Contract Standard, um Konzepte auf drei Ebenen mit den implementierenden Daten zu verbinden:

1. Auf einem Datenprodukt (ODPS), das das Datenprodukt als Ganzes repräsentiert.
2. Auf einem Data Contract oder einem seiner Schema-Objekte.
3. Auf einem konkreten Feld innerhalb eines Contract-Schemas.

Dieselbe Verknüpfung kann auch direkt in ODCS-YAML geschrieben werden. Aus einem Demo-Shipments-Contract:

properties:
  - name: shipment_id
    businessName: Shipment ID
    logicalType: string
    primaryKey: true
    authoritativeDefinitions:
      - type: "semantics"
        url: "https://demo.entropy-data.com/my-organization/semantics/main/shipment_id"
  - name: order_id
    authoritativeDefinitions:
      - type: "semantics"
        url: "https://demo.entropy-data.com/my-organization/semantics/main/order_id"

Der Marker type: "semantics" sagt Entropy Data, dass die URL auf ein semantisches Konzept verweist, und der Link wird auf der Contract-Seite als klickbare Referenz gerendert. Auf der Konzeptseite listet Entropy Data jedes Datenprodukt und jeden Data Contract, der darauf verweist, sodass Fragen wie „Welche Datensätze enthalten Kunden-E-Mail-Adressen?“ direkt beantwortet werden können.

Wofür Semantik nützlich ist

Discovery nach Bedeutung

Consumers suchen nach Shipment und finden jedes Datenprodukt, das dieses Konzept implementiert, unabhängig davon, wie die zugrunde liegenden Spalten benannt sind.

Konsistente Definitionen über Teams hinweg

Eine Customer-Email-Definition wird von mehreren Data Contracts referenziert. Ändert man ihre Klassifizierung auf sensitiv, aktualisiert das jede Referenz.

Eine Single Source of Truth für Metriken

GMV, Conversion Rate und die Deckungsbeiträge haben kanonische Definitionen mit Formeln. Das beseitigt die Mehrdeutigkeit, die sich in Spreadsheets gerne ansammelt.

Kontext für KI-Agenten

LLMs wissen nicht, was dein Business unter Active Customer oder Contribution Margin 2 versteht. Wenn Agenten über unseren MCP-Server auf Daten zugreifen, liefert Semantik diesen Kontext, sodass sie über die richtigen Keys joinen und die richtigen Metrikdefinitionen nutzen.

Mit einer Industrieontologie starten

Du musst deine Domäne nicht von Grund auf modellieren. Entropy Data liefert vorbereitete Ontologien für mehrere Branchen mit. Öffne das Studio, geh zu Semantik und nutze Add → Import Industry Standard:

• GoodRelations (E-Commerce)
• FIBO (Finanzen)
• EBU Core Plus (Medien)
• CGMES (Energie)
• IDMP (Pharma)
• EPCIS (Supply Chain)
• IATA ONE Record (Luftfracht)
• TM Forum SID (Telco)

Du kannst auch eigene RDF/OWL-Dateien hochladen (Turtle, OWL, RDF/XML, N-Triples, N3, JSON-LD) oder die Ontologie programmatisch über den SPARQL-Endpoint unter /api/semantics/sparql abfragen.

Offene Standards: Apache Ossie

Entropy Data setzt sich für offene Standards im Semantic Layer ein und ist dem Projekt Apache Ossie beigetreten, früher bekannt als Open Semantic Interchange (OSI). Apache Ossie ist eine herstellerunabhängige Open-Source-Initiative, um zu standardisieren, wie semantische Modelle zwischen BI-Plattformen, KI-Agenten und Analytics-Tools ausgetauscht werden, damit eine einzige Definition einer Entität oder Metrik in deinem Ökosystem konsistent bleibt. Wir werden den kommenden Ossie Ontology Standard nativ in Semantik unterstützen, ergänzend zu unserer Unterstützung von Bitols Open Data Contract Standard und Open Data Product Standard auf der Data-Contract- und Datenprodukt-Seite.

Wie Semantik in den Rest von Entropy Data passt

• Marketplace nutzt semantische Konzepte für Discovery.
• Studio ist der Ort, an dem Domain Experts und Data Product Owner Konzepte kuratieren und mit Contracts verknüpfen.
• Governance verwendet semantische Klassifizierungen (PII, sensitiv usw.) in übergreifenden Policies.
• Der MCP-Server nutzt Semantik, um LLM-Tool-Aufrufe in deinem Business-Vokabular zu verankern.

Erste Schritte

Semantik ist hinter einem Feature Flag verfügbar:

• Entropy Data Cloud: Kontaktiere uns, um es für deine Organisation zu aktivieren.
• Self-Hosted: Setze APPLICATION_SEMANTICS_ENABLED=true und starte die Anwendung neu.

Um Semantik ohne Installation auszuprobieren, öffne die Demo und geh zu Studio → Semantik. Die Demo enthält die wichtigsten Industriestandards: Geh zu Studio → Semantik → Add → Import Ontology, um die bereitgestellten Industriestandards zu erkunden oder deine eigene Ontologie hochzuladen.

Über den Autor

Jochen Christ

LinkedIn von Jochen Christ

Co-Founder & CTO, Entropy Data

Jochen baut Tools, die Daten, Menschen und KI zusammenarbeiten lassen. Er ist Autor der Website Data Mesh Architecture, Maintainer der Data Contract CLI und TSC-Mitglied im Bitol-Projekt der Linux Foundation, der Heimat des Open Data Contract Standard.

Sprich mit Jochen →