Open Standards

What is Apache Ossie?

Jochen Christ

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

Apache Ossie is an open, vendor-neutral specification for exchanging semantic metadata between analytics, BI, and AI platforms. It describes what your data means, in two layers: semantic models that sit on top of tables and define fields, joins, and metrics, and ontologies that describe the business itself in terms of concepts, relationships, and rules. Define "Customer" or "Gross Merchandise Value" once, and every tool that reads the file, including your AI agents, means the same thing.

The problem Ossie solves

Every data tool has its own place to store meaning. The warehouse has a semantic layer, the BI tool has a data model, dbt has its metrics, the CRM has its own field definitions, and the AI assistant has a prompt with instructions. None of them read each other. The result is that a concept like "Monthly Active Users" or "Net Revenue" gets defined three or four times, slightly differently each time, and nobody can say which number is right.

With AI agents, this fragmentation stops being an inconvenience and becomes a correctness problem. An agent that writes SQL needs to know that total_spent is the customer's lifetime revenue, that an order has many line items, and that GMV is measured before refunds. If that knowledge lives in a proprietary format inside one tool, the agent cannot use it anywhere else.

Ossie's answer is a single, open file format for semantic metadata that any tool can read and write. The project's own summary:

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.

The rest of this article follows the three levels in the diagram below: the conceptual level, where the ontology lives; the logical level of data products, data contracts, and semantic models; and the physical tables and columns underneath. Ossie specifies the first two.

From Open Semantic Interchange to Apache Ossie

The project started in 2025 as the Open Semantic Interchange (OSI), launched by Snowflake with 17 founding partners. The public repository opened in November 2025. In July 2026, the project was accepted into the Apache Incubator and renamed Apache Ossie, mainly because "OSI" already belongs to several other projects and standards (ISO/OSI reference model...). By then, the coalition had grown to more than 50 organizations, with code contributions from Snowflake, Dremio, Salesforce, Databricks, dbt Labs, RelationalAI, GoodData, and Entropy Data.

Entropy Data joined the project in June 2026 and contributes to the Ontology working group, which is building the second layer of the specification described below.

Ossie Specifications

Apache Ossie is a family of specifications. The current version is the 0.2.0 draft, which is not yet finalized: minor changes are expected before the release, so treat the examples in this article as a snapshot. What exists today:

• Core metadata specification (core-spec). The original and most mature part: semantic models with datasets, fields, relationships, metrics, AI context, and vendor extensions. Ships as a human-readable spec, a machine-readable spec.yaml, and the osi-schema.json schema used for validation.
• Ontology specification (ontology). Concepts, relationships, rules, and the mappings that connect concepts to the fields of a semantic model, with its own ontology.json schema. This is the layer the Ontology working group is building and the one Entropy Data contributes to; the rest of this article covers it in detail.
• Expression language (proposal). A portable SQL subset for field and metric expressions, so that a metric does not have to be written once per dialect. Defines the supported constructs, operator precedence, the required aggregation functions, and how names are resolved. Still a proposal, produced by the Metric Language working group.

Semantic models

A semantic model is the part most people know from BI tools. It takes physical tables and gives them business structure for dimensional analytics: which tables are facts and dimensions, how they join, and which metrics are defined on them. In data product terms, it is typically what a consumer-aligned data product exposes to BI tools and agents. The building blocks:

• Datasets: logical fact and dimension tables, each pointing to a physical source and declaring its primary and unique keys.
• Fields: the columns of a dataset. Each field has an expression, optionally in several dialects (ANSI SQL, Snowflake, Databricks, BigQuery, Tableau, MDX, GoodData MAQL), a data type, and a role: dimensions, time dimensions, or plain attributes.
• Relationships: join paths between datasets, declared as from / to with the joining columns.
• Metrics: aggregate measures such as total revenue or customer count, again as multi-dialect expressions.
• AI context on the model, a dataset, a field, or a metric, and custom extensions for vendor-specific settings.

A trimmed version of the specification's e-commerce example:

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"]

This is enough for a BI tool to build a star schema, for dbt to generate a metric, and for an AI agent to write a correct revenue query. What it does not say is what an order is, or that the same customer also appears in the CRM dataset under a different key. That is the job of the ontology.

Ontology

An ontology, in the Ossie sense, is a conceptual model of enterprise data. The specification puts it like this:

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

The difference to a semantic model is the level of abstraction. A semantic model is bound to datasets: a field is an expression over columns, a relationship is a join. An ontology talks about the business without reference to storage. A Customer is a concept whether it lives in Salesforce, in the warehouse, or in both; a Customer places an Order is true regardless of which table holds the foreign key. This independence is exactly what makes an ontology portable and what makes it useful to an AI agent that has to reason across several systems.

Concepts

Everything in an ontology is a concept, and a concept is currently one of these kinds:

• An EntityType represents real-world things that cannot be written down directly and must be referenced through other information: a person by their social security number, an order by its order ID. Other modeling languages call these entities or object types.
• A ValueType is a data type with additional semantics: a social security number is a string of exactly nine digits, a currency code is a three-letter ISO 4217 code. Other languages call these domains or data types.

Every concept extends one or more other concepts. Value types eventually extend one of the built-in types; entity types extend other entity types and, implicitly, the built-in Any. This gives the ontology a subtype hierarchy: an Employee is a Person, a Billing Address is a 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 )" ]

Relationships, roles, and verbalization

Relationships connect concepts. Each relationship is declared under the concept that plays its first role and is identified by that concept's name plus its own, so the relationships above are Person.nr and Person.earns. The additional participants are listed as roles. Think of a relationship as a narrow table: its links are the rows, its roles are the columns, and each role is typed by a concept.

Ossie supports n-ary relationships, so they are not limited to binary. A unary relationship has no extra roles (Person files married filing joint), a ternary one has two (Person purchased Vehicle on Date). When the same concept plays two roles, as in Store ships to Store in NrDays, a role name such as destination tells them apart.

The verbalizes patterns are a small detail with large consequences. Every relationship must declare how a link reads in plain language, with placeholders for the roles: "{Customer} places {Order}". This is what lets a tool, or an LLM, turn a graph into sentences and sentences back into graph navigation. Multiplicities (ManyToOne, OneToOne) state that the last role is determined by the others: each person earns at most one salary.

Identifiers, derivations, and rules

• identify_by lists the relationships that form a concept's preferred identifier. A person is identified by nr; a license may be identified by the pair of account and seat number.
• derived_by turns a concept or relationship into a view. The Employee above is every person who earns a salary. A recursive ancestor_of relationship can be derived from parent_of in two rules, a base case and a recursive case, the way a SQL query derives rows.
• requires adds constraints that must hold over a population: a social security number is positive and at most nine digits, a sales amount is greater than zero, an item that has sales in a store must be offered in that store.

Together, these make an Ossie ontology more than a glossary. It is a computable model: a tool can check the rules, expand the derivations, and answer "which Persons are Employees?" without a human having written that query.

An ontology in practice: the retail example

Here is what an Ossie ontology looks like for a real domain. This excerpt is from the demo retail organization that ships with Entropy Data: a Customer entity, the shared Customer ID value type it is identified by, the relationship to Order, and the Gross Merchandise Value metric measured on it.

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}"

A few things to notice. The structure is the Ossie one: a document with a name, a list of concepts under ontology, each with a type, an extends chain down to a built-in, and relationships grouped under their first-role concept with roles, multiplicity, and verbalizes. On top of that, Entropy Data adds a few extensions in the places the draft leaves open: groups and metrics are concept types of their own (GroupType, MetricType), properties are attached to entities through hasProperty relationships, and custom_properties, an Entropy Data extension that is not part of the Ossie draft, carries translations as language-tagged keys (name@de) and the alignment with external ontologies (owl:equivalentClass: http://schema.org/Person). The iri makes every concept addressable as a semantic-web resource, so the same ontology can be imported from and exported to OWL or RDF.

Semantic model vs. ontology

You need both. The semantic model gets you correct numbers from a specific platform; the ontology gets you a shared vocabulary across platforms, and the reasoning that AI agents need to find the right data product in the first place.

Apache Ossie in Entropy Data

Semantics in Entropy Data is an ontology editor built on the Ossie ontology draft. Concepts are organized in namespaces and groups, with entities, shared properties, and metrics side by side, and every concept links to the data products and data contracts that implement it.

Each concept has a detail page with its description in several languages, its relationships, its properties with data types and classification, its IRI and external alignment, and the data products related to it.

Because the ontology is stored in the Ossie format, it is portable. You can edit a whole namespace or a single concept as YAML in the browser, export it to keep it in Git, import it into another instance, and write it through the MCP server, where tools such as semantics_save_ontology accept an Ossie document for a namespace. Existing OWL and RDF ontologies, for example industry standards like EBUCore Plus, can be imported and are represented as Ossie concepts with their original IRIs. And the agents in Entropy Intelligence use the same ontology to resolve a business question to the data products that answer it.

How ontologies, data products, data contracts, and semantic models relate

Back to the three-level picture from the start of the article. The four things in it play distinct roles, and it pays to keep them apart:

• The ontology is the shared vocabulary. It says what a Customer is, that a customer places orders, and that Gross Merchandise Value is the sum of order totals before refunds. It is defined once, owned by the business, and says nothing about where data is stored or which tool reads it.
• A data product is the unit of ownership and delivery. A team publishes data through one or more output ports, takes responsibility for it, and declares which concepts of the ontology the product is about. It is implemented by physical tables, files, or topics.
• A data contract is the specification of an output port: the schema with its fields and types, quality rules, service levels, and terms of use. Each field can reference the ontology concept it implements, which is how a column such as customer_id gets its meaning, its classification, and its place in the graph.
• A BI semantic model is a consumer-facing model built for analysis: facts, dimensions, joins, and metrics over one or more data products, in Power BI, Snowflake, dbt, or Tableau. It maps its metrics and dimensions to the ontology so that "revenue" in a dashboard means the same as Gross Merchandise Value everywhere else.

The relationships run in one direction. The ontology defines meaning; data products and semantic models implement it; data contracts are the written specification that binds an implementation to the concepts; and the physical tables are where the data lives. A semantic model typically reads from the output ports of data products, so its own definitions can be derived from the contracts upstream of it, and in Entropy Data a semantic model is itself a data product that can be put under a contract. Ossie standardizes the two layers that carry meaning, the ontology and the semantic model, so that both can be exchanged between tools. Bitol's ODPS and ODCS standardize the data product and its contracts.

This relationship model is, of course, itself an ontology, so it can be written in Ossie. The excerpt below declares the Data Contract concept with its two relationships; the full document has all nine concepts in three groups, one per level.

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}"

Loaded into Entropy Data, the document becomes a navigable graph: the three levels are the groups, the concepts are the nodes, and the edges carry the relationship names from the verbalizes patterns.

From concepts to data products: the data contract link

An ontology says what a Customer is. It does not say where customer data lives, and it should not: the same concept is implemented by several data products, in different systems, with different schemas. Something has to make the connection from the conceptual layer down to the physical data. In Entropy Data, that something is the data contract, which specifies the logical level of the three-level picture above.

The mechanism already exists in the Open Data Contract Standard: authoritativeDefinitions, a list of typed URLs that can be attached to almost any element of a contract. Entropy Data recognizes the type semantics and resolves the URL to a concept, either by its Entropy Data address (/semantics/{namespace}/{id}) or by the concept's IRI. The link can be set at three levels:

1. On a field in a contract schema: the column SKU implements the shared value type Stock Keeping Unit.
2. On a schema object or the contract: the customers table implements the entity Customer.
3. On a data product, in its ODPS description, at the root or on an input or output port: the Customer Cohorts product is about Customer.

From the demo articles contract, two fields pointing at their concepts:

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

And the same link on a data product, in its ODPS file:

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

Once the link is in the contract, Entropy Data uses it in several places. The contract page shows each linked field with its concept, and the concept's classification travels with it: a field linked to Customer Email is marked Restricted because the concept is, and the contract's own classification is derived from the concepts it links to and re-derived when a concept changes. The concept page lists every data product and contract that implements it, which turns "which datasets contain customer email addresses?" into a lookup. In the contract editor, a picker finds the right concept for a field, and an AI suggestion run proposes links for every property of a contract at once.

For an AI agent, this is the path from a question to a query. The agent resolves the business terms in the question against the ontology, follows the contract links from the concepts to the data products that implement them, reads the contract schema to find the physical columns, and only then writes SQL. Ossie's own ontology mappings describe the same connection from the ontology side, field by field. Entropy Data declares it from the data side, in the contract, which keeps the ontology stable while any number of data products can state which concepts they implement.

Getting started

• Read the core metadata specification and the ontology specification in the apache/ossie repository, and validate your first file with the schema and tooling there.
• Follow project updates at ossie.apache.org; the original opensemantic.com site still introduces the idea of a vendor-agnostic semantic model.
• Try the ontology editor in the Entropy Data demo: open Studio, then Semantics, and switch any concept or the whole namespace to YAML.

About the author

Jochen Christ

LinkedIn of Jochen Christ

Co-Founder & CTO, Entropy Data

Jochen builds tools that help data, people, and AI work together. He is the author of the Data Mesh Architecture website, maintainer of the Data Contract CLI, and a TSC member of the Linux Foundation's Bitol project, home of the Open Data Contract Standard.

Talk with Jochen →