Open Semantic Interchange

A semantic model lands in your repository: a YAML file with datasets, fields, a primary key, and a couple of time dimensions. It is the analytics team's description of what the warehouse *means*. Now somebody needs it as a table definition, or as JSON Schema for a validator, or as the JSON serialization dbt ingests. This walkthrough takes you from that file to a converted schema with one HTTP call - and, just as importantly, to a machine-readable ledger of everything the conversion did and did not preserve.

Four verbs cover everything you will do with an Apache Ossie semantic model through the CoreModels API, and picking the right one is mostly a question of *where the schema lives*. Is it a file you have? Import it, or map it statelessly. Is it a governed model in a CoreModels project? Export it. Do you need the same conversion again next month, byte for byte? Replay a stored plan.

Here is the request, as an analyst actually phrases it: *"Take the billing semantic model in our repo, give me the JSON form our dbt project ingests, and tell me what didn't survive the conversion."*

Run an Ossie conversion twice and diff the two outputs. If the bytes differ, the conversion cannot live in a pipeline - you would be re-reviewing generated files every build. CoreModels (by ARAMAI) gives you the other answer, and it comes from three deliberate design choices: the encoder is hand-written with fixed key order, the mapping plan is returned as an artifact you can store, and replaying a stored plan runs the same validation gate as the call that produced it.

An Apache Ossie semantic model and a typed intermediate representation disagree about the world in one fundamental way: an Ossie field has no type. It is a name, an optional expression, an optional description, and optional dimension metadata. The IR that CoreModels (by ARAMAI) moves schemas through is typed, and so is every neighboring format - SQL, Avro, JSON Schema, LinkML.