Rosetta Stone vs. Apache Ossie

Rosetta Stone and Apache Ossie both exist to solve semantic fragmentation: the problem that every system describes the same information in its own way, so combining data across systems means writing custom translation for each pair. Both replace N×N custom integrations with N mappings to a single shared definition, and both are pitched as “define once, use everywhere.” They solve it at different layers. Rosetta Stone normalizes the data itself—the rows and schemas. Ossie standardizes the metadata that describes data—the definitions of metrics, dimensions, and joins. This page explains the distinction so you can reason about where each fits.

​

What each one is

​

Rosetta Stone

Rosetta Stone is Narrative’s schema normalization system. It takes data in each source’s native format and translates it to a common schema at query time, so you can query, combine, and analyze data from many sources without building an integration for each one. It works through two primitives:

• Attributes are standardized field definitions—the common schema. An attribute like hl7_gender has a defined type system (string, long, double, boolean, timestamptz, object, array), supports enums, and can compose other attributes through $ref.
• Mappings connect a specific dataset’s columns to attributes, including any SQL transformation needed to convert values. Machine learning suggests mappings, people curate them, and an AI confidence score rates how well each mapping fits.

When you query narrative.rosetta_stone, the platform rewrites the query for each source dataset, executes it, normalizes the results, and unions them. Rosetta Stone runs the transformations and enforces validations—it is an operating feature of the platform, not a document you hand to another tool.

​

Apache Ossie

Apache Ossie (incubating) is the Apache Software Foundation home of the Open Semantic Interchange (OSI) initiative, launched by Snowflake and partners in September 2025. It is a vendor-neutral YAML/JSON specification for exchanging semantic models across BI and AI tools. Version 0.1.1 was released in December 2025, with later versions in active development, and roughly 50 organizations back it—Snowflake, Salesforce, dbt Labs, Databricks, Oracle, and ThoughtSpot among them. An Ossie document describes a semantic_model made up of:

• Datasets with a source and primary or unique keys
• Fields with SQL expressions written per dialect (ANSI SQL, Snowflake, Databricks, MDX, Tableau, MAQL)
• Relationships describing foreign-key joins, including composite keys
• Metrics defined at the model level
• ai_context—instructions, synonyms, and examples that help LLMs use the model correctly
• custom_extensions for vendor-specific metadata

Ossie is a format plus converters. It has no runtime and no execution engine; each tool reads the YAML and interprets it. Ossie never touches or transforms row data.

​

The core difference

The clearest way to separate them: Rosetta Stone transforms the rows, Ossie describes the definitions. A concrete example of each job:

• Rosetta Stone turns "M" and "F" into male and female, or Fahrenheit into Celsius. It reconciles the data.
• Ossie records that Revenue = SUM(orders.amount) so your dbt models, Tableau dashboards, and AI agents all compute revenue the same way. It reconciles the definitions.

​

Where the differences matter

Problem axis. Rosetta Stone normalizes heterogeneous data so it can be combined. Ossie keeps a single definition consistent across the tools that consume it. Neither does the other’s job: Ossie leaves the row data untouched, and Rosetta Stone does not distribute metric definitions to third-party BI tools. Spec versus system. Because Ossie is a specification, its value depends on each tool implementing it, and translation burden falls on model authors, who write an expression per dialect. Because Rosetta Stone is a system, it centralizes that burden—one mapping expression, and the platform handles execution across sources. Scope of collaboration. Rosetta Stone normalizes data across sources whether those sources are external partners or internal teams. Ossie is primarily about agreement across tools within one organization—your dbt project, your BI layer, and your AI agents settling on one metric definition—though working groups on composability and catalogs may broaden that over time. Maturity and governance. Ossie is open and portable but early, and shaped by committee. Rosetta Stone is operational today, but its attribute catalog and mappings live inside the Narrative platform.

​

Complementary, not competitive

These two do not compete for the same job. Ossie deliberately leaves out the layer Rosetta Stone owns—actually normalizing heterogeneous data at query time—and Rosetta Stone does not aim to be a portable interchange format for BI and AI tools. That leaves room for them to work together. Ossie could plausibly become a format Narrative reads and writes: exporting Rosetta Stone attribute definitions as an Ossie semantic model would let downstream BI and AI tools consume Narrative’s normalized schema through an open standard, while Rosetta Stone continues to handle the normalization itself.

​

Related content

​

External references

• Apache Ossie (incubating)
• Ossie Core Metadata Specification
• Open Semantic Interchange launch announcement