Shared Semantics OSI

[NewEngram]

OSI solves structural interoperability — any tool can read and write semantic models in a common format. What it does not solve is conceptual interoperability. When one semantic model defines a field as security_type and another calls the same concept instrument_class, both are structurally valid OSI. But a consumer still has to reverse-engineer that they mean the same thing. At scale, this manifests as a significant integration cost.

The problem is not theoretical. In financial services, dozens of data providers and institutions independently model the same core concepts — trades, positions, instruments, claims — with no shared vocabulary to anchor them. Every integration rediscovers the same mapping problems. The structural standard gives us a wire format; it does not give us a shared language.

The need is already recognized outside of OSI. FIBO (Financial Industry Business Ontology), for example, provides thousands of open, industry-vetted concept definitions in OWL/RDF ontology format. Efforts like this confirm the demand for shared vocabularies — but these concepts are not yet consumable within an OSI semantic model.

Concept-level standards are not a silver bullet. Not every concept lends itself to standardization — some carry nuance, some embed intellectual property, and some vary enough across contexts that consensus may not be possible. But standardizing even the common core would meaningfully reduce integration friction, particularly when coupled with parallel developments on the OSI roadmap like ontology support and composability.

Concretely, this could take the form of a governed reference dictionary of concept definitions — organized by industry vertical, starting with financial services — that OSI models can optionally cite. Not a schema extension. Not a mandate. A shared vocabulary that gives model authors a common starting point and gives model consumers a basis for alignment without reverse-engineering field names.

This is a gap in the standard. Data providers, platform vendors, and consumers stitching models together are all dealing with it. this discussion is about how we can address this gap.

[jklahr]

I am curious of the "semantic_mappings" element proposed in the Extended Metadata proposal would allow for this: https://docs.google.com/document/d/1DLuteF0WwlVbpD5kmHhcqa6vItqNFL4MoAQrImy6dKo/edit?tab=t.0#heading=h.ormr47seafi

For example:

semantic_mappings:
  - source: https://github.com/edmcouncil/fibo/blob/master/SEC/Equities/EquityInstruments.rdf
    identifier: Dividends

[anykolaiszyn]

Everyone in this thread has lived the moment this discussion describes. A consumer opens two perfectly valid models, finds security_type in one and instrument_class in the other, and spends a week proving they mean the same thing. The wire format did its job. The language didn't exist.

So I'm for this. A governed reference vocabulary that models can cite, not a schema extension, not a mandate. That's the right shape.

But I want to name a trap before we walk into it, because I've watched it swallow glossary programs for twenty years: identifying a concept is not the same as agreeing on its meaning.

Take gross margin. Ask a product lead, a services lead and a controller for it and you'll get three confident numbers: 34%, 22%, 31%. All three are right. All three divide revenue minus cost by revenue. "Cost" means landed goods in one, technician labor in another, total cost of revenue in the third. Stamp all three with a shared identifier for Gross Margin and you've told a consumer they're the same thing. They aren't. They can't be averaged, they can't be compared, and one of them is the only one allowed near a board deck. The shared identifier is true and dangerous at the same time.

That's the distinction I'd ask this proposal to hold onto. There are three jobs here, and they belong to three different owners:

Job	Question it answers	Owner
Interchange standard	How is a model, a concept and a mapping written down and moved?	Ossie
Reference vocabulary	What does the industry mean by instrument or claim?	FIBO and its cousins, cited, not copied
Organizational governance	Which local interpretation is approved, where does it apply, what may it be compared with, and what should a tool do when a question doesn't settle it?	The organization, above the file

@jklahr, semantic_mappings looks like the right hook for the second job. I'd want to see how it sits alongside the ontology spec's existing external identifiers and model-to-ontology mappings so we end up with one door, not two. And I'd push for two things on whichever door we keep:

• A mapping relationship, not just a target. Exact, broader, narrower, context-dependent. SKOS already solved this. Without it we've swapped guessing-from-field-names for guessing-from-shared-IDs, and the second guess is more confident.
• A pointer to the governing local definition. Not a governance framework baked into Ossie, just a portable way to say "the thing that decides what this metric means in our house lives here." ODCS has authoritativeDefinitions for exactly this. Ossie has custom_extensions, which works but makes every vendor invent the convention.

Full disclosure: this is the gap I've been working in the open at Semantic-Management/framework, an early, technology-independent operating model for ownership, perspectives, approved use, and what a consumer does when context can't choose. It is not an interchange format and not an ontology. Its one rule is the one gross margin taught me: two things can be true, and when context can't select one, ask. Ossie is the preferred interchange target in it, not a competitor.

The boundary I'd propose for this discussion:

Standardize how a semantic assertion is expressed and exchanged. Don't make the standard decide whose assertion is authoritative.

The first is a format problem and Ossie should own it. The second is an organizational problem, and no file format has ever been able to own it.

Happy to bring two worked cases if it helps: one where differently named fields genuinely mean the same thing and a shared reference closes the gap cleanly, and one where a shared concept has legitimate local interpretations that must stay distinct. The proposal should pass both.