OKF vs Apache Ossie: Which Format Should Describe Your Data Model?

The short answer

Most teams will want both, for different jobs: a model your tools exchange, and a description your agents and colleagues can read. Neither replaces the other, and both are young. OKF’s specification in Google’s repository is at version 0.2, and it changed two v0.1 fields on the way. Apache Ossie is an incubating project whose current specification is an unreleased draft, 0.2.0.dev0.

What each one is

OKF, the Open Knowledge Format, was published by Google Cloud’s Data Cloud team on 12 June 2026. It is a directory of markdown files with YAML frontmatter, one concept per file, where only a type field is required. Files link to each other with ordinary markdown links. The announcement described version 0.1 as “a starting point, not a finished standard”, and the specification in the repository has since moved to 0.2, which adds optional provenance, trust and lifecycle fields. For the full picture, see what OKF is.

Apache Ossie, formerly the Open Semantic Interchange, is an open specification for exchanging a semantic model between BI tools, query engines and AI agents. A file has datasets, fields, relationships, metrics and ai_context. What Apache Ossie is explains it, and how to read an Ossie file walks through one.

An OKF bundle can also say which version it targets: the specification lets the root index.md carry okf_version: "0.2", and tells a consumer that does not understand the version to read the bundle as best it can instead of refusing it. Ossie takes the opposite approach, a version string that is required on every document, and Snowflake’s and dbt’s documentation both say a version they do not support is an error.

Neither belongs to OWOX. The OKF and Ossie files in this article were written by the OWOX Model Canvas, which is one producer of each; another tool may write the same format differently.

Side by side

Only cells we could verify from the format’s own documentation or from a file we produced are filled in.

The same model in both formats

Take store_sales from the TPC-DS file. In Ossie, a metric is an entry in the model’s metrics list:

- name: total_sales
  expression:
    dialects:
      - dialect: ANSI_SQL
        expression: SUM(store_sales.ss_ext_sales_price)
  description: Total sales revenue across all transactions
  ai_context:
    synonyms: ["total revenue", "gross sales", "sales amount"]

The canvas’s Export menu offers both formats:

Exported to OKF, the model becomes six markdown files: an index.md and one per dataset. The same metric is a section of store-sales.md:

### `total_sales` · NUMERIC · Metric

Total sales revenue across all transactions

Synonyms: total revenue, gross sales, sales amount

```sql
SUM(ss_ext_sales_price)
```

Same name, same meaning, same SQL. What changed is what each file lets a tool do. The Ossie entry is a field in a list, so a converter can read expression.dialects and know where the formula starts and ends. The OKF section is prose with a code block, which an agent reads easily and a converter has to parse by convention.

What survives the conversion

We counted. The starting file was examples/tpcds_semantic_model.yaml from the Apache Ossie repository: 5 datasets, 4 relationships, 8 metrics, 619 non-empty lines.

Importing the OKF bundle back gave the same counts, as the dialog shows before you confirm:

The OKF files the canvas writes use type, title, description and tags, and none of the provenance, trust or lifecycle fields that version 0.2 defines, so a model that goes through the canvas picks up no record of where its definitions came from. Two things stand out. First, nothing numeric was lost: the counts match in both directions, and the importer listed no warnings on the OKF round trip. Second, the losses are all the structure that tools rely on and prose does not hold: the typed ai_context, the time-dimension flags, the extra key declarations and the vendor blocks.

One formula also changed shape. In the Ossie file the metric reads SUM(store_sales.ss_ext_sales_price); in the OKF page it reads SUM(ss_ext_sales_price), because the canvas places the metric on store_sales and drops the dataset prefix. A formula that reads from another dataset keeps the prefix.

Round trips inside Ossie lose things too. Exporting the TPC-DS model back to Apache Ossie produced a file that passes the repository’s own validation/validate.py, with the same datasets, relationships and metrics, and the same 0.2.0.dev0 version string, but 519 lines against 672, with structured ai_context flattened into descriptions and the unique_keys gone. So “lossless” depends on what you count.

A second model, with metrics

The TPC-DS file is a benchmark, and its metrics are the textbook kind. So we wrote a second, smaller Ossie model of the OWOX demo shop with three revenue metrics (gross, excluding cancelled, net), one of them a conditional sum across two datasets, and sent it through the same conversion. It passes validate.py.

Two results matter for the choice. The formulas survive both ways, so a metric defined in Ossie is not lost on the way to a human-readable page. And the type guess is wrong in both: line_revenue is a number, and both exports call it a string. The Ossie specification says to omit datatype when a type is unknown, so the canvas’s default goes against that. Type your fields in the file before you convert it.

What OKF 0.2 adds that neither export uses

The specification in Google’s repository, version 0.2, adds optional frontmatter for where a definition came from and whether anyone checked it: sources, generated, verified, status and stale_after. It also describes an Attested Computation concept, with a runtime and parameters, as a way to record the sanctioned way to compute a value. The Ossie specification’s root has version, name, description, ai_context, datasets, relationships, metrics and custom_extensions, and nothing for provenance. The OKF files the canvas writes use none of the 0.2 fields.

That is a gap worth knowing about, in either direction. If it matters who defined a metric and when, OKF has a place for it that Ossie lacks, and a converter that does not write it throws it away.

A template, both ways

The TPC-DS file is a benchmark. For something closer to a working shop we used the canvas’s E-commerce template: 12 datasets and 14 relationships.

Neither file contains the SQL that defines the datasets. In the Ossie export, each dataset’s source is the dataset’s title, such as Orders, and the OKF pages state a definition type of SQL without showing it. That is a property of the template, which is a model of the shop and not a query against one, but it is a reminder of what these files hold. They describe a model. They do not hold the transformation that builds it.

The template’s calculated fields, such as completed_orders and completion_rate, appear as plain fields with a description in both files, not as formulas.

Which to use when

• An AI agent needs to understand your model. Give it OKF. It is plain text that explains what each table and column means and how tables join, and the agent does not need a parser.
• Two or more tools need the same metric definitions. Use Ossie, with the version those tools actually read. The vendors do not agree on one yet, which the explainer lays out.
• You must keep the typed structure. Keep the Ossie file as the source and produce OKF from it, not the other way round. Our run shows which parts the other direction drops.
• You need to record who defined a metric and when. OKF 0.2 has frontmatter for provenance and verification, and Ossie’s root has no equivalent, so keep that record in OKF or in your own extension.

If you only review changes in git, either works: OKF diffs read like documentation and Ossie diffs read like configuration. A small team starting from nothing can write the model once in a tool that exports both, then hand each reader the format it reads best, without maintaining two copies by hand.

The Model Canvas opens either format and exports both. For how OKF compares with dbt exposures and LookML, see OKF vs dbt exposures vs LookML.

Data ModelingWhat Is Apache Ossie? The Open Standard for Semantic Models, ExplainedOctober 19, 2026→Data ModelingBenefits of Data Modeling for Business ReportingMarch 3, 2025→Data ModelingBest Data Modeling Tools in 2026July 21, 2026→

See all articles →