The Semantic Interchange Moment

For years, the meaning of your data — what a metric measures, which dimension a field belongs to, which values a status is allowed to take — has lived inside whichever tool happened to define it. That is finally changing: open specifications for semantic models, data contracts, and domain schemas are converging on one idea — meaning should travel. CoreModels is built for exactly that moment.

Your metrics have a vendor

Ask three tools in your stack what "active customer" means and you will get three answers — or worse, three copies of the same answer that drifted apart last quarter. The definition lives once in your BI tool's modeling layer, again in a warehouse view, again in a pipeline's YAML, and each copy is written in a dialect only its host understands. The semantics are real intellectual property — the accumulated judgment of your analysts, engineers, and domain experts — but they are stored in formats that were never designed to leave.

That is vendor lock-in of the most subtle kind. Nobody is holding your rows hostage; data moves freely. It is the meaning that can't move: the enum that says which order states exist, the constraint that says a key is required, the relationship that says these two tables describe the same customer. Rebuild your stack and you rebuild your semantics from memory.

The industry response: open interchange

The last few years have produced a wave of open specifications aimed squarely at this problem, each from a different corner of the industry:

• Apache Ossie (formerly OSI) defines a vendor-neutral semantic model — datasets, fields, dimensions, per-dialect expressions — so the definition of a metric can exist independently of any one analytics tool.
• ODCS, the Bitol Open Data Contract Standard, expresses data contracts as versioned v3 YAML documents: what a dataset promises, property by property, with logical types and requiredness spelled out.
• LinkML gives the sciences a YAML schema language with classes, attributes, and permissible-value enumerations — modeling rigor without a proprietary runtime.
• ODM takes the documentation-first path: data models authored as Markdown documents that machines can nonetheless read.

These specs come from different communities and make different trade-offs, but they share a premise: semantic definitions belong in open, inspectable text that any conformant tool can read. We think that premise is right, and we have voted with our engineering time.

To be clear about our position: CoreModels implements these specifications. We are not speaking for any of these projects or claiming a seat in any standards body — we read their published specs carefully and built coders that honor them. Neutral interoperability is the point.

Model meaning once, speak every dialect

CoreModels, by ARAMAI, is a governed schema graph with a fourteen-format transformation engine attached. You model your types, elements, taxonomies, and relationships once, and the engine encodes and decodes that model across JSON Schema, ShEx, Avro, JSON-LD, SQL DDL (Postgres, MySQL, or SQL Server dialects), Apache Ossie semantic models in both YAML and JSON, OWL ontologies, LinkML, Protocol Buffers, ODCS data contracts, ODM documents, and Synapse schemas.

The interchange formats are not bolted on; they are first-class citizens of the same engine that handles the workhorse formats. A few examples of what that means in practice:

• The Ossie coder pins its output to spec version 0.1.1, tracked against the published schema in the Apache Ossie repository — and its JSON serialization (osi-json) is the form dbt ingests, so a governed model can flow straight toward the analytics layer. Documents carrying a legacy version string that never existed in the spec are normalized to 0.1.1, and the normalization is reported rather than hidden.
• The ODCS coder emits contracts pinned to apiVersion v3.1.0 of the Bitol standard, and it is deliberately forgiving on the way in: unknown keys in a contract are preserved verbatim rather than rejected, so an ODCS document you wrote elsewhere can never break parsing just because it uses a corner of the spec we don't model.
• LinkML exports carry your enumerations as proper permissible-value lists and your requiredness as required: true — the things a scientific data manager actually checks.
• ODM is decode-only by design, because ODM entities are authored documentation, not a generated artifact. We read them; we don't pretend a machine should write them for you.

All of this is reachable the ways you would expect: over the authenticated HTTP transform surface — schema import, export, and stateless mapping — and over MCP through the OAuth-protected /mcp endpoint, where tools like transform_schema and export_linkml put the whole engine in reach of any agent. No state is written unless you ask for it.

Honest lossiness, or: formats disagree and we say so

Here is the uncomfortable truth every "universal translator" glosses over: these formats do not agree on what a schema is. Postgres has no inline enum type. The Ossie spec has no controlled-list construct at all. Proto3 has no date-time scalar. A converter that claims perfect fidelity across all of them is lying to you somewhere.

CoreModels takes the opposite stance. Every transformation returns a lossiness ledger alongside its output: a list of records, each naming what happened, where, and why. There are exactly four kinds — a structural drop (something had no home in the target), a type approximation (a close-but-not-exact type stood in), a constraint relaxation (a rule couldn't be enforced and was loosened), and a semantic narrowing (meaning was narrowed or guessed).

So when a customer schema with a three-value status enum becomes a Postgres table, the status column arrives as VARCHAR and the ledger says so, in plain language: Postgres has no inline enum; the allowed-value constraint is not enforced. When the same schema becomes an Ossie semantic model, the ledger records that the controlled list isn't representable there either. Our own documentation puts it bluntly: a successful response does not mean "nothing changed" — it means "it ran." Always read the lossiness.

We think this honesty is a feature you should demand from any interchange tooling. A translation you can audit is worth ten you have to trust.

No lock-in — including ours

A platform preaching open interchange had better practice it, so we hold ourselves to the same standard we hold the ecosystem to.

Everything you model in CoreModels leaves as standard artifacts: JSON Schema, LinkML YAML, ODCS contracts, Ossie models, OWL, Avro, Protocol Buffers, SQL DDL. There is no proprietary export format you would need us around to read. If you walk away tomorrow, you walk away with your semantics in the open formats this article is about.

Mapping between schemas produces a replayable plan — a stored artifact that, given the same source, provably produces the same output every time. Your migration logic is yours, inspectable and repeatable, not a black box inside our service.

And changes to meaning stay human-gated. Map-imports run as dry runs before anything is written. When our AI-assisted mapping proposes a plan, the same validation gate that checks a hand-written plan checks the AI's — its self-reported confidence is advisory, and the gate never trusts it. Ontology term suggestions are advisory only; binding a term to your model is a separate, explicit act by a person with the authority to make it. Semantics are too important to change by side effect.

The moment is now

Open semantic interchange has moved from manifesto to published, versioned specifications with real implementations behind them. The organizations that benefit first will be the ones whose meaning is already modeled once, in a form that can speak every dialect — with an honest account of what each dialect can and cannot carry.

That is what we built CoreModels to do.

To try it against your own schemas, start with the CoreModels docs and the per-format quickstarts.