Four things go by “semantic”. They do not mean the same thing.

Joins in OSI describe how two tables are combined for a calculation — the computation path for a metric. That is a SQL optimisation, not a model of the world.

A “relationship” in the YAML has no identity, no logic, no class that anything could reason over. It is an instruction to the query engine, not knowledge.

A label like :Allergen is, to the database, just a search string. It does not know that a walnut is an allergen unless you draw every edge yourself.

No class hierarchy kicks in automatically, no disjointness, no inverse property. You would have to rebuild the logic as application code — a hand-written substitute ontology.

To be fair: you can build a knowledge graph on an LPG. The question is whether meaning, identity and rules are standard — or your team's hand-maintained code.

That works — as long as the logic is procedural and known up front. SQL executes what you specify. It discovers nothing you haven't already poured into a query.

Chained rules (“A implies B, B implies C …”) turn into SQL cascades that only their author can maintain. Declared as rules, they are formulated once, checked everywhere, and changed with a version — modelling remains work, but it happens in one place.

An LLM estimates statistical similarity. Excellent at sounding plausible, unreliable at being guaranteed correct. It cannot prove that a conclusion necessarily follows.

A knowledge graph delivers verifiable statements with provenance — it is as right as its curation, and it shows its sources. The LLM delivers language. Together they work; alone, the LLM sounds right without being checkable.

The name is the source of the confusion. OSI standardises the definition of metrics, so that “revenue” is calculated identically everywhere. Enormously valuable — but a metrics interchange format.

It contains no class logic, no reasoning, no open-world semantics, no global identity. It makes numbers consistent, not knowledge derivable.

Fair, and answered honestly: yes, the knowledge graph has the highest barrier to entry on the modelling side, and it is not the fastest place for bulk aggregation. Both true.

But the conclusion “so buy all three next to each other” rebuilds the silo problem one level up: metric definitions in one tool, paths in a second, meaning in a third — three systems, three lifecycles, and nobody guarantees that the metric in tool one uses the same definition of “customer” as the rule in tool three.

Correct, and it should stay that way. Nobody in your team should write SPARQL, just as nobody writes the bytecode of your BI tool. Consumers get generated APIs and prepared context for agents; the query language is an implementation detail below them.