A guide by Datus · Apache Ossie (incubating)

Apache Ossie.An open standardfor semantic models.

Apache Ossie (incubating), formerly Open Semantic Interchange (OSI), is an open, vendor-neutral specification for exchanging semantic models. It describes datasets, fields, relationships, metrics, and business context so compatible tools can work from shared definitions.

Apache-2.0 · Vendor-neutral specification

The standard

Business meaning, beyond a single tool.

A semantic model records how your data represents the business. Apache Ossie gives those definitions an exchange format, so supported analytics platforms, applications, and AI agents can reuse compatible modeling work.

01

A shared format

Keep datasets, calculations, relationships, and context in a readable model document, rather than only inside one product.

02

A common language

Exchange compatible definitions between tools. Review conversion diagnostics and runtime support before expecting equivalent behavior.

03

A clear boundary

The specification describes the model. A compatible runtime still has to validate requests, plan queries, and execute them.

Why use Apache Ossie?

Keep business definitions reusable.

Keep using your BI and analytics tools. Ossie provides a shared format for the compatible definitions you want to review, maintain, and reuse across them.

How teams work today

Maintain definitions separately in each BI or analytics tool.

What Ossie adds

Represent compatible datasets, metrics, and relationships in a shared model, reducing repeated modeling work.
1 / 3

Ossie defines the exchange format; DOSI provides execution for compatible models. Neither replaces your BI tools or warehouse. Conversion coverage and calculation behavior still need validation in the target runtime.

Explore supported conversion paths
Inside an Ossie model

More than a metric name.

The model connects physical data to business meaning. Its definitions give both people and software something explicit to inspect.

Ossie models can be written in YAML or JSON. Each document declares its specification version; check that version against your validator and intended consumer.

northstar-explained.yaml

Highlighted: Datasets

# Educational subset adapted from the Northstar Premier demo.
# Source queries, field expressions and booked_revenue are preserved.
# Root layout updated; ai_context is an added explanatory annotation.
version: 0.2.0.dev0
name: northstar_premier_excerpt
description: Northstar retail orders and booked revenue — educational subset
datasets:
  - name: customers
    source: northstar_living.dim_customer
    primary_key:
      - customer_id
    fields:
      - name: customer_id
        datatype: Integer
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: customer_id
        dimension: {}
      - name: city
        datatype: String
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: city
        dimension: {}
  - name: orders
    source: SELECT o.* FROM northstar_living.fct_orders o JOIN northstar_living.dim_customer c
      USING(customer_id) WHERE o.status='delivered' AND NOT o.is_test AND
      o.delivered_at>=DATE '2025-09-20' AND o.delivered_at<DATE '2026-09-20' AND NOT
      c.is_employee AND c.identity_status='resolved' AND EXISTS (SELECT 1 FROM
      northstar_living.fct_order_lines l WHERE l.order_id=o.order_id AND
      l.delivered_qty>0)
    primary_key:
      - order_id
    fields:
      - name: order_id
        datatype: Integer
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: order_id
        dimension: {}
      - name: customer_id
        datatype: Integer
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: customer_id
      - name: ordered_at
        datatype: Date
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: ordered_at
        dimension: {}
  - name: lines
    source: SELECT l.* FROM northstar_living.fct_order_lines l JOIN
      northstar_living.fct_orders o ON l.order_id=o.order_id JOIN
      northstar_living.dim_customer c ON o.customer_id=c.customer_id WHERE
      o.status='delivered' AND NOT o.is_test AND o.delivered_at>=DATE '2025-09-20' AND
      o.delivered_at<DATE '2026-09-20' AND NOT c.is_employee AND
      c.identity_status='resolved' AND l.delivered_qty>0
    primary_key:
      - order_line_id
    fields:
      - name: order_line_id
        datatype: Integer
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: order_line_id
        dimension: {}
      - name: order_id
        datatype: Integer
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: order_id
      - name: gross_sales_cents
        datatype: Integer
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: gross_sales_cents
      - name: discount_cents
        datatype: Integer
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: discount_cents
relationships:
  - name: lines_to_orders
    from: lines
    to: orders
    from_columns:
      - order_id
    to_columns:
      - order_id
  - name: orders_to_customers
    from: orders
    to: customers
    from_columns:
      - customer_id
    to_columns:
      - customer_id
metrics:
  - name: booked_revenue
    expression:
      dialects:
        - dialect: ANSI_SQL
          expression: SUM((lines.gross_sales_cents-lines.discount_cents)*0.01)
ai_context:
  instructions: Booked revenue uses gross sales less discounts, in currency units. Inspect
    source filters and do not treat booked revenue as customer margin.
  synonyms:
    - booked sales
    - sales before refunds

Click an attribute to locate its definition. This example covers the five core categories shown here, not every optional Ossie property. It preserves selected Northstar source queries, fields, relationships and booked_revenue. The root layout is adapted to the current draft; ai_context is an explanatory annotation added for this page. It is not the complete nine-table production demo.

A portable definition is a starting point. Each consumer must support the model features and expression language it uses.

Explore a complete semantic model

Connect calculations to business concepts.

The core semantic model describes datasets, fields, metrics, and their data relationships. The separate ontology specification describes business concepts, roles, relationships, and rules; mapping documents connect that conceptual model to semantic models.

01

Business concepts

Customer → places → Order

Describe what things mean and how they relate, beyond a physical table name.

02

Ontology mappings

Concepts & roles ↔ datasets & fields

Connect the conceptual business vocabulary to its representation in semantic models.

03

Semantic definitions

orders.amount → revenue

Make source mappings and calculation expressions explicit for compatible consumers.

Descriptions and synonyms in ai_context help interpretation, but are not a substitute for the ontology specification. Consumers need to document which ontology and mapping features they implement.

Read the upstream ontology specification
How interoperability works

One shared format. Fewer translations.

Instead of maintaining a separate translation for every pair of tools, use Ossie as the common exchange format. A supported converter imports or exports the definitions that its source and destination can represent.

Convert models with Datus’s workbench.

Datus’s conversion workbench includes these example paths. They move model definitions—not the underlying data. Import and export coverage are maintained separately.

For example: Cube YAML → Ossie → Snowflake Cortex Analyst format. In this workbench Snowflake Cortex Analyst is export-only; raw dbt project YAML is not an accepted dbt import. Review diagnostics, then validate and test in the destination. Availability follows the live tool catalog.

Project & community

An open standard, built in public.

  1. Open Semantic Interchange announced

  2. Public repository opens

  3. Apache Ossie (incubating)

Launched as Open Semantic Interchange in 2025, the project later became Apache Ossie (incubating). It remains in the Apache Incubator; the specification continues to evolve.

Development and decisions happen in public. The ecosystem includes Snowflake, Salesforce, dbt Labs, Microsoft, Databricks, Datus, and others; implementation support varies. Anyone can discuss proposals, report issues, or contribute.

How Datus uses Apache Ossie

From open definitions to agent action.

DOSI turns compatible Apache Ossie definitions into native SQL. Within Datus, that runtime sits alongside Datus Agent and Studio: agents work with shared business meaning, while teams build, review, and inspect the context behind their work.

Existing knowledge

Documents
SQL & ETL
Warehouses
Datus

Datus Studio

A shared workspace for Agent-driven data engineering.

Datus Agent

A complete data Agent for engineering and analysis.

Ontology + semantic model

DOSI Engine

Execute compatible Ossie definitions as native SQL.

Apache Ossie Spec

An open, vendor-neutral semantic modeling specification.

Put context to work

Teams
AI agents
Applications & BI

Apache Ossie (incubating) is an Apache Software Foundation project maintained by its community, not a Datus-owned product. This diagram shows how Datus uses the specification: DOSI executes compatible definitions. Datus and DOSI are independent of the ASF and are not ASF-endorsed products.

Apache Ossie

The open specification describes semantic models and ontology. It does not execute a query by itself.

DOSI

The semantic runtime validates compatible definitions and compiles supported requests into native SQL. It can also be used independently.

Datus

Studio provides a shared workspace; Datus Agent carries out data engineering and analysis. Modeling is one part of that workflow.

Ossie defines the metadata. MCP, API, and CLI access are supplied by implementations, not automatically by an Ossie file. Shared context helps ground analysis; it does not guarantee an error-free answer.

Inspect DOSI execution
Native execution with DOSI

The specification defines it. DOSI runs it.

DOSI is Datus’s semantic execution runtime, available within Datus and independently. It reads compatible Ossie definitions, validates supported requests, and compiles them into native SQL for the configured data source.

01

Read the model

Use datasets, metric expressions, and declared relationships as inputs.

02

Validate & plan

Check the request and plan supported joins and aggregations; report unsupported cases explicitly.

03

Generate native SQL

Inspect the SQL before choosing to execute it against your configured source.

How native Ossie execution works

Watch the DOSI walkthrough to follow the product workflow.

Watch on YouTube
Run the full quickstart
Choose your starting point

Start with the knowledge you already have.

You can build a model from existing work or bring compatible definitions from another tool. Keep your team in the review loop.

01

Build from your data work

Use Datus Agent to help draft definitions from SQL, supported BI queries, documents, and new requirements. Review the model in your workflow.

Explore the modeling workflow
02

Bring an existing model

Use supported import paths for existing semantic artifacts. Inspect the output and diagnostics, then validate it in the intended runtime.

Open the conversion workbench
03

Try one executable example

Start with a small model and an inspectable SQL query. Connect your own source after you understand the model and execution boundaries.

Follow the Ossie + DOSI quickstart
Compatibility, made explicit

Open definitions. Documented boundaries.

Using the same format does not mean every tool implements every feature or computes every query the same way.

The standard and the product have different licenses.

Apache Ossie is the open specification developed at the Apache Software Foundation. DOSI uses Elastic License 2.0. Datus Agent is open-source under Apache-2.0. Datus and DOSI are independent products, not ASF projects or ASF-certified implementations.

LayerWhat to check
Apache Ossie coreValidate the document against the upstream schema and the specification version it declares.
DOSI runtimeCheck supported expressions, query behavior, source adapters, and execution requirements in the current documentation.
Datus extensionsAdvanced capabilities may use the specification’s extension mechanism. Other tools may not interpret these extensions.
Conversion pathsImport and export are separate capabilities. Review fields, dependencies, diagnostics, and any unsupported semantics.
FAQ

Questions about adopting Apache Ossie

Does an Apache Ossie document execute a query by itself?

No. An Ossie document describes semantic definitions; it is not a query runtime. A compatible engine must interpret the supported definitions, validate the request, plan the calculation, and generate or execute a query. DOSI provides that execution path for compatible models and supported requests.

How should I interpret the older name Open Semantic Interchange?

Open Semantic Interchange, often shortened to OSI, is the earlier name of the initiative now developed as Apache Ossie (incubating). Older articles, paths, and commands may still use OSI. A shared name history does not guarantee that every historical model shape is compatible with today’s specification; check the document version and current validator.

Can I use Apache Ossie without adopting the full Datus platform?

Yes. The specification is vendor-neutral and is developed independently of Datus. Choose a consumer that supports the definitions and behavior you need. DOSI can be used independently of Datus Studio through its supported interfaces; it does not require adopting the complete workspace to compile a compatible model.

What should I verify before reusing a converted model?

Check the source artifact, model version, relationships, expressions, and conversion diagnostics. Then validate and test the intended queries in the target runtime. A successful conversion does not by itself establish equivalent filters, timezone handling, extension support, or results across tools.

Is Datus’s ecosystem listing an Apache certification?

No. The Apache Ossie ecosystem lists organizations and their work with the specification. Datus appears there for DOSI, its quickstart, and Datus Agent. That listing is not an ASF certification or endorsement of the products. Apache Ossie is an incubating Apache project; Datus and DOSI are separate products.

What does an Apache Ossie YAML file look like?

It declares a specification version and model name, then describes datasets and fields, with relationships, metrics, and context as needed. YAML and JSON are both supported. The downloadable example on this page uses the 0.2.0.dev0 document shape and was checked with DOSI 0.2.0. Older examples may use a different wrapper; validate the version before reuse.

How does Apache Ossie differ from the dbt Semantic Layer?

Apache Ossie defines an open format for exchanging semantic metadata. The dbt Semantic Layer provides a modeling and metric-querying system. Supported converters can move compatible definitions between formats; coverage, expressions, and execution behavior still need validation. Our comparison guide explains the different roles.

How do AI agents use Apache Ossie metadata?

Agents can inspect the declared fields, metrics, relationships, descriptions, and AI context, then submit supported requests to a compatible consumer or runtime. DOSI supplies an execution path for compatible definitions. The document itself does not provide an agent protocol or guarantee correct answers.

Which companies support Apache Ossie?

The official ecosystem directory lists participants including Datus, Databricks, dbt Labs, Microsoft, and Salesforce. Inclusion does not mean every organization offers the same integration. Check the linked implementation details for import, export, native reading, and execution support.

How does the Ossie hub-and-spoke model work?

Ossie is the shared document format at the hub; converters connect vendor-specific formats as spokes. This reduces the need to build a separate converter for every pair of tools. It does not require a central data service, and unsupported semantics may still need changes after conversion.

Put open definitions to work

Give teams and agents business meaning they can use.

Build and review context with Datus, or start independently with the DOSI quickstart.