Ontology Is Not a Better Semantic Model

Every few weeks the same objection surfaces in comment threads and conference hallways: ontologies are just semantic models with a new name. The comparison is understandable. Both sit above the raw data. Both describe entities and the relationships between them. Both let you reason about a business without opening a single table.

But the two are answering different questions, and the difference matters more as we hand parts of that reasoning to machines.

The argument I want to make here is not that one replaces the other. It is that an ontology is turning into something a semantic model was never meant to be: a governed, machine-readable representation of what a business actually means — one that data models, processes, and AI agents can all refer to. That makes it less a modelling technique than a piece of operational infrastructure, with all the governance consequences that implies.

Two different questions

A semantic model starts from the data and asks how it should be organised so that questions can be answered. In practice that means a fact table in the middle, dimensions around it, relationships between them, and measures on top:

                 Customer
                    |
Product —— Sales —— Region
                    |
                   Date

This structure is excellent at what it was designed for: revenue by customer, by product, by region. Microsoft describes a Power BI semantic model as a logical description of an analytical domain, with metrics and business-friendly terminology.

An ontology starts from the other end. It begins with the concepts a business uses when it talks about itself, and makes the relationships between them explicit:

Customer
  ├── has ────────── Contract
  │                    ├── covers ────── Product
  │                    ├── governedBy ── SLA
  │                    └── generates ─── Invoice
  └── reports ─────── Incident
                        └── impacts ──── SLA

The shift is easy to miss because both diagrams contain boxes and lines. But the second one is not saying these tables can be joined. It is saying a contract is governed by a service level agreement. The relationship itself carries meaning, and that meaning is stated rather than implied by a foreign key.

The video that prompted this piece puts it in a line worth borrowing: businesses are naturally more graph-like than star-shaped. A company is not a fact surrounded by dimensions. It is customers, contracts, suppliers, services, incidents, obligations and people, connected by relationships that mean different things — owns, supplies, approves, depends on, violates, is responsible for.

For most BI questions, that complexity is unnecessary overhead. For questions like which regulatory obligations are affected by a change to this process? or which systems, units and controls depend on this capability?, it is the whole point.

Where the contrast is drawn too sharply

The popular framing of this distinction runs roughly as: semantic model equals structure, ontology equals meaning. It is memorable, and it is too sharp on at least three counts. I think the argument is stronger without the exaggeration.

Semantic models do carry meaning. A well-built one exposes Revenue, Gross Margin, Customer, Region — not tbl_f001, col_17, fk_782. Business-friendly terminology is part of Microsoft's own definition. The honest formulation of the difference is narrower and more useful: a semantic model operationalises meaning for an analytical context, while an ontology tries to make business semantics explicit, cross-domain and reusable.

The star schema is not a historical mistake. The claim that it exists to serve a query engine rather than the business gets the order backwards. Dimensional modelling predates any particular engine by decades, and Microsoft is straightforward about the reasoning: a star schema design is optimised for analytic query workloads. What is true is narrower — a star schema does not necessarily mirror the conceptual structure of the business. That is a real limitation. It is not an indictment.

AI is not helpless in front of a table. Current models read SQL schemas, infer relationships, generate queries and use data catalogues. The problem is not that they cannot interpret structure. It is that without explicit semantics they have to reconstruct meaning, and reconstruction is guessing with better manners. Given four columns named cust_id, contr_id, sla_cd and inc_status, an agent will probably infer something reasonable. Given

Customer  HAS_CONTRACT   Contract
Contract  GOVERNED_BY    ServiceLevelAgreement
Customer  REPORTS        Incident

it does not have to infer anything at all.

What this buys an agent

The value of an ontology for an AI system is best seen in a question that sounds simple and is not:

Which high-value customers are at risk because they have unresolved incidents and repeated SLA breaches?

Pull that apart and it contains at least three definitions that must exist somewhere before the question can be answered consistently:

HighValueCustomer  := Customer where AnnualRevenue > X
                      or StrategicAccount = true
UnresolvedIncident := Incident where Status != Closed
RepeatedSLABreach  := count(SLABreach over 90 days) >= 3

In most organisations these definitions do exist — in a slide deck, in someone's head, in three slightly different SQL views maintained by three different teams. The question is not whether the business has a definition of a high-value customer. It is whether anything other than a human can read it.

An ontology connects three levels in a form a machine can traverse: concepts, the typed relationships between them, and the rules and constraints that qualify them. Microsoft describes the purpose of its own implementation in almost exactly these terms — giving agents a governed, shared understanding of entity types, relationships, definitions, rules and source mappings, so that answers are more grounded and more consistent across systems.

The useful way to think about this is not that the ontology makes the agent smarter. It makes the agent's interpretation space smaller. For systems that are expected to be reliable rather than merely impressive, that is the more valuable property.

It is worth noting that this need not start from scratch. Fabric can generate an ontology from an existing semantic model, mapping tables to entity types, columns to properties and relationships to relationship types. That is a reasonable starting point and a poor finishing point. The transformation produces structure, not semantics; deciding that a customer reports an incident and is subject to an SLA is modelling work, and no conversion performs it for you.

What an ontology does not solve

This is the part that tends to go missing, and it is where enthusiasm meets the actual state of most enterprise data.

Suppose the same company appears in three systems:

Salesforce   ACME GmbH                Customer ID: 4711
SAP          ACME Deutschland GmbH    Debitor:     88721
ServiceNow   ACME DE                  Organisation: 1529

An ontology can define what a Customer is. It can state that a customer has contracts and reports incidents. What it cannot do, by itself, is know that

4711 = 88721 = 1529

That equality is not a semantic question. It is entity resolution, and behind it sit master data management, identity mapping, reference data, source-of-truth rules, data quality and stewardship. None of these are solved by declaring a concept. An ontology that sits above unresolved identities produces confident, consistent, well-grounded answers about three different companies that happen to be the same one.

I am labouring this because the failure mode is quietly expensive. A semantic layer that is obviously incomplete gets treated with appropriate suspicion. One that is conceptually elegant and factually ungrounded gets trusted — and it is now feeding agents that act on it.

Meaning becomes infrastructure

The shift underneath all of this is easier to state than to absorb.

In conventional information systems, meaning lived in people. Data was structured, a human interpreted it, a decision followed. Documentation of that meaning was a hygiene activity: valuable, chronically deferred, rarely load-bearing.

Data → human interprets → decision

As reasoning moves into agents, a growing share of that meaning has to become machine-readable to be usable at all:

Data → machine-readable semantics → reasoning → decision → action

The moment semantics sit in that path, they stop being documentation. They become part of the operating infrastructure of the company, with the same demands one would make of any other production system — versioning, ownership, change control, testing.

And that turns a modelling exercise into a governance question almost immediately. As soon as an organisation formally defines Customer, Material Incident, Critical Supplier or Regulatory Obligation, it has to answer a set of questions it may have avoided for years:

• Who owns this definition, and who may change it?
• Which version is authoritative, and which source is definitive?
• Which systems consume it, and which agents may act on it?
• How does a change propagate to everything downstream?

These are not data modelling questions. They are the same questions business architecture has been asking about capabilities, information objects and ownership for a long time — now with the added property that the answers are executable.

The layer in between

So the claim that an ontology is the next generation of the semantic model is not so much wrong as too small. The two are not competing; they describe the same organisation from different angles, and both are useful. A semantic model is optimised for aggregation, calculation and reporting. An ontology is optimised for meaning, context, relationships and rules.

What is genuinely new is the position an ontology occupies. It sits between business architecture, data architecture, knowledge graphs, governance and agentic systems, and it is the first artefact in that stack that all of them can read.

Microsoft's implementation is still in preview as of August 2026, and it would be premature to treat any current product as the shape this settles into. The direction, though, looks robust independently of the vendor: if machines are going to reason about a business, the business has to be written down in a form they can read — and someone has to be accountable for what it says.

That is a business architecture problem wearing a data architecture costume. It is worth being clear about which one we are actually solving.

This piece grew out of a critique of a short video on ontology and semantic models, which makes the distinction well and, in my view, sharpens the contrast further than the evidence supports. The corrections and extensions above are mine.

Topics: Ontology · Business Architecture · AI