Re: [D] Shared Semantics OSI [ossie]

["anykolaiszyn (via GitHub)" <gi...@apache.org>]

GitHub user anykolaiszyn added a comment to the discussion: Shared Semantics OSI

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](https://github.com/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.


GitHub link: https://github.com/apache/ossie/discussions/108#discussioncomment-18823509

----
This is an automatically sent email for dev@ossie.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@ossie.apache.org