The relationships that matter aren't in any of your semantic models

Take a supply chain, since almost every operational business has one somewhere inside its walls. Supply chains are big, complex systems with moving parts running in all directions. You probably have inventory data in a Power BI semantic model. Live shipment data is processing through an event hub. Standard operating procedures sit in a SharePoint library. Assembly data lives on the factory floor. And the supplier list a procurement manager actually sources from is an Excel workbook nobody outside that team has ever opened.

Now count what a planner does on a normal Tuesday. Open the Power BI report. Pull the number. Open the spreadsheet. Track the shipment. Check which distributors received what. Each of those is a person holding a relationship in their head because no system holds it for them. Then a supplier's shipment runs late, and the question they have to answer is which distribution centers and which stores are affected, and by how much. Nothing they opened that morning answers that.

You don't fix that with a bigger semantic model. It's unrealistic that a single company has one semantic model that rules and governs everything. Most organizations have several. Some live in Power BI and some live outside it, and there is a lot of ungoverned data out there that will stay ungoverned no matter how good the program is. Most of what matters arrives from somewhere nobody modeled.

That's not a knock on the semantic model. It's still the right tool for what it does. It reconciles values, and it's the reason finance and the warehouse stop arguing about what "profit" means. Reconciling values inside one domain is a different job than relating entities across domains, and a semantic model was never built for the second one.

Where the relationships actually live

A semantic model's relationships are join relationships. They exist so a measure aggregates correctly across a star schema. They aren't built to answer which distribution centers and stores feel it when a supplier's shipment is late. That question needs a chain: a Supplier caused a late Shipment, the Shipment was headed to a Distribution Center, the Distribution Center supplies a set of Stores. A foreign key will join those tables for a report. It will not tell an agent, or a person, that the chain means anything. Somebody has to model that meaning on purpose.

That's the job an ontology does. Fabric IQ's ontology item defines entity types, properties, and relationships. Those relationships are typed and directional, and they exist to enable traversal and rule based inference "without custom join logic." That isn't a faster join. It's a different question.

Generating an ontology from a semantic model

In my last article about semantic models, we discussed generating ontologies from existing semantic models. What does it actually give you?

Generation creates four things: an ontology item, entity types matching the tables in your semantic model, static properties from your columns along with data bindings to the rows underneath, and relationship types that follow the relationships defined in the model.

The relationships it inherits are the semantic model's relationships, which are the star schema joins. Those are the same joins that can't answer the shipment question. Generation hands you your dimensional model restated as entity types. Microsoft's own page then lists what you do by hand afterward: bind time series data, review entity type keys, bind the relationship types to data, and review the whole ontology. Even the relationships you inherited arrive declared and unbound.

Two Microsoft pages also disagree about the binding layer. The ontology overview says data bindings connect definitions to "lakehouse tables, eventhouse streams, and Power BI semantic models." The how-to page supports only OneLake and Eventhouse as binding source types. The technical page is what's really happening in your workspace.

One static binding per entity type. You can't combine static data from multiple sources into a single entity type. So "unify three semantic models" doesn't mean fusing three Supplier tables into one Supplier. Unification happens across entity types through relationships, not inside one of them.

Import-mode semantic model tables are out. The ontology graph doesn't support delta tables with column mapping enabled, and column mapping is turned on automatically on the delta tables that store import mode semantic model data. Direct Lake over a managed lakehouse table is the path that works.

The static side is not live. Upstream changes need a manual refresh of the graph model before the ontology sees them. Live data comes in through time series bindings from Eventhouse, and a time series binding requires a completed static binding first, with a key that exactly matches a column in the stream.

A late shipment is an operational question, and how fresh the answer is depends on which half of the binding model produced it. The stream is live. The supplier and distribution center context around it is as fresh as the last refresh somebody ran.

Two fields arriving at the same missing step

Jessica Talisman gets to the same place from library science, which is a completely different lineage than mine. Her Substack framework The Ontology Pipeline runs controlled vocabularies through metadata standards, taxonomy, and thesaurus before you ever reach ontology. Her argument is that skipping the earlier stages makes the later ones nearly impossible. The logical structure an ontology needs was never built underneath them.

A governed semantic model already does the vocabulary and metadata work in her pipeline. What it doesn't do is the taxonomy and relationship work her later stages describe, which is the same gap Fabric IQ's generation leaves open. BI modeling and library science landing on the same missing step from opposite directions is a stronger signal than either alone.

Open Semantic Interchange makes the same split visible. The cross-vendor effort Snowflake and dbt started with seventeen partners entered the Apache Incubator as Ossie in June and now spans more than fifty organizations. Its three working groups are Metric Language, Catalog, and Ontology. A portable standard for metric definitions is real progress on the vocabulary layer. Which relationships your business has is not something a standards body can hand you.

What this looks like once it exists

I'm not going to untangle ontology from knowledge graph here. The short version is that an ontology is the schema while a graph holds the instances.

Once entity types and relationships are defined and bound, Graph in Microsoft Fabric stores and traverses them using GQL, the ISO standard graph query language. Here's a query that walks the chain from the scenario above and finds every store affected by a delayed shipment. It's syntactically valid against Fabric's GQL grammar, shown as an illustrative pattern rather than a captured trace:

MATCH (sup:Supplier)-[:supplies]->(sh:Shipment)
      -[:deliversTo]->(dc:DistributionCenter)
      -[:serves]->(st:Store)
WHERE sh.status = 'Delayed'
RETURN sup.name, sh.id, dc.name, st.name

Three hops across four entity types that started life in separate semantic models, none of which could answer this alone. The ontology declared those relationships exist and what they mean. The graph stores and walks them.

The part that bites first

Supplier appears in your Power BI model, in the event hub payload, and in the procurement spreadsheet under three different keys and probably three different spellings. The ontology needs one Supplier. And because each entity type supports exactly one static binding, you resolve that identity before you bind. Entity resolution isn't cleanup you schedule for later. It's the gate.

This is the most common reason ontology programs stall, and it's the thing nobody demos. It's also where the ongoing cost lives. The vendor-side Enterprise Knowledge Graph Buyer's Guide puts semantic stewardship at roughly one FTE per 50 to 100 entity types. Discount that however you like for the source. It's still a headcount line, and it doesn't go away after the build.

What to do differently

If you're a Data & AI Director looking at this, the question isn't whether to build an ontology. Pull up your supply chain, or whatever your equivalent sprawling domain is, and ask two narrower things. Are the relationships that matter for a real operational question modeled anywhere, or do they only exist as foreign keys that happen to join correctly? And does Supplier mean the same thing in all three systems, in a way you could prove this week?

If nobody has deliberately defined that Supplier causes Shipment causes Distribution Center impact, generating an ontology won't create it. You'll get clean entity definitions and you'll skip vocabulary work you already did. The relationship modeling is still yours, the same way you once sat down and decided what "profit" meant.

Here's one of the four, modeled. Take the edge from Shipment to DistributionCenter. It's the genuinely cross-domain one, since logistics owns Shipment and retail owns DistributionCenter and neither model knows the other exists.

Name it deliversTo for the thing that happens rather than ShipmentDCKey for the column it was joined on. Point it one way, because the reverse question is a traversal and not a second relationship. Cardinality is many Shipments to one DistributionCenter. Binding it means matching the shipment stream's destination code to the facility code on the DC, which is somebody sitting down and agreeing those two identifiers name the same place.

Then hang scheduledArrival, actualArrival and carrier on the edge itself. Fabric IQ relationships carry attributes alongside their cardinality rules. That's the move a foreign key can't make. A join key knows the shipment was headed there. It has nowhere to record that the shipment was supposed to land Tuesday and landed Thursday. In a star schema those three fields are columns on a fact table with no way to say which relationship they describe. On the edge, they turn a traversal that answers which stores are affected into one that answers by how much.

Generation reads one semantic model at a time. If a future release reads across several and proposes a relationship none of them declares, and gets it right often enough to trust, the distinction I'm drawing here gets thin fast. Fabric IQ's ontology item is still in preview and I intend to keep testing it as it moves.

What if the cross-domain relationship doesn't exist in any single model to be inherited? Suppose that release reads across two semantic models plus Teams messages, email, and the SharePoint library where the SOPs live. How does an ontology traverse those?

Fabric IQ doesn't try. Binding sources are lakehouse tables and Eventhouse streams, so the ontology covers the structured half of the estate and stops. Databricks and Palantir both go further, and both get there the same way. Palantir's Document Intelligence parses documents into entities and populates Ontology objects from them. Genie Ontology treats unstructured context as supporting evidence rather than primary truth. Both rank the structured side above the unstructured one, and neither traverses a Teams thread as a first-class node in the graph. They convert it first.

Which leaves the question I actually want answered. Is extract-then-bind enough, or does a partial ontology covering only the structured half leave an agent reasoning with a hole it can't see? I don't know yet, and I'd be keen to hear from anyone further along on this than I am. Let me know in the comments!

None of this makes the semantic model less important. It's still the thing that keeps your numbers honest. It's not the thing that tells your agents, or your people, how the business connects.