Offene Standards

Was ist Apache Ossie?

Jochen Christ

Co-Founder & CTO, Entropy Data · 2026-08-22

Apache Ossie ist eine offene, herstellerneutrale Spezifikation für den Austausch semantischer Metadaten zwischen Analytics-, BI- und KI-Plattformen. Sie beschreibt, was deine Daten bedeuten, auf zwei Ebenen: Semantic Models, die auf Tabellen aufsetzen und Felder, Joins und Metriken definieren, und Ontologien, die das Business selbst in Konzepten, Beziehungen und Regeln beschreiben. Definiere „Customer“ oder „Gross Merchandise Value“ einmal, und jedes Tool, das die Datei liest, auch deine KI-Agenten, meint dasselbe.

Das Problem, das Ossie löst

Jedes Daten-Tool hat seinen eigenen Ort, an dem Bedeutung gespeichert wird. Das Warehouse hat einen Semantic Layer, das BI-Tool ein Datenmodell, dbt seine Metriken, das CRM eigene Felddefinitionen, und der KI-Assistent einen Prompt mit Anweisungen. Keines davon liest das andere. Das Ergebnis: Ein Konzept wie „Monthly Active Users“ oder „Net Revenue“ wird drei- oder viermal definiert, jedes Mal ein bisschen anders, und niemand kann sagen, welche Zahl stimmt.

Mit KI-Agenten wird aus dieser Fragmentierung mehr als ein Ärgernis: Sie wird zu einem Korrektheitsproblem. Ein Agent, der SQL schreibt, muss wissen, dass total_spent der Lifetime-Umsatz eines Kunden ist, dass eine Bestellung viele Positionen hat und dass GMV vor Rückerstattungen gemessen wird. Steckt dieses Wissen in einem proprietären Format in einem einzigen Tool, kann der Agent es nirgendwo sonst nutzen.

Die Antwort von Ossie ist ein einziges, offenes Dateiformat für semantische Metadaten, das jedes Tool lesen und schreiben kann. So fasst es das Projekt selbst zusammen:

Apache Ossie, industry wide specification effort to standardize how we exchange semantic metadata across analytics, AI and BI platforms, providing a vendor neutral, single source of truth for semantic data.

Der Rest dieses Artikels folgt den drei Ebenen im Diagramm unten: der konzeptionellen Ebene, auf der die Ontologie lebt; der logischen Ebene mit Datenprodukten, Data Contracts und Semantic Models; und den physischen Tabellen und Spalten darunter. Ossie spezifiziert die ersten beiden.

Von Open Semantic Interchange zu Apache Ossie

Das Projekt startete 2025 als Open Semantic Interchange (OSI), ins Leben gerufen von Snowflake mit 17 Gründungspartnern. Das öffentliche Repository wurde im November 2025 eröffnet. Im Juli 2026 wurde das Projekt in den Apache Incubator aufgenommen und in Apache Ossie umbenannt, vor allem weil „OSI“ bereits mehreren anderen Projekten und Standards gehört (etwa dem ISO/OSI-Referenzmodell). Bis dahin war die Koalition auf mehr als 50 Organisationen angewachsen, mit Code-Beiträgen von Snowflake, Dremio, Salesforce, Databricks, dbt Labs, RelationalAI, GoodData und Entropy Data.

Entropy Data ist dem Projekt im Juni 2026 beigetreten und arbeitet in der Ontology Working Group mit, die die zweite Ebene der unten beschriebenen Spezifikation entwickelt.

Ossie-Spezifikationen

Apache Ossie ist eine Familie von Spezifikationen. Die aktuelle Version ist der 0.2.0-Draft, der noch nicht finalisiert ist: Vor dem Release sind kleinere Änderungen zu erwarten, betrachte die Beispiele in diesem Artikel also als Momentaufnahme. Was es heute gibt:

• Core Metadata Specification (core-spec). Der ursprüngliche und ausgereifteste Teil: Semantic Models mit Datasets, Feldern, Beziehungen, Metriken, AI Context und Vendor Extensions. Ausgeliefert als lesbare Spezifikation, als maschinenlesbare spec.yaml und als osi-schema.json, das zur Validierung dient.
• Ontology Specification (ontology). Konzepte, Beziehungen, Regeln und die Mappings, die Konzepte mit den Feldern eines Semantic Models verbinden, mit eigenem ontology.json-Schema. Das ist die Ebene, die die Ontology Working Group entwickelt und zu der Entropy Data beiträgt; der Rest dieses Artikels behandelt sie im Detail.
• Expression Language (Proposal). Eine portable SQL-Teilmenge für Feld- und Metrik-Ausdrücke, damit eine Metrik nicht einmal pro Dialekt geschrieben werden muss. Definiert die unterstützten Konstrukte, die Operator-Präzedenz, die verpflichtenden Aggregatfunktionen und die Namensauflösung. Noch ein Proposal, erarbeitet von der Metric Language Working Group.

Semantic Models

Ein Semantic Model ist der Teil, den die meisten aus BI-Tools kennen. Es nimmt physische Tabellen und gibt ihnen eine Business-Struktur für dimensionale Analysen: welche Tabellen Fakten und Dimensionen sind, wie sie gejoint werden und welche Metriken darauf definiert sind. In Datenprodukt-Begriffen ist es typischerweise das, was ein Consumer-aligned Datenprodukt BI-Tools und Agenten bereitstellt. Die Bausteine:

• Datasets: logische Fakten- und Dimensionstabellen, die jeweils auf eine physische source zeigen und ihre Primär- und Unique-Keys deklarieren.
• Fields: die Spalten eines Datasets. Jedes Feld hat einen Ausdruck, optional in mehreren Dialekten (ANSI SQL, Snowflake, Databricks, BigQuery, Tableau, MDX, GoodData MAQL), einen Datentyp und eine Rolle: Dimension, Zeitdimension oder einfaches Attribut.
• Relationships: Join-Pfade zwischen Datasets, deklariert als from / to mit den Join-Spalten.
• Metrics: aggregierte Kennzahlen wie Gesamtumsatz oder Kundenzahl, wieder als Ausdrücke in mehreren Dialekten.
• AI Context am Modell, einem Dataset, einem Feld oder einer Metrik, und Custom Extensions für herstellerspezifische Einstellungen.

Eine gekürzte Fassung des E-Commerce-Beispiels aus der Spezifikation:

version: 0.2.0.dev0
semantic_model:
  - name: ecommerce_analytics
    description: E-commerce sales and customer analytics
    ai_context:
      instructions: >-
        Use this model for analyzing sales trends,
        customer behavior, and product performance
    datasets:
      - name: orders
        source: sales.public.orders
        primary_key: [order_id]
        fields:
          - name: order_id
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: order_id
          - name: order_date
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: order_date
            datatype: Date
            dimension:
              is_time: true
          - name: amount
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: amount
      - name: customers
        source: sales.public.customers
        primary_key: [id]
    relationships:
      - name: orders_to_customers
        from: orders
        to: customers
        from_columns: [customer_id]
        to_columns: [id]
    metrics:
      - name: total_revenue
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: SUM(orders.amount)
        description: Total revenue from all orders
        ai_context:
          synonyms: ["total sales", "revenue"]

Das reicht, damit ein BI-Tool ein Sternschema baut, dbt eine Metrik generiert und ein KI-Agent eine korrekte Umsatz-Query schreibt. Was es nicht sagt: was eine Bestellung ist, oder dass derselbe Kunde auch im CRM-Dataset unter einem anderen Schlüssel auftaucht. Das ist die Aufgabe der Ontologie.

Ontologie

Eine Ontologie im Sinne von Ossie ist ein konzeptionelles Modell von Unternehmensdaten. Die Spezifikation formuliert es so:

Ontologies are conceptual models of enterprise data that describe the enterprise in terms of concepts, relationships, and business rules.

Der Unterschied zu einem Semantic Model ist die Abstraktionsebene. Ein Semantic Model ist an Datasets gebunden: Ein Feld ist ein Ausdruck über Spalten, eine Beziehung ist ein Join. Eine Ontologie spricht über das Business, ohne sich auf die Speicherung zu beziehen. Ein Customer ist ein Konzept, egal ob er in Salesforce, im Warehouse oder in beiden lebt; ein Customer gibt eine Order auf gilt unabhängig davon, welche Tabelle den Fremdschlüssel hält. Genau diese Unabhängigkeit macht eine Ontologie portabel, und sie macht sie nützlich für einen KI-Agenten, der über mehrere Systeme hinweg schließen muss.

Konzepte

Alles in einer Ontologie ist ein Konzept, und ein Konzept ist aktuell eines der folgenden:

• Ein EntityType steht für Dinge der realen Welt, die sich nicht direkt aufschreiben lassen und über andere Informationen referenziert werden müssen: eine Person über ihre Sozialversicherungsnummer, eine Bestellung über ihre Bestell-ID. Andere Modellierungssprachen nennen das Entitäten oder Objekttypen.
• Ein ValueType ist ein Datentyp mit zusätzlicher Semantik: Eine Sozialversicherungsnummer ist ein String aus genau neun Ziffern, ein Währungscode ein dreibuchstabiger ISO-4217-Code. Andere Sprachen nennen das Domänen oder Datentypen.

Jedes Konzept erweitert mit extends ein oder mehrere andere Konzepte. Value Types erweitern letztlich einen der eingebauten Typen; Entity Types erweitern andere Entity Types und implizit das eingebaute Any. Das gibt der Ontologie eine Subtyp-Hierarchie: Ein Employee ist eine Person, eine Billing Address ist eine Postal Address.

name: EnterpriseOntology
ontology:
  - concept: SocialSecurityNr
    type: ValueType
    extends: [Integer]
    requires: [ "0 < SocialSecurityNr", "SocialSecurityNr <= 999999999" ]
  - concept: Person
    type: EntityType
    identify_by: [ nr ]
    relationships:
      - name: nr
        roles:
          - concept: SocialSecurityNr
        multiplicity: OneToOne
        verbalizes: [ "{Person} is identified by {SocialSecurityNr}" ]
      - name: earns
        roles:
          - concept: Salary
        multiplicity: ManyToOne
        verbalizes: [ "{Person} earns {Salary}" ]
  - concept: Employee
    type: EntityType
    extends: [Person]
    derived_by: [ "EXISTS ( Person.earns )" ]

Beziehungen, Rollen und Verbalisierung

Beziehungen verbinden Konzepte. Jede Beziehung wird unter dem Konzept deklariert, das ihre erste Rolle spielt, und über den Namen dieses Konzepts plus ihren eigenen identifiziert. Die Beziehungen oben heißen also Person.nr und Person.earns. Die weiteren Beteiligten werden als Rollen aufgelistet. Stell dir eine Beziehung als schmale Tabelle vor: Ihre Links sind die Zeilen, ihre Rollen die Spalten, und jede Rolle ist durch ein Konzept typisiert.

Ossie unterstützt n-äre Beziehungen, sie sind also nicht auf binäre beschränkt. Eine unäre Beziehung hat keine zusätzlichen Rollen (Person files married filing joint), eine ternäre hat zwei (Person purchased Vehicle on Date). Spielt dasselbe Konzept zwei Rollen, wie in Store ships to Store in NrDays, hält ein Rollenname wie destination sie auseinander.

Die verbalizes-Muster sind ein kleines Detail mit großer Wirkung. Jede Beziehung muss deklarieren, wie sich ein Link in natürlicher Sprache liest, mit Platzhaltern für die Rollen: "{Customer} places {Order}". Das ist es, was einem Tool, oder einem LLM, erlaubt, einen Graphen in Sätze zu verwandeln und Sätze zurück in Graph-Navigation. Multiplizitäten (ManyToOne, OneToOne) legen fest, dass die letzte Rolle durch die anderen bestimmt ist: Jede Person verdient höchstens ein Gehalt.

Identifikatoren, Ableitungen und Regeln

• identify_by listet die Beziehungen, die den bevorzugten Identifikator eines Konzepts bilden. Eine Person wird über nr identifiziert; eine Lizenz vielleicht über das Paar aus Account und Seat-Nummer.
• derived_by macht aus einem Konzept oder einer Beziehung eine View. Der Employee oben ist jede Person, die ein Gehalt verdient. Eine rekursive ancestor_of-Beziehung lässt sich aus parent_of in zwei Regeln ableiten, einem Basisfall und einem rekursiven Fall, so wie eine SQL-Query Zeilen ableitet.
• requires fügt Constraints hinzu, die über einer Population gelten müssen: Eine Sozialversicherungsnummer ist positiv und höchstens neun Ziffern lang, ein Verkaufsbetrag ist größer als null, ein Artikel mit Verkäufen in einem Store muss in diesem Store angeboten werden.

Zusammen machen diese Elemente eine Ossie-Ontologie zu mehr als einem Glossar. Sie ist ein berechenbares Modell: Ein Tool kann die Regeln prüfen, die Ableitungen auflösen und „Welche Personen sind Employees?“ beantworten, ohne dass ein Mensch diese Query geschrieben hat.

Eine Ontologie in der Praxis: das Retail-Beispiel

So sieht eine Ossie-Ontologie für eine echte Domäne aus. Dieser Auszug stammt aus der Demo-Retail-Organisation, die mit Entropy Data ausgeliefert wird: eine Customer-Entität, der gemeinsam genutzte Value Type Customer ID, über den sie identifiziert wird, die Beziehung zu Order und die Metrik Gross Merchandise Value, die darauf gemessen wird.

version: 0.2.0.dev0
name: main
description: Core business semantics for the demo retail organization.
ontology:
  - concept: Customer ID
    id: customer_id
    type: ValueType
    shared: true
    group: Customers
    description: |-
      The internal ID of any customer in the online shop.
      Guest customers have a customer ID as well.
    extends:
      - String
    classification: Confidential
    examples:
      - "c1-10123123"
    custom_properties:
      name@de: Kunden-ID
      name@fr: ID du client

  - concept: Customer
    id: customer
    type: EntityType
    group: Customers
    description: A natural person who places orders in the online shop.
    iri: http://www.entropy-data.com/ns/main/Customer
    custom_properties:
      owl:equivalentClass: http://schema.org/Person
      name@de: Kunde
      name@fr: Client
    relationships:
      - name: places
        description: A customer places one or more orders.
        roles:
          - concept: Order
        multiplicity: OneToMany
        verbalizes:
          - "{Customer} places {Order}"
      - name: customer_id
        type: hasProperty
        roles:
          - concept: Customer ID
      - name: customer_email
        type: hasProperty
        roles:
          - concept: Customer Email

  - concept: Gross Merchandise Value
    id: gmv
    type: MetricType
    group: Controlling
    description: |-
      Total value of all placed orders before refunds, returns, and discounts.
      The headline ecommerce KPI, commonly abbreviated as GMV.
    unit: EUR
    better_when: higher
    formula: "SUM(order.total_amount)"
    relationships:
      - name: measures
        type: measures
        roles:
          - concept: total_amount
        verbalizes:
          - "{Gross Merchandise Value} measures {total_amount}"

Ein paar Dinge fallen auf. Die Struktur ist die von Ossie: ein Dokument mit einem name, eine Liste von Konzepten unter ontology, jedes mit einem type, einer extends-Kette bis hinunter zu einem eingebauten Typ, und Beziehungen, die unter dem Konzept ihrer ersten Rolle gruppiert sind, mit roles, multiplicity und verbalizes. Darüber hinaus ergänzt Entropy Data ein paar Erweiterungen an den Stellen, die der Draft offenlässt: Gruppen und Metriken sind eigene Konzepttypen (GroupType, MetricType), Properties werden über hasProperty-Beziehungen an Entitäten gehängt, und custom_properties, eine Entropy-Data-Erweiterung, die nicht Teil des Ossie-Drafts ist, trägt Übersetzungen als sprachmarkierte Schlüssel (name@de) sowie die Angleichung an externe Ontologien (owl:equivalentClass: http://schema.org/Person). Die iri macht jedes Konzept als Semantic-Web-Ressource adressierbar, sodass dieselbe Ontologie aus OWL oder RDF importiert und dorthin exportiert werden kann.

Semantic Model vs. Ontologie

Du brauchst beides. Das Semantic Model liefert dir korrekte Zahlen von einer bestimmten Plattform; die Ontologie liefert dir ein gemeinsames Vokabular über Plattformen hinweg, und das Schlussfolgern, das KI-Agenten brauchen, um überhaupt erst das richtige Datenprodukt zu finden.

Apache Ossie in Entropy Data

Semantik in Entropy Data ist ein Ontologie-Editor auf Basis des Ossie-Ontologie-Drafts. Konzepte sind in Namespaces und Gruppen organisiert, mit Entitäten, gemeinsam genutzten Properties und Metriken nebeneinander, und jedes Konzept ist mit den Datenprodukten und Data Contracts verknüpft, die es implementieren.

Jedes Konzept hat eine Detailseite mit seiner Beschreibung in mehreren Sprachen, seinen Beziehungen, seinen Properties mit Datentypen und Klassifizierung, seiner IRI und externen Angleichung sowie den zugehörigen Datenprodukten.

Weil die Ontologie im Ossie-Format gespeichert ist, ist sie portabel. Du kannst einen ganzen Namespace oder ein einzelnes Konzept als YAML im Browser bearbeiten, es exportieren, um es in Git zu halten, es in eine andere Instanz importieren und es über den MCP-Server schreiben, wo Tools wie semantics_save_ontology ein Ossie-Dokument für einen Namespace entgegennehmen. Bestehende OWL- und RDF-Ontologien, zum Beispiel Branchenstandards wie EBUCore Plus, lassen sich importieren und werden als Ossie-Konzepte mit ihren ursprünglichen IRIs dargestellt. Und die Agenten in Entropy Intelligence nutzen dieselbe Ontologie, um eine Business-Frage auf die Datenprodukte aufzulösen, die sie beantworten.

Wie Ontologien, Datenprodukte, Data Contracts und Semantic Models zusammenhängen

Zurück zum Drei-Ebenen-Bild vom Anfang des Artikels. Die vier Dinge darin spielen unterschiedliche Rollen, und es lohnt sich, sie auseinanderzuhalten:

• Die Ontologie ist das gemeinsame Vokabular. Sie sagt, was ein Customer ist, dass ein Kunde Bestellungen aufgibt und dass Gross Merchandise Value die Summe der Bestellbeträge vor Rückerstattungen ist. Sie wird einmal definiert, gehört dem Business und sagt nichts darüber, wo Daten gespeichert sind oder welches Tool sie liest.
• Ein Datenprodukt ist die Einheit von Ownership und Bereitstellung. Ein Team veröffentlicht Daten über einen oder mehrere Output Ports, übernimmt die Verantwortung dafür und deklariert, um welche Konzepte der Ontologie es in dem Produkt geht. Implementiert wird es durch physische Tabellen, Dateien oder Topics.
• Ein Data Contract ist die Spezifikation eines Output Ports: das Schema mit seinen Feldern und Typen, Qualitätsregeln, Service Levels und Nutzungsbedingungen. Jedes Feld kann das Ontologie-Konzept referenzieren, das es implementiert. So bekommt eine Spalte wie customer_id ihre Bedeutung, ihre Klassifizierung und ihren Platz im Graphen.
• Ein BI Semantic Model ist ein Consumer-orientiertes Modell für Analysen: Fakten, Dimensionen, Joins und Metriken über einem oder mehreren Datenprodukten, in Power BI, Snowflake, dbt oder Tableau. Es bildet seine Metriken und Dimensionen auf die Ontologie ab, sodass „Umsatz“ in einem Dashboard dasselbe bedeutet wie Gross Merchandise Value überall sonst.

Die Beziehungen verlaufen in eine Richtung. Die Ontologie definiert Bedeutung; Datenprodukte und Semantic Models implementieren sie; Data Contracts sind die schriftliche Spezifikation, die eine Implementierung an die Konzepte bindet; und die physischen Tabellen sind der Ort, an dem die Daten liegen. Ein Semantic Model liest typischerweise aus den Output Ports von Datenprodukten, sodass seine eigenen Definitionen aus den Data Contracts stromaufwärts abgeleitet werden können, und in Entropy Data ist ein Semantic Model selbst ein Datenprodukt, das unter einen Data Contract gestellt werden kann. Ossie standardisiert die beiden Ebenen, die Bedeutung tragen, die Ontologie und das Semantic Model, sodass beide zwischen Tools ausgetauscht werden können. ODPS und ODCS von Bitol standardisieren das Datenprodukt und seine Data Contracts.

Dieses Beziehungsmodell ist natürlich selbst eine Ontologie und lässt sich daher in Ossie schreiben. Der Auszug unten deklariert das Konzept Data Contract mit seinen zwei Beziehungen; das vollständige Dokument enthält alle neun Konzepte in drei Gruppen, eine pro Ebene.

version: 0.2.0.dev0
name: ossie-meta
ontology:
  - concept: Data Contract
    type: EntityType
    group: logical-level
    description: The specification of an output port. Schema, quality rules, service levels, and terms of use. Specified by Bitol ODCS.
    relationships:
      - name: references
        description: Contract fields reference the concepts they implement via authoritativeDefinitions.
        roles:
          - concept: Concept
        multiplicity: OneToMany
        verbalizes:
          - "{Data Contract} references {Concept}"
      - name: describes
        description: The contract schema describes the physical columns.
        roles:
          - concept: Column
        multiplicity: OneToMany
        verbalizes:
          - "{Data Contract} describes {Column}"

In Entropy Data geladen, wird das Dokument zu einem navigierbaren Graphen: Die drei Ebenen sind die Gruppen, die Konzepte sind die Knoten, und die Kanten tragen die Beziehungsnamen aus den verbalizes-Mustern.

Von Konzepten zu Datenprodukten: die Verknüpfung über den Data Contract

Eine Ontologie sagt, was ein Customer ist. Sie sagt nicht, wo Kundendaten liegen, und das soll sie auch nicht: Dasselbe Konzept wird von mehreren Datenprodukten implementiert, in verschiedenen Systemen, mit verschiedenen Schemas. Irgendetwas muss die Verbindung von der konzeptionellen Ebene hinunter zu den physischen Daten herstellen. In Entropy Data ist dieses Etwas der Data Contract, der die logische Ebene des Drei-Ebenen-Bilds oben spezifiziert.

Der Mechanismus existiert bereits im Open Data Contract Standard: authoritativeDefinitions, eine Liste typisierter URLs, die an fast jedes Element eines Data Contracts gehängt werden kann. Entropy Data erkennt den Typ semantics und löst die URL zu einem Konzept auf, entweder über seine Entropy-Data-Adresse (/semantics/{namespace}/{id}) oder über die IRI des Konzepts. Die Verknüpfung kann auf drei Ebenen gesetzt werden:

1. An einem Feld im Schema eines Data Contracts: Die Spalte SKU implementiert den gemeinsam genutzten Value Type Stock Keeping Unit.
2. An einem Schema-Objekt oder am Data Contract: Die Tabelle customers implementiert die Entität Customer.
3. An einem Datenprodukt, in seiner ODPS-Beschreibung, auf Root-Ebene oder an einem Input oder Output Port: Im Produkt Customer Cohorts geht es um Customer.

Aus dem Demo-Data-Contract für Artikel: zwei Felder, die auf ihre Konzepte zeigen:

schema:
  - name: articles
    properties:
      - name: SKU
        logicalType: string
        primaryKey: true
        authoritativeDefinitions:
          - type: semantics
            url: https://demo.entropy-data.com/my-organization/semantics/main/sku
      - name: BRAND_NAME
        logicalType: string
        description: The brand of the article
        authoritativeDefinitions:
          - type: semantics
            url: https://demo.entropy-data.com/my-organization/semantics/main/product.brand

Und dieselbe Verknüpfung an einem Datenprodukt, in seiner ODPS-Datei:

apiVersion: v1.0.0
kind: DataProduct
id: customer-cohorts
authoritativeDefinitions:
  - type: semantics
    url: https://demo.entropy-data.com/my-organization/semantics/main/customer
inputPorts:
  - name: customers-latest-npii
    contractId: databricks_customers_latest_npii_v1
    authoritativeDefinitions:
      - type: semantics
        url: https://demo.entropy-data.com/my-organization/semantics/main/customer

Sobald die Verknüpfung im Data Contract steht, nutzt Entropy Data sie an mehreren Stellen. Die Contract-Seite zeigt jedes verknüpfte Feld mit seinem Konzept, und die Klassifizierung des Konzepts wandert mit: Ein Feld, das mit Customer Email verknüpft ist, wird als Restricted markiert, weil das Konzept es ist, und die Klassifizierung des Data Contracts selbst wird aus den verknüpften Konzepten abgeleitet und neu abgeleitet, wenn sich ein Konzept ändert. Die Konzeptseite listet jedes Datenprodukt und jeden Data Contract, die es implementieren, womit „Welche Datasets enthalten Kunden-E-Mail-Adressen?“ zu einem Nachschlagen wird. Im Contract-Editor findet ein Picker das passende Konzept für ein Feld, und ein KI-Vorschlagslauf schlägt Verknüpfungen für alle Properties eines Data Contracts auf einmal vor.

Für einen KI-Agenten ist das der Weg von einer Frage zu einer Query. Der Agent löst die Business-Begriffe in der Frage gegen die Ontologie auf, folgt den Contract-Verknüpfungen von den Konzepten zu den Datenprodukten, die sie implementieren, liest das Contract-Schema, um die physischen Spalten zu finden, und schreibt erst dann SQL. Die Ontology Mappings von Ossie beschreiben dieselbe Verbindung von der Ontologie-Seite aus, Feld für Feld. Entropy Data deklariert sie von der Datenseite aus, im Data Contract. So bleibt die Ontologie stabil, während beliebig viele Datenprodukte angeben können, welche Konzepte sie implementieren.

Erste Schritte

• Lies die Core Metadata Specification und die Ontology Specification im Repository apache/ossie und validiere deine erste Datei mit dem Schema und den Tools dort.
• Verfolge die Projekt-Updates auf ossie.apache.org; die ursprüngliche Website opensemantic.com führt nach wie vor in die Idee eines herstellerneutralen Semantic Models ein.
• Probiere den Ontologie-Editor in der Entropy-Data-Demo aus: Öffne Studio, dann Semantik, und schalte ein beliebiges Konzept oder den ganzen Namespace auf YAML um.

Ü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 →