Traditional BI answers “𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝗲𝗱?”

Semantic models answer “𝗛𝗼𝘄 𝘀𝗵𝗼𝘂𝗹𝗱 𝘁𝗵𝗲 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗺𝗲𝗮𝘀𝘂𝗿𝗲 𝗶𝘁?”

Taxonomies answer “𝗪𝗵𝗮𝘁 𝗸𝗶𝗻𝗱 𝗼𝗳 𝘁𝗵𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗶𝘀?”

Knowledge graphs answer “𝗪𝗵𝗮𝘁 𝗶𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗰𝗼𝗻𝗻𝗲𝗰𝘁𝗲𝗱, 𝗿𝗶𝗴𝗵𝘁 𝗻𝗼𝘄?”

𝗢𝗻𝘁𝗼𝗹𝗼𝗴𝗶𝗲𝘀 𝗮𝗻𝘀𝘄𝗲𝗿 “𝗛𝗼𝘄 𝗮𝗿𝗲 𝗮𝗹𝗹 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘀 𝗰𝗼𝗻𝗻𝗲𝗰𝘁𝗲𝗱?”

Your AI agent doesn’t know what a customer is. It knows you have a table called CUST_MASTER_V2. Closing that gap takes a layer that captures what your business actually means: every entity named, every relationship made explicit, in a form machines can reason over.

That layer has a name: Ontology.

---

Most people hear “ontology” and think philosophy class. In data and AI, it means something very practical: “𝗔𝗻 𝗼𝗻𝘁𝗼𝗹𝗼𝗴𝘆 𝗶𝘀 𝗮 𝗳𝗼𝗿𝗺𝗮𝗹 𝗺𝗮𝗽 𝗼𝗳 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂𝗿 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗲𝗻𝘁𝗶𝘁𝗶𝗲𝘀 𝗮𝗿𝗲, 𝗮𝗻𝗱 𝗵𝗼𝘄 𝘁𝗵𝗲𝘆 𝗿𝗲𝗹𝗮𝘁𝗲.”

Not a table. Not a dashboard. A map of meaning. Where a schema describes 𝘴𝘵𝘳𝘶𝘤𝘵𝘶𝘳𝘦, an ontology describes 𝘴𝘦𝘮𝘢𝘯𝘵𝘪𝘤𝘴. And that difference is exactly what today’s AI agents are missing.

Ask an AI agent: “𝘞𝘩𝘪𝘤𝘩 𝘴𝘶𝘱𝘱𝘭𝘪𝘦𝘳𝘴 𝘢𝘳𝘦 𝘢𝘧𝘧𝘦𝘤𝘵𝘦𝘥 𝘣𝘺 𝘵𝘩𝘦 𝘥𝘦𝘭𝘢𝘺 𝘰𝘯 𝘗𝘳𝘰𝘥𝘶𝘤𝘵 𝘟?” without an ontology, and it guesses which tables to join. Sometimes it guesses wrong, and you don’t find out until the number is already in a board deck.

With an ontology, the relationship is already defined:

• 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 sourced from 𝗦𝘂𝗽𝗽𝗹𝗶𝗲𝗿
• 𝗦𝘂𝗽𝗽𝗹𝗶𝗲𝗿 ships via 𝗦𝗵𝗶𝗽𝗺𝗲𝗻𝘁
• 𝗦𝗵𝗶𝗽𝗺𝗲𝗻𝘁 delayed by 𝗘𝘃𝗲𝗻𝘁

No guessing. Just traversal.

The pattern repeats across every industry:

Healthcare

• Patient has Encounter
• Encounter treated by Provider
• Medication prescribed during Encounter
• Claim billed to Payer

Manufacturing

• Asset located at Facility
• Asset maintained by Technician
• Sensor monitors Asset
• Work Order triggered by Maintenance Event

Retail / Supply Chain

• Product sourced from Supplier
• Order fulfilled from Warehouse
• Customer placed Order

Financial Services

• Account owned by Customer
• Transaction flagged by Risk Rule
• Loan secured by Collateral

Different industries. Same idea: entities and relationships that reflect how the business actually thinks, not how the data happens to be stored.

Taxonomy vs Ontology

These get conflated a lot, but they solve different problems.

Taxonomy: a hierarchy of categories

A taxonomy classifies things into nested “is-a” relationships. It’s a tree. One parent, one path down to each item (usually).

Example:
Gaming Laptops nest inside Laptops, which nest inside Electronics, which nest inside Products

It answers: “What kind of thing is this, and what category does it belong to?” That’s it. One dimension of relationship (containment and classification) and nothing else.

Ontology: a network of relationships

An ontology doesn’t just classify things; it describes how different kinds of things relate to each other, including types of relationships, rules, and constraints. It’s a graph, not a tree. Entities can connect in many directions at once.

Example:
Product sourced from Supplier
Product belongs to Category (this part can borrow from a taxonomy)
Product affected by Shipment Delay
Supplier located in Region

Notice the taxonomy (“Category”) can actually live inside the ontology as one type of relationship. A taxonomy is a special case of an ontology, but an ontology can express many more relationship types beyond “is-a”.

The practical difference for AI/data work

	Taxonomy	Ontology
Structure	Hierarchical tree	Graph / network
Relationships	One type: “is-a” / “belongs-to”	Many types: “owns”, “treats”, “delays”, “flags”, etc.
Question it answers	“What category is this?”	“How does this connect to everything else?”
Good for	Navigation, filtering, search facets	Reasoning, inference, cross-domain queries
AI agent use	Helps narrow scope	Helps the agent traverse logic and answer why/how questions

A taxonomy tells an AI agent where something sits. An ontology tells it how something behaves and relates, which is what’s needed to answer a question like “which suppliers are affected by this delay”, where the answer requires hopping across multiple entity types, not just going up or down one branch.

Knowledge graphs and ontology

The two terms travel together, so it helps to keep them straight: the ontology is the blueprint, the knowledge graph is the building.

The ontology defines the types and the rules: what a Supplier is, that a Shipment must have exactly one, that an Event can delay it. The knowledge graph is what we get when we load real data into that blueprint: millions of actual nodes and edges. Supplier 4711, the shipment it sent last Tuesday, the port strike currently delaying it.

One describes what can exist. The other records what does exist.

This is also where AI agents actually operate. An agent doesn’t traverse the ontology; it traverses the knowledge graph, and the ontology is what makes that traversal trustworthy. Every hop has a defined meaning, so “which suppliers are affected by this delay” becomes a walk along known relationships instead of a guessed join. It’s the same idea behind GraphRAG: ground the model’s answers in a graph of connected facts rather than a pile of documents.

And no, we don’t need a graph database on day one. The ontology can start life as a governed set of definitions and relationships. The knowledge graph is where that investment compounds once the questions get big.

But don’t standard applications give us a head start?

Partly, and that’s good news. If you run on SAP, Salesforce or Dynamics, a large share of your entities and relationships is already modelled: customers, orders, assets, work orders. Vendor models like Microsoft’s Common Data Model, and industry standards such as FIBO in finance or FHIR in healthcare, give us a ready-made vocabulary to start from.

But their models describe how the application thinks, not how your business does: the custom fields, the cross-system relationships, the definitions two departments still argue about.

The acceleration is real. The last mile of meaning is still ours to model.

Why Ontologies Matter in Microsoft Fabric’s AI Era

As organisations embrace Microsoft Fabric and Databricks, most of the attention goes to where the data lands. The ontology decides what it means once it gets there. In a modern Fabric architecture, the layers stack like this:

• OneLake: the centralised enterprise data foundation
• Lakehouse and Warehouse: curated business data using a Medallion architecture
• Semantic Models: business-friendly metrics and dimensions for analytics
• 𝗢𝗻𝘁𝗼𝗹𝗼𝗴𝘆 𝗟𝗮𝘆𝗲𝗿: business concepts, entities, relationships and rules
• 𝗙𝗮𝗯𝗿𝗶𝗰 𝗔𝗜 / 𝗖𝗼𝗽𝗶𝗹𝗼𝘁 / 𝗗𝗮𝘁𝗮 𝗔𝗴𝗲𝗻𝘁𝘀: use the ontology to answer business questions with context and accuracy

The ontology is what turns the rest of the stack into something Copilot and Data Agents can actually reason over. It creates a common business vocabulary across departments, improves AI accuracy by supplying business context, connects data across ERP, CRM, EMR, IoT and other systems, and supports governance by standardising definitions across the enterprise.

And it lets us ask questions in plain language:

“𝘚𝘩𝘰𝘸 𝘥𝘪𝘢𝘣𝘦𝘵𝘪𝘤 𝘱𝘢𝘵𝘪𝘦𝘯𝘵𝘴 𝘳𝘦𝘢𝘥𝘮𝘪𝘵𝘵𝘦𝘥 𝘸𝘪𝘵𝘩𝘪𝘯 30 𝘥𝘢𝘺𝘴.”

“𝘞𝘩𝘢𝘵 𝘢𝘴𝘴𝘦𝘵𝘴 𝘢𝘳𝘦 𝘢𝘧𝘧𝘦𝘤𝘵𝘦𝘥 𝘣𝘺 𝘵𝘩𝘪𝘴 𝘮𝘢𝘪𝘯𝘵𝘦𝘯𝘢𝘯𝘤𝘦 𝘦𝘷𝘦𝘯𝘵?”

Why does the ontology get forgotten?

Because AI journeys are run as technology programmes. Platforms, models and licences are visible: they have budgets, vendors and go-live dates. Meaning has none of those. There is no SKU for “a shared understanding of what a customer is”, so it never makes the business case.

It also has no natural owner. The ontology cuts across every department, and what belongs to everyone tends to belong to no one.

And the pain arrives late. A missing platform blocks a project on day one. A missing ontology lets the pilot demo brilliantly and only starts hurting at scale, when the answers stop matching each other. By then the programme has already declared success. The result is the section below.

What happens when we omit the ontology?

Nothing breaks loudly. That’s the trap.

Every team keeps its own private definition of “customer”, “order” and “revenue”, and every dashboard quietly disagrees.

AI agents keep guessing at joins, and their confident answers inherit every wrong assumption.

Every new use case rebuilds the same business logic from scratch, in yet another tool.

And the knowledge of how things really connect lives in people’s heads, walking out of the door when they do.

The data survives. The meaning doesn’t. And meaning is the layer everything downstream depends on.

How do we get meaning onto the roadmap?

Treat the ontology as a product, not a by-product. Give it an owner, a backlog and a definition of done, just like any platform component.

Start where the pain is. Pick one domain and one question the business keeps asking, model the entities and relationships behind it, and let an agent answer it end to end. One working traversal beats a hundred slides.

Borrow before building. The standard applications and industry models above give us the vocabulary; our job is the last mile of custom fields, cross-system relationships and contested definitions.

Make it a gate. No AI use case ships until its entities and relationships are defined in the shared model.

And measure it where the business feels it: fewer dashboards that disagree, and more agent answers that survive scrutiny.