Open Semantic

Open standards for semantic data

Layers: Ontology (conceptual), Semantic Models and Data Products (logical), Data (physical)

What is Semantic Data?

Semantic data provides reliable business context for humans and agents. Tables and columns describe how data is stored, but not what it means. Semantic data adds that meaning: the business concepts and how they relate, how metrics like revenue or churn are calculated, and who owns a data product and guarantees its quality. When this context is defined once in an open, machine-readable format, analysts, BI tools, and AI agents all work from the same definitions. Agents stop guessing from column names, and every tool reports the same numbers.

Why Semantic Data Matters

Semantic technologies have been around for many years, but with the rise of AI, they are finally becoming more relevant. LLMs need the context to understand what a user asks for, they need to evaluate which data product carries the relevant data for the business domain, and they need to decide if a data product is reliable enough to be used:

  • Speak the business language. Customers, orders, revenue, and churn are defined in the terms the business uses, not in table and column names.
  • Give agents business context. AI agents read the same definitions as your analysts, so they stop guessing what cust_flg_2 means.
  • Same answers, every time. Every app and every agent returns the same answer to the same question, today and tomorrow.
  • Work on the correct data. Business concepts point to the data products that hold them, so teams pick the right source and report the same numbers.
  • Token efficiency. A compact semantic definition replaces schema exploration, data sampling, and failed query retries. Agents need fewer tokens and answer faster.

The Need for Open Standards

Semantic metadata becomes a core business asset. Your definitions of concepts, metrics, and rules encode how your business works, and every tool that works with your data needs them: business apps, BI tools, data platforms, and AI agents. Today, most of these tools keep their own definitions in their own formats. Open standards turn these scattered definitions into one asset that you own:

  • One format, many tools. Apache Ossie describes ontologies and semantic models, and Bitol ODPS and ODCS describe data products and data contracts. Every tool that supports them reads and writes the same definitions.
  • No vendor lock-in. Definitions in an open format stay yours when you add or replace a tool. Nothing has to be rebuilt from scratch.
  • Semantics as code. Keep ontologies, semantic models, and data contracts as YAML files in Git. Changes go through pull requests and reviews, CI validates them against the JSON Schemas, and every release is versioned.
  • Published everywhere. Each release is pushed into the knowledge bases and context layers of your apps, data platforms, and AI platforms, so every tool works with the current definitions. See Distributing Semantic Data below.

Apache OssieApache Ossie logo

Apache Ossie (incubating) is an industry-driven open standard for semantic data. It started as Open Semantic Interchange (OSI), launched by Snowflake and partners in September 2025, and entered the Apache Incubator in July 2026 under its new name.

More than 50 organizations contribute, including Snowflake, Databricks, Salesforce, dbt Labs, Dremio, GoodData, RelationalAI, and Honeydew. The specification is developed in the open under Apache Software Foundation governance, with public mailing lists, GitHub discussions, and a vote for every spec change. It is licensed under the Apache License 2.0.

Ossie covers two layers of semantic data, both written in YAML or JSON:

Conceptual

Ontology

Business concepts, their relationships, and rules, mapped to the datasets that hold them.

Specification 0.2.0 (in development)

Logical

Semantic Models

Datasets, relationships, metrics, and multi-dialect expressions for BI tools, query engines, and agents.

Specification 0.1.1 (released), 0.2.0 in development

Source, issues, and discussions are on GitHub.

Ontology

An ontology describes the business in its own terms: the concepts that matter, how they relate, and the rules that always hold. It is independent of where and how the data is stored.

Here is an ontology for an online store with customers, orders, products, payments, and shipments. Click a concept to see its properties and rules:

Ossie defines a YAML specification for these elements in the ontology:

Ontology

An Ossie ontology starts with a version, a name, and an optional description and AI context.

Concepts

Concepts are the things that matter to the business. Entity types like Customer and Order are real-world objects, referenced by an identifier. Value types like CustomerNr or Amount are data types with business meaning that extend built-in types such as String, Integer, or Date. An optional IRI gives a concept a global identifier, so data contracts and other tools can refer to it.

Relationships

Relationships connect concepts. Each one is grouped under the concept that plays its first role, so Order.placed_by links an order to its customer. Multiplicities state that an order is placed by at most one customer, and verbalizations describe each link in plain business language.

Business Rules

Business rules make the ontology precise. requires declares constraints that always hold: amounts are never negative, and every order has a customer and a date. derived_by defines a concept from others, like a view: a LargeOrder is any order that totals 1,000 or more.

Ontology Mappings

Ontology mappings connect concepts to data. Each mapping embeds a semantic model and populates concepts and relationships from its fields. Every row in orders becomes an Order, linked to the Customer who placed it and to its total. Agents can now translate a question about customers into a query on the right tables.

Full Example

Here is the complete e-commerce ontology from the diagram above: value types and entity types, relationships with verbalizations, business rules, and the mapping to the semantic model shown below.

Reference: Apache Ossie Ontology Specification

ecommerce.ontology.ossie.yaml
version: "0.2.0.dev0"
name: ecommerce
description: Business concepts of an online store
ai_context:
  instructions: >
    Use this ontology to understand customers, orders,
    products, payments, and shipments.
    Amounts are always in cents.
  synonyms:
    - "customer: buyer, shopper, client"
    - "order: purchase, sale"
    - "product: item, article"
ontology:
  - concept: Customer
    type: EntityType
  - concept: Order
    type: EntityType

The ontology specification is part of the upcoming Ossie 0.2.0 release (currently 0.2.0.dev0). It includes a JSON Schema for validation and a specification document. Expect changes before the release.

Semantic Models

Semantic models are primarily used in BI tools to describe data for analytics: logical datasets and their fields, the relationships between them, and the metrics calculated on top. Each dataset and field links to the underlying tables and columns, so every metric resolves to the actual data. Expressions can be written in multiple SQL dialects, so BI tools, query engines, and AI agents all calculate revenue the same way.

In a BI tool, the semantic model shows up as named metrics and dimensions that business users can drag into a report:

BI tool · Sales overviewModel: ecommerce
Order date: Last 12 monthsRegion: All
Total revenue · Sep 2026
1.24M
+4.2% vs Aug
Order count · Sep 2026
9,830
+3.7% vs Aug
Avg order value · Sep 2026
126
+0.5% vs Aug
Total revenue by month
00.5M1.0M1.5MOctNovDecJanFebMarAprMayJunJulAugSep1.24M
Total revenue by region · Sep 2026
Europe0.52MNorth America0.41MAsia Pacific0.21MLatin America0.10M
Mockup of a BI tool connected to the ecommerce semantic model. Metrics and dimensions come from the model, so every report calculates revenue the same way.

Each BI tool (Power BI, Looker, Tableau, …) uses its own proprietary format to define semantic models. Apache Ossie defines a common standard that makes them interchangeable. Let's explore an Ossie semantic model step-by-step:

Semantic Model

Every Ossie semantic model starts with a version and a model definition: a name, description, and optional AI context that helps AI agents understand and query the data correctly.

Datasets

Datasets represent logical tables (fact or dimension tables). Each dataset has a source, primary key, and fields. Fields require multi-dialect expressions and can be marked as dimensions.

Relationships

Relationships define foreign key connections between datasets. They specify the "from" (many side) and "to" (one side) datasets along with the join columns, enabling tools to automatically join tables.

Metrics

Metrics are aggregate business measures defined centrally. Each metric has multi-dialect expressions, ensuring consistent metric definitions across all tools, with no more conflicting "revenue" numbers.

Custom Extensions

Custom extensions allow vendor-specific metadata without polluting the core model. Each extension targets a specific vendor (Snowflake, Databricks, dbt, etc.) and stores configuration as a JSON string.

Full Example

Here is a complete Ossie semantic model bringing all elements together: model definition with AI context, datasets with fields and multi-dialect expressions, relationships, metrics, and vendor-specific extensions.

Reference: Apache Ossie Core Specification

ecommerce.ossie.yaml
version: "0.1.1"
semantic_model:
  - name: ecommerce
    description: E-commerce analytics semantic model
    ai_context:
      instructions: >
        Use this model for e-commerce analytics.
        Revenue is always in cents.
        Active customers have placed an order in the last 90 days.
      synonyms:
        - "revenue: total_revenue, sales, income"
        - "customers: buyers, users, shoppers"
      examples:
        - "What was the total revenue last month?"
        - "How many active customers do we have?"
        - "Show me the top 10 products by revenue"

The examples use the released core specification 0.1.1. Version 0.2.0 is in development: each document holds a single model at its root (the semantic_model list is removed), fields and metrics get logical data types, and new dialects such as BigQuery, DAX, and Ossie's own portable SQL are added. See the specification document and the JSON Schema.

Note: Ossie is not yet at version 1.0. We encourage early adoption and feedback, but be prepared for breaking changes in future versions.

Data Products and Data Contracts

Ontologies and semantic models describe what data means. Data products and data contracts describe the data that is actually delivered: who owns it, where it is available, its schema, and the quality and service levels consumers can rely on.

Bitol, a project of the Linux Foundation's LF AI & Data Foundation, maintains two open standards for this layer. Both are licensed under the Apache License 2.0:

Logical

Open Data Product Standard (ODPS)

A data product's identity, owner, and status, with input and output ports that reference data contracts.

Version 1.1.0

Logical

Open Data Contract Standard (ODCS)

The agreement between producer and consumers: schema, quality rules, SLAs, servers, and team.

Version 3.2.0

Each output port of a data product has a data contract. The contract defines the data product from the consumer's point of view: what data they get, where they access it, and which quality and service levels they can rely on.

A semantic model can be a data product

When a semantic model has clear ownership, it can be a data product of its own. Like any other data product, it can be specified and quality-assured through a data contract: the contract describes the metrics and dimensions consumers can use (ODCS 3.2 adds semanticType for measures and dimensions), and its quality rules and SLAs ensure the numbers are correct and fresh.

Let's explore a data contract step-by-step:

Data Contract

A data contract defines a data product from the consumer's point of view. It starts with fundamentals like id, version, status, and the data product it belongs to, describes purpose, usage, and limitations, and lists the servers where consumers access the data, here a Snowflake schema.

Schema

The schema defines tables and their properties with business names, logical and physical types, keys, and classifications. Authoritative definitions of type semantics link the orders table and its identifier columns to concepts of the ontology.

Quality and SLAs

Quality rules turn expectations into executable checks, as SQL queries or predefined metrics such as row counts. The ontology says amounts are never negative, and the contract checks that in the data. SLA properties state freshness, availability, and retention.

Data Product

The data product is what a team owns and offers. Its ODPS file states identity, status, domain, and the owning team, and lists the output ports. Each output port references its data contract by contractId, so the orders port is described by the contract above.

Full Example

Here is the complete data contract for the orders data product: fundamentals, servers, schema with semantic links, quality rules, SLAs, team, and AI context.

Reference: Open Data Contract Standard

orders.odcs.yaml
apiVersion: v3.2.0
kind: DataContract
id: orders
name: Orders
version: 1.0.0
status: active
domain: sales
dataProduct: orders
description:
  purpose: Web shop orders for analytics and AI agents
  usage: Revenue analysis and order volume trends
  limitations: Only orders placed since 2020-01-01
servers:
  - server: production
    environment: prod
    type: snowflake
    account: acme-eu
    database: SALES
    schema: ANALYTICS

The examples are available as orders.odcs.yaml and orders.odps.yaml. Validate a data contract and test your data against it with the open-source Data Contract CLI, edit it in the Data Contract Editor, and manage data products with the Data Product CLI. Learn more about data contracts at datacontract.com.

Data Contract Editor

Create and edit data contracts visually with the open-source Data Contract Editor (GitHub). It provides form, diagram, and YAML views for ODCS data contracts and validates the contract as you edit. It opens with the orders data contract from above.

editor.datacontract.com

Distributing Semantic Data

Semantic data does not live in a single platform. Business definitions need to be integrated into every relevant app, data platform, and AI platform. That is the key to consistency: all platforms share the same semantics, work on the same linked data products, and return the same numbers.

The ontology is curated by domain experts, the people who know what a customer, an order, or a return means in your business.

curateproposalsfeedbackDomain expertsSemanticsOntologySemantic modelsData contractsAppsCRM, ERP, web shopRevenue last month1.24MData PlatformsSnowflake, DatabricksRevenue last month1.24MAI PlatformsAgents, assistants, MCPRevenue last month1.24MSales and serviceAnalysts and controllersManagers and everyone elseBusiness value happens where business users workKnowledge basesDocumentsCodeData ProductsEmailsSemantic agentruns in a loop

Curated by domain experts

Domain experts curate the semantics: the ontology, semantic models, and data contracts, written in open formats such as Apache Ossie and ODCS.

Integrated into every platform

The same definitions are pushed into the knowledge bases and context layers of all relevant apps, data platforms, and AI platforms.

This is where the business value happens: in the tools business users work with every day.

Same numbers everywhere

Every platform works with the same semantics. Ask any of them for revenue last month, and the answer is 1.24M.

A semantic agent reads your knowledge bases

LLMs can extract semantics from existing business knowledge.

Proposals, reviewed in a loop

The agent turns its findings into proposals for the domain experts. Approved changes reach every platform, and feedback improves the next run. This creates a positive feedback loop. Every approved change makes the answers on all platforms more accurate, and every approval or rejection teaches the agent what the experts accept. Over time, proposals get better, reviews get faster, and the semantics keep up with the business.

curateproposalsfeedbackDomain expertsSemanticsOntologySemantic modelsData contractsAppsCRM, ERP, web shopRevenue last month1.24MData PlatformsSnowflake, DatabricksRevenue last month1.24MAI PlatformsAgents, assistants, MCPRevenue last month1.24MSales and serviceAnalysts and controllersManagers and everyone elseBusiness value happens where business users workKnowledge basesDocumentsCodeData ProductsEmailsSemantic agentruns in a loop

Avoid semantic vendor lock-in

Many platforms offer their own semantic layer. Definitions authored there live in a proprietary format: they have to be rebuilt for every other platform, and again when you replace the tool. Keep the source of truth in open formats such as Apache Ossie and ODCS, owned and versioned by your organization, and let each platform consume it.

Frequently Asked Questions

What is semantic data?

Semantic data provides reliable business context for humans and agents. Tables and columns describe how data is stored, but not what it means. Semantic data adds that meaning: the business concepts and how they relate, how metrics like revenue or churn are calculated, and who owns a data product and guarantees its quality.

What is Apache Ossie?

Apache Ossie (incubating) is an industry-driven, vendor-neutral open standard for semantic data. It defines YAML and JSON formats for ontologies and semantic models, so that business definitions stay consistent as they are exchanged between AI agents, BI platforms, and analytics tools. It is developed under Apache Software Foundation governance and licensed under the Apache License 2.0.

Is Apache Ossie the same as Open Semantic Interchange (OSI)?

Yes. Open Semantic Interchange (OSI) was launched by Snowflake and partners in September 2025. In July 2026 the project entered the Apache Incubator and was renamed Apache Ossie to avoid confusion with other projects that share the OSI acronym.

What is the difference between an ontology and a semantic model?

An ontology is conceptual: it describes business concepts, their relationships, and rules, independent of where and how the data is stored. A semantic model is logical: it describes datasets, fields, relationships, and metrics that link to the actual tables and columns, so BI tools, query engines, and AI agents calculate metrics the same way. Ontology mappings connect the two.

What is an Apache Ossie ontology?

An Ossie ontology is a conceptual model of the business. It defines concepts (entity types and value types), relationships between them with multiplicities and verbalizations, and business rules (requires and derived_by expressions). Ontology mappings connect concepts and relationships to the datasets and fields of an Ossie semantic model.

What does an Apache Ossie semantic model include?

An Ossie semantic model includes datasets (logical fact and dimension tables with fields), relationships (foreign key connections between datasets), metrics (aggregate business measures like revenue and order count), AI context (instructions, synonyms, and examples for AI agents), and custom extensions for vendor-specific metadata.

How do Apache Ossie, ODPS, and ODCS fit together?

Apache Ossie ontologies and semantic models describe what data means. The Bitol standards describe the data that is delivered: the Open Data Product Standard (ODPS) defines a data product with its owner and output ports, and the Open Data Contract Standard (ODCS) defines the schema, quality rules, SLAs, and AI context of each output port. ODCS authoritative definitions can link tables and columns to ontology concepts.

What platforms does Apache Ossie support?

Ossie supports multi-dialect expressions for ANSI SQL, Snowflake, Databricks, Tableau, and MDX, with BigQuery, DAX, MAQL, Sigma, ThoughtSpot, and a portable Ossie SQL dialect added in version 0.2.0. Vendor-specific metadata for Snowflake, Salesforce, dbt, Databricks, GoodData, and others is stored in custom extensions.

How does Apache Ossie differ from vendor-specific semantic layers?

Unlike vendor-specific semantic layers, Ossie is a vendor-neutral specification that can be translated to and from any platform. This prevents metadata lock-in and lets the same definitions feed AI, data, BI, and software platforms.

About

This website is maintained by Entropy Data. We are passionate about open standards for data and believe that common semantic standards are essential for the future of analytics and AI.

Our work on data contracts and data mesh has shown us that interoperability requires open, vendor-agnostic standards. Apache Ossie is the next step: ensuring that business semantics travel with the data, regardless of which tool processes it.

The Apache Ossie specification is licensed under the Apache License 2.0. Apache Ossie is an effort undergoing incubation at The Apache Software Foundation (ASF). This website is independent and not an official ASF page. The official project website is ossie.apache.org.