Semantic model vs. ontology

A retail chain runs its Monday review from one dashboard. The same question opens every meeting: which store sells the most. The answer is on screen before anyone finishes the sentence. Sum revenue, group by store, sort from high to low. A semantic model is built for exactly this.

Then a freezer in the back of one store sets off a temperature alarm. A different question comes up. Which stores does this one breach put at risk? The chain shares stock between locations, moves it on shared trucks, and buys from shared suppliers. The bad batch could be anywhere by now. And the dashboard has nothing to say. Not a wrong answer. No answer.

The easy move is to fix it with more measures. Add a churn measure, a risk measure, a breach-exposure measure. It never works, because this was never a measure to begin with. One question is a total. The other is a walk across four different parts of the business that nobody joined together in advance. Same data, one estate (the company's whole data setup), two questions that need two completely different machines.

Two shapes of question, two backends

Look at the two questions side by side and you can see they are not even the same kind of question. "Which store sells the most" points inward. It squeezes a pile of rows into one number along a dimension you already have. "Which stores does one breach put at risk" points outward. It starts at a single freezer and spreads across shipments, shared stock, and stores, following links until the answer appears at the far end.

Neither question is harder than the other. They are just different jobs. A backend built to roll rows up into totals is not built to walk relationships. And a backend built to walk relationships is a heavy, slow way to add up a column. Give each question the machine it was built for, and both come back clean. Swap them, and both struggle.

Aggregation is a roll-up. Reasoning is a walk.

Here is the difference in how the two questions work. Aggregation is fan-in: many rows arrive, and one value leaves. You planned the grouping when you built the model, so the road is already drawn and the trip is instant. This is the whole design of a semantic model. It is a ready-made map of the trips you knew you would take.

Relationship reasoning goes the opposite way. It is fan-out along a path: start at one node, step to its neighbors, step again, and let the question decide how far to go. Nobody drew this exact route in advance, and that is the point. The answer is not a stored fact you look up. It is a path you walk when you need it, across concepts that a total would have flattened away.

That is why adding more measures to the dashboard never made the breach question answerable. A measure is a better total. It cannot become a walk. The two shapes need two backends because they are two different actions: summarize versus trace.

Pick a question and watch each backend handle it.

Run through all of them and the split is clear. The totals go to the semantic model and come back instantly. The traces go to the ontology and come back with a path. Nothing here says one backend is better. It shows that the same estate holds both shapes of question, so it needs both machines.

In Fabric, they sit on the same data

Microsoft Fabric carries both machines, and the right way to see them is as partners, not rivals. The Power BI semantic model is the hand-built analytics layer: measures and dimensions shaped around the aggregation questions you planned for. The Fabric IQ ontology is the relationship layer: a knowledge graph your questions can traverse, and the grounding an AI agent stands on. In Fabric that grounded agent has a name, the data agent. When it faces the breach question, it walks the ontology's relationships instead of guessing a join.

The part that matters most is that they work together over the same OneLake data, instead of living in separate silos. An ontology can bind to a semantic model as one of its sources, and Fabric can seed an ontology straight from a semantic model, so the meaning you already built flows into the graph instead of being drawn again. So a model and an ontology are not a one-time choice you are stuck with. You pick the backend per question: the data agent searches over the ontology's relationships to answer the traversal questions, and the semantic model keeps answering the planned ones. This ontology and graph surface is in preview as of July 2026, so treat the exact seeding steps as still changing. But the split of work between the two is the part that lasts.

It helps to be exact about what that seed actually gives you, because "Generate Ontology" is a starting point, not a finished ontology. The entity, property, and relationship definitions carry over from any semantic model, so the shape of the graph is there in one click. The data behind that shape is the part that depends on your setup: bindings and live querying only arrive through a Direct Lake model whose backing lakehouse workspace has inbound public access turned on, so with Import or DirectQuery you get the skeleton and nothing to traverse yet. Either way, you finish the job by hand: binding time series, checking the entity keys, setting up the relationship types, and reading the whole graph before a data agent stands on it. The structure is generated everywhere. Queryable data is the part you still have to earn.

The one trap

Do not treat this as a contest with a winner. The moment you ask "which one is better, a semantic model or an ontology," you have already asked the wrong question, because the honest answer is always "better for which question?" Use the semantic model when the question is a total you expected. Use the ontology when the question is a walk nobody drew. An estate that has only one of them can answer only half its questions. And the half it drops is usually the half that matters most in a crisis.

So the real work comes before the backend: read the shape of the question first. And the fastest way to see that shape is to stop translating questions into joins by hand and let the ontology take a plain-English question directly. That is the next concept, turning natural language into an ontology query.