Wissen

Semantik: Business mit Datenprodukten verbinden

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.

Semantik-Diagrammansicht mit Konzepten und Beziehungen als interaktiver Graph
Diagrammansicht eines Semantik-Namespaces mit der nach Entropy Data importierten EBU-Core-Plus-Medienontologie.

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: die Substantive deiner Domäne. Customer, Order, Article, Shipment.
  • Shared Property: ein wiederverwendbares Attribut mit einem primitiven Typ, das an eine oder mehrere Entitäten gehängt wird. Customer Email, SKU, Order ID. Einmal definiert, an mehreren Stellen referenziert.
  • Metric: eine messbare Größe mit Einheit, einer "Better-When"-Richtung und einer optionalen Formel. Gross Merchandise Value, Conversion Rate, Order Fulfillment Time.
  • Group: 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 Annotationen und Tags.

Semantik-Listenansicht in Entropy Data mit Konzepten, gruppiert nach Group
Listenansicht eines Semantik-Namespaces, gruppiert nach Themengebiet.
Detailansicht eines semantischen Konzepts mit Properties, Annotationen und eingehenden/ausgehenden Beziehungen
Eine Konzeptseite mit Schema, Klassifizierung, Beispielen, Annotationen und Beziehungen.

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. Ein Auszug aus der Retail-Demo-Ontologie: 

concepts:
  - id: order
    name: Order
    kind: entity
    group: Sales
    description: A confirmed purchase placed by a customer in the online shop.
    properties:
      - ref: Order ID
      - ref: Customer ID
      - name: placed_at
        kind: property
        data_type: timestamp
      - name: order_status
        kind: property
        data_type: string
        enum: [pending, confirmed, shipped, delivered, cancelled, returned]
      - name: total_amount
        kind: property
        data_type: number
      - name: currency
        kind: property
        data_type: string
        pattern: ^[A-Z]{3}$
        examples: [EUR, USD]
    annotations:
      - name: owl:equivalentClass
        value: http://schema.org/Order

Zwei Details lohnen einen Hinweis. Die ref-Einträge ziehen Shared Properties (Order ID und Customer ID) heran, die einmal definiert und über Entitäten hinweg wiederverwendet werden. Die Annotation owl:equivalentClass 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. 

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

  - id: average_order_value
    name: Average Order Value
    kind: metric
    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, isA, memberOf, measures, derived_from und relatedTo. 

relationships:
  - id: gmv_measures_order_total
    type: measures
    relates:
      - concept: gmv
      - concept: order.total_amount
    verbalizes: "{Gross Merchandise Value} measures {Order.total_amount}"

  - id: aov_derived_from_gmv
    type: derived_from
    relates:
      - concept: average_order_value
      - concept: gmv
    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 annotation-Einträge mit lang-Tag 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. 

concepts:
  - id: customer
    name: Customer
    kind: entity
    description: A natural person who places orders in the online shop.
    annotations:
      - name: name
        value: Kunde
        lang: de
      - name: name
        value: Client
        lang: fr
      - name: description
        value: Eine natürliche Person, die Bestellungen im Online-Shop aufgibt.
        lang: de
      - name: description
        value: Une personne physique qui passe des commandes dans la boutique en ligne.
        lang: fr

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.
Find-Definition-Picker im Data Contract Editor
Der Find-Definition-Picker im Data Contract Editor.

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 (Air Cargo)
  • 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: OSI

Entropy Data setzt sich für offene Standards im Semantic Layer ein und ist der Open Semantic Interchange (OSI)-Initiative beigetreten. OSI 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 OSI-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.