Discussion: How do we expect OSI to be used

[willpugh]

I'm wondering how we expect OSI to be use. As we move forward, I think that it affects how we reason about and rank solutions.

I see two different approaches that are implicit in some of the discussions I've seen and proposals:

1. OSI is an interchange format. Mainly used to help with conversions, and provide one place to consolidate models from different tools, but does not specify its own semantics or execution model. Vendors can have radically different expression languages, so extension is easy, but ensuring everything acts the same is hard.
2. OSI is a standard like SQL. In this approach, there are semantics, expression language, etc. Vendors are expected to implement the standard, and for the most part, one expression should work across compliant vendors. Vendor extensions can come in new functions and metadata, but semantics MUST comply with the standard.

Clearly approach 1 is easier as a standards body to implement, however, from the meeting a week ago, I got the impression that we think approach 2 is more valuable.

Do folks generally agree with that? or is this contentious?

I bring this up, because there are already things in the proposal that seem to tie us to 1. For example the dialects part of an expression:

expression:
    dialects:
      - dialect: ANSI_SQL
        expression: ss_sold_date_sk

The assertion behind adding this property is:

• It is common enough for expressions to differ by provider, that we should make the concept a first class citizen at the lowest level.
• It is common enough for expressions to have multiple implementations across providers that we should support this directly.

If we were to solve handling vendor extensions with the assumption that we are doing 2, then I would expect an approach that has vendor at the file level and allows for composition so the standards compliant behaviour can be shared.

Does anyone have thoughts on this?
My take is that 2 is a better approach, even though it has a higher amount of work to get right.

[dmariani]

My take is that we should strive for 2, because delivering a language standard would kill two birds with one stone: it can serve as an interchange format and a standard language. Why not strive for both?

[srcolinas]

Are there any progress on this topic? I was looking for a true standard to define the spec of a semantic model for a tool I am working on.

[QMalcolm]

Hi @srcolinas there has been a fair bit of discussion on this. We actually just published the project roadmap yesterday 🎉 Under the Metric Semantics & Core Semantic Model you'll find that one of the deliverables is Standard metrics specification language. There is currently a proposal document being worked on can be found here: https://docs.google.com/document/d/1Jn98kHWsnbvo1MycQBAnWirGTwRmw-DWaen7coNCYWA/edit?usp=sharing

It's less apparent than we'd like because we've been figuring out the proper process and tooling so people can find 😞 We are working to fix that though.

[magerdaniel]

I clearly support option 1. Option 2 is an utopie in my eyes

[MarioDeFelipe]

I tested this: One generated SAP ontology into two major agent platforms (Palantir and Microsoft Fabric), element by element, what each platform actually stored. Results: across five categories — identity, cardinality, actions, provenance, field-level synonyms — no two platforms broke the model the same way. The worst losses were silent: accepted with a success code, discarded without a word.

That experience reads directly onto the interchange-vs-standard question. Interchange without mandated semantics doesn't remove the N×M translation problem — it relocates it inside the standard: if every producer/consumer pair can interpret constructs differently, dialects become N×M reborn with better branding.

A middle position that would have saved us real losses: a small core with mandated behavior (identity, cardinality, constraints — the things agents act on), with dialect freedom reserved for expression syntax rather than construct semantics. Happy to share the anonymized loss table if it's useful to the discussion.

[willpugh]

We're been working on some defined semantics in the expression language group. I've got a PR for the current ones out, with an MD file that defines a slim set of semantics: #246

Would love any feedback. Particularly, if there are some of the inconsistencies you saw and whether we cover places in the spec that would address them.

The approach is not to get everything on the first rev, but get something in that is foundational and build on top of it.

[MarioDeFelipe]

Thank you for your comments Will. I have read the full document. Beautiful, and I have strong support for both the content and for the foundational-first approach.
You asked whether the inconsistencies we measured are covered; here I go:

It is covered, and good looking: The five user-visible semantics — especially Semantic 5 (typed error, never a plausible-but-wrong number) and Semantic 1's NULL-bucketing of unmatched fact rows — address the query-time family of what we saw in the field. The NULL determinism work (5.1 ordering defaults, 6.11 empty/NULL aggregate behaviour, NULL-safe stitch merges) pins down the places where two engines we tested with SAP quietly disagree today. Composite keys as first-class citizens in relationships (from_columns/to_columns, unique_keys) covers the compound-identity shape that ERP-class models live on — our four-part keys map onto the inference described in 6.4's is described cleanly.

The gap I see: The worst losses were not query-time — they were at transport-time: When I tested with Microsoft Fabric IQ, the platform accepted parts of the SAP semantic model with a success response but then silently discarded them. We only caught it by re-reading what was stored.

We published a generated SAP ontology into Fabric IQ's ontology item, and the API answered with success codes. Then, because we had a rule is to re-read everything we write — a getDefinition round-trip — we fetched back what Fabric had actually stored and diffed it against what we sent. No error, no warning, no partial-success flag — accepted with a 200, but then gone.

And this is the worst single loss: not because synonyms were lost — every platform loses something — but because nothing told us. If we have a schema rejection, we can handle it in a pipeline; but a silent drop we only catch if we are disciplined enough to read back and compare. And the payload matters for agents specifically: property-level synonyms are the alternative names that let an agent map a human question ("who's the client on this order?") to the right field. We can't risk an agent grounding on the stored model that doesn't know the synonyms ever existed.

So a permissive parser that ignores fields it doesn't model instead of rejecting them is to be avoided, and the PR comment deliberately claims only the observed behavior. For contrast, when we tested Palantir Foundry, the behaviour was different.

So my proposal is a conformance rule that implementations must represent, reject, or explicitly report a construct — and never accept-and-drop.

Now, two field notes from the SAP side:

1. Sentinel values vs. NULL. In SAP-sourced data, "missing" is usually not NULL — it's an initial value ('', '0000000000', '00000000'). Semantic 1's NULL bucket won't catch those, worth a future hook.
2. Declared cardinality, when it lands. 6.4's inference: world sources like SAP always know their cardinality — associations declare it, and especially in CSN. When the deferred declared-cardinality/RI proposal comes, two requests from the emitter side: keep declaration cheap (we declare, we never infer), and make declared-vs-inferred disagreement a typed error rather than silent trust of either side.

One clarifying question: the ontology layer's requires/derived_by fields also carry ANSI-SQL expressions. Is the intent that Ossie_SQL_2026 plus these evaluation semantics govern those expressions too, or does the ontology layer get its own semantics pass? Asking because if we are to build a CSN (SAP model language) → Ossie converter that emits closed-world constraints into requires, we'd like to target whichever contract will govern them.

[jakub-moravec]

Hi @willpugh @MarioDeFelipe @dmariani, very interesting discussion here. I'm wondering, if the community decides to go the standard way (#2), how do you envision the adoption of the standard by the industry proceeding? What would be the success criteria for that?

• from the perspective of the standard - who needs to adopt to make the standard relevant?
• from the perspective of the vendors - how do you define what depth of adoption is sufficient to be officially considered standard compliant?

[jakub-moravec]

@MarioDeFelipe, by "versioned suite arbitrates", do you mean an actual automation that would check the compatibility? From my experience with the OpenLineage standard, having that would make all the difference

[MarioDeFelipe]

@jakub-moravec yes, all automated. Because if a document says "implementations must not silently drop constructs" is only a wish; preferred having it in the code.
One annotation though. The repo already has validation/tooling that checks a model file against the Ossie schema. So, "is this document well-formed Ossie?" is answered, but another question follows up: "did this implementation preserve what it accepted?" You can pass the first perfectly and still be wrong on the second.

Concretely, the shape I'd propose is fixture-pair round-trips: a corpus of small models, each exercising one construct, each with an expected output, all pinned to a spec release — so "compliant" is never ambiguous; it's always "compliant with 0.x".

Since you've actually lived this: what broke in OpenLineage's version?

[jakub-moravec]

Hi @MarioDeFelipe, apologies for the radio silence, it took me a while to recover from vacation :)

In the case of OpenLineage, the spec makes it possible and simple for your payload to be valid against the spec/JSON schema, and yet not really usable for cross-vendor integrations:

• answering whether the payload is syntactically correct and schema-valid is simple, as you mentioned
• answering whether what is documented is sufficient is not. For example, you can create an OpenLineage payload without actually documenting any lineage (and share runtime metrics instead). Or you can document lineage at different levels of granularity. The best practices are often use-case specific. Not sure if this problem is relevant for Ossie.
• Information can be captured in custom payload fields, similar to Ossie custom_extensions. If important information is captured using this mechanism (as opposed to a standardised model), the integrations built on top of the standard end up being vendor-to-vendor integrations, as opposed to vendor-agnostic standard integrations.

[MarioDeFelipe]

@jakub-moravec — no apology needed, and thank you, this is exactly what I was hoping to learn.

In my view, your first failure mode is very relevant to Ossie. I went and checked the schema. In the ontology layer, a concept only has to declare two things: a name and a type. Identity, constraints, derivations, inheritance, relationships and descriptions are all optional. On a relationship, the human-readable phrasing is mandatory but the cardinality is not. So you can emit a perfectly valid Ossie ontology that is a list of named concepts and nothing else — no identity, no cardinality, no mappings to anything real. That is your OpenLineage payload with no lineage in it

What strikes me is that we found the same disease from opposite ends. Yours is a producer problem: the payload is valid and says nothing. Ours was a consumer problem: we sent a model that did say something, and parts of it were accepted and quietly discarded. That is bad because its a document that passes every check and cannot be used. So a compliance suite has to answer two separate questions; Did the model declare enough to be useful? And did the implementation keep what was declared?

On your second point, you have named the thing I ran into from the other side. Ossie's custom_extensions exists in the core spec at five levels, and the payload is an opaque JSON string, so a consumer cannot even inspect what is in there. But the ontology layer has no such escape hatch at all. Building a converter from SAP's model language, I found that @ODM.entityName — a stable cross-system identifier for a business object, is the kind of thing you want to ship but has nowhere to go. So the choice is drop it, or push it into a vendor-private field. Neither of those is shared meaning and the problem is not solved.

Where that leads me is not to ban the escape hatch. People need it, and closing it just converts leakage into loss. I would rather instrument it: have the conformance profile report what a model puts into custom_extensions and where. Then a concentration of extensions in one area says the standard is missing a construct there. Every use is a bug report against the spec

There is a live example of that loop working here. PR #332 proposes namespace prefixes and URIs so models can reference each other with stable global identifiers. That is a construct arriving because the pressure was visible. My worry is only that the pressure is currently visible by accident, when someone happens to complain, rather than by measurement.

Does OpenLineage have anything mechanical for this — usage of custom fields being counted or reported anywhere — or has it stayed a matter of best practice and social pressure?

[jakub-moravec]

or has it stayed a matter of best practice and social pressure?

This is where we are for now.

I'm trying to figure out what would be the best way to improve on that. For sure, the ability of the community to standardize relevant sub-models quickly is a good prereq, as it removes the incentive to use custom extensions for most of the producers.

Exposing some kind of ratio of how much is shared in the standard vs custom extension model might be a good driver too.

[tfaber]

We're starting on the Ossie path and wondering precisely this, is OSI intended is only an interchange format, or can it figure as the source-of-truth format.

With an interchange-first approach, adopting OSI for us currently really becomes useful once you have at least two semantic-layer implementations:

Vendor A repo → OSI representation → Vendor B repo

which right now means maintaining 3 (separate) repositories which is simply too time consuming and error-prone.

An OSI-first model changes the architecture:

OSI repo → Vendor A
OSI repo → Vendor B

with vendor_extensions living primarily in the vendor specific representations of the datasets/ cubes etc.

Is that an intended use case for OSI? In other words, and consequently, would an ossie.yml model eventually be expressive and modular enough to be maintained directly as the canonical semantic model (so not one big file but files per asset), rather than primarily being generated through export/import between vendor implementations?

[MarioDeFelipe]

@tfaber Good question, it makes SAP a useful stress test for it. For us the answer is "both, in layers".
The structural part of the model — entities, keys, associations, types — already has a source of truth: the ERP system. Nobody should hand-maintain that in YAML; SAP can generate it. What has no home is the curation on top: business names and verbalizations, which of several candidate identities agents should use. That layer is small, human-owned, and is the thing worth keeping in a repo as canonical — never changes structure, applied on top of the generated document.

So I'd say OSI-first is right for the overlay and interchange is right for the structure, and the "three repos" problem goes away once the generated part is reproducible and the maintained part is separate.
That favors modularity you describe — files per asset, and ideally ontology, semantic models and mappings as separable artefacts, that is being discussed in the ontology working group now.

[jbonofre]

Thanks @tfaber for the question, and @MarioDeFelipe for the SAP perspective. This thread has been open since January, so I'll start with a quick update on @willpugh's original question.

Interchange format or standard: we're doing both

The project has converged on a layered model (see core-spec/spec_layers.md):

• Layer 1, model definition: the model format (spec.md) plus a portable expression language, OSSIE_SQL_2026 (expression_language.md). The goal is that expressions in an Ossie model evaluate identically on any conforming engine.
• Layer 2, relational query interface: SQL with measures and duplication-free evaluation (relational_semantics.md).
• Layer 3, wide table query interface: Initial Foundational Semantics Spec  #246 (still open).
• Layer 4, ontology: ontology/ontology.md.

On the dialects concern Will raised: the top-level sql field is now the primary, portable form, written in OSSIE_SQL_2026. dialects only holds optional vendor variants. OSSIE_SQL_2026 is the only dialect whose semantics the spec defines. Any other dialect is opaque, and implementations MAY ignore it. Root-level dialects and vendors declarations were removed in 0.2.0.dev0. So the standard owns the semantics, and vendor variants are an escape hatch rather than the default.

On compliance (@jakub-moravec, @MarioDeFelipe): the repo now has a compliance/ folder with two parts:

• a portability ladder: fixtures plus a grader that scores each converter round trip element by element, with an explicit DROPPED-silent outcome
• an initial Layer 2 query compliance framework (test(compliance): add initial layer 2 query compliance test framework #632)

It's still early, but it is the automated suite pinned to a spec version that you both described.

@tfaber: can Ossie be the source of truth?

Yes, that is an intended use case. The reason Layer 1 exists is that a model authored once can be deployed anywhere without rewriting its expressions. An Ossie repo → Vendor A / Vendor B setup is what the hub-and-spoke converters in apache/ossie-converters are designed for.

There are a few caveats today:

• One model per document, no imports yet. Since 0.2.0.dev0, a document holds exactly one model, and the core spec has no import or include mechanism. You can't yet split a model into one file per asset. You also can't share a dataset (e.g. date_dim) across models without duplicating it (see Support for reusable datasets and relationships across semantic models #103). A practical workaround for now: keep per-asset fragments in your repo and assemble them into a single document in CI, before running validation and the converters.
• Converter fidelity varies. How much survives Ossie → vendor depends on the converter. The portability grader is the place to check that, and to add fixtures for the constructs you care about.
• Vendor-specific settings. If they live in the Ossie repo, they go in custom_extensions. Today its data field is an opaque JSON string; Structured custom extension / properties (avoid opaque JSON strings) #481 proposes making it a structured object. Keeping them on the vendor side, as you suggest, also works. The trade-off is that the generated vendor files then need a merge step so those settings survive each regeneration.

I also agree with Mario's "both, in layers" answer. When a system of record already holds the structure, generate that part, and keep the human-curated layer on top as the canonical source.

Modularity needs a proposal

Multi-file models (files per asset, imports, references across documents) are not a roadmap deliverable yet. They are related to "reusable datasets and relationships shared across semantic models" under Dataset Abstraction & Logical Modeling in the roadmap, to stable identifiers (#31), and to the ontology IRIs and prefixes (#332). As Mario mentioned, the ontology working group is also discussing how to keep ontology, semantic models and mappings as separate artefacts.

If you're up for it, a concrete proposal would help a lot. It should cover:

• the import/reference syntax
• how name resolution works across files
• how validation and converters handle a multi-file model

Please start that thread on the dev@ossie.apache.org mailing list, so the whole community can weigh in.

[marioapiphani]

Thanks @jbonofre — this compliance/ ladder with an explicit DROPPED-silent outcome is a great contribution. I'll take you up on "add fixtures for the constructs you care about": from the SAP side the three that matter most are compound identity (four-part keys), declared cardinality, and source-defined sentinel values (#401), and I'll contribute them against the Business Partner slice that both CSN converters now share (apache/ossie-converters#54 and #130).

On @tfaber's multi-file question: agreed it needs a written proposal. The ontology/mappings split already in ontology/mapping.json, and the working group's discussion of ontology, semantic models and mappings as separate artefacts, are probably the starting point; I'll follow the dev@ thread when it opens.

[marioapiphani]

A follow-up on the fixtures I promised. I had a look at compliance/portability before writing them, and the grader currently collects expressions only — primary_key, relationships and the ontology sections aren't elements under test, so a converter that drops a four-part key grades the same as one that keeps it. That's not a complaint; it's the "every use is a bug report" loop working.

Concretely: I've filed #693 proposing key and relationship element kinds with the compound-identity fixture as the motivating case, and #694 on the missing cardinality field in core-spec relationships. The sentinel case has no spec construct yet (#401), so what I'll contribute now is a rung that carries SAP sentinel shapes and grades whether the recognition rule survives
The ontology-layer constructs wait for an ontology track in the ladder, which I'll raise in the ontology WG.