Originally published September 6, 2026. Updated October 2026 to reflect current Fabric IQ terminology and capabilities.

What Is an Ontology in Microsoft Fabric IQ?

Key takeaway: A Fabric IQ ontology creates a shared, machine-understandable model of the business by defining entities, properties, relationships, rules, and metrics and connecting those concepts to enterprise data. It complements—not replaces—Power BI semantic models by giving people and AI a broader, reusable business vocabulary across domains and data sources.

Fabric IQ Ontologies Defined

If you're a Power BI professional, the word ontology may sound like something from a computer science textbook. If that's your reaction, I totally get it.

Business Intelligence (BI) professionals are accustomed to discussing fact tables, dimensions, measures, relationships, and Power BI semantic models.

“Ontology” sounds like a different world.

But the basic idea is much more approachable than the terminology suggests.

In Microsoft Fabric IQ, an ontology describes the business in terms both people and AI can understand. Instead of starting with tables and columns, you start with things the business recognizes:

  • Distributors

  • Employees

  • Customers

  • Locations

  • Products

  • Orders

Then you describe what is true about those things and how they relate to one another.

  • A Customer has a Name.

  • A Product belongs to a Category.

  • A Sales Order contains Products.

  • A Distributor places a Sales Order.

That's the heart of an ontology.

Ontologies can become a critical foundation when Generative BI needs to reason across business domains, data sources, and AI agents.

Start With the Business, Not the Tables

Power BI professionals usually begin with Kimball-style data warehouse tables because that's been the traditional best practice evangelized by Microsoft. Here are some classic examples:

  • DimGeography

  • DimCustomer

  • DimProduct

  • FactSales

And there's a reason why Kimball-style dimensional models have withstood the test of time - they're extremely useful for analytics. Even in the age of cloud MPP database technologies like Azure Synapse Analytics.

Kimball-style star schemas provide battle-tested design patterns for organizing data for filtering, aggregation, and calculation.

But business users don't normally think in terms of dimensions and fact tables. They think in terms of:

  • Customers buy Products.

  • Products belong to Categories.

  • Distributors place Sales Orders.

  • Employees manage Sales Territories.

A Fabric IQ ontology makes those business concepts explicit.

Microsoft describes ontology in Fabric IQ as a shared, machine-understandable business vocabulary. That vocabulary is built around a few core ideas:

  • Entity types represent business concepts.

  • Properties describe facts about those concepts.

  • Relationships describe how those concepts connect.

So instead of thinking only in terms of a DimDistributor table, you can model a Distributor as a business concept. Instead of seeing BusinessType as just another column, you model it as a property of the Distributor.

And instead of thinking only about a foreign-key relationship between two tables, you can explicitly model the business meaning behind the connection. For example:

  • Distributors place Sales Orders.

That shift matters.

Entities Represent the Things the Business Cares About

An entity type represents a reusable business concept and is at the heart of Fabric IQ ontologies. For example:

  • Distributor

A Distributor might have properties such as:

  • Distributor Name

  • Business Type

  • Annual Revenue

  • Number of Employees

  • Address

The Fabric IQ ontology defines what a Distributor means independently of any single row in a DimDistributor table. Individual Distributors are then instances of that entity type.

That distinction may sound academic, but it becomes useful when the same business concept appears across different systems.

A Customer might exist in a CRM platform. The same Customer might also appear in a sales system. And again in an IT support system.

While the underlying tables may differ, the business concept remains Customer. A Fabric IQ ontology gives you a place to define that concept at the business level.

Relationships Add Meaning That Joins Alone Don't Express

Relationships are where Fabric IQ ontologies become particularly interesting. Suppose a Power BI semantic model contains a relationship between a DimDistributor table and a FactSalesOrder table.

Technically, that relationship tells Power BI how to filter and analyze the data. But what does the relationship mean to the business?

Perhaps: Reseller places Sales Order. That statement explicitly expresses something a join alone does not. It names the meaning of the connection. Now continue this idea with:

  • Product belongs to Product Category.

  • Distributor operates in Geography.

  • Sales Order contains Product.

When you define relationships as above, you begin to describe a network of business concepts rather than simply a collection of linked tables.

That matters for Generative BI because business questions are often expressed in exactly these terms. A business executive doesn't ask:

  • "Join the reseller table to the sales table and then join the product dimension."

They ask:

  • "Which product categories are growing fastest among our specialty distributors?"

The closer your semantic layer comes to representing the business concepts in that question, the less interpretation AI has to invent in response to real-world business questions.

An Ontology Isn't a Replacement for a Power BI Semantic Model

For Power BI professionals and teams, I need to make this crystal clear:

These technologies serve two different but complementary purposes. A Power BI semantic model is designed for analytics. It gives you things such as:

  • Fast, governed reporting and dashboards

  • Business-friendly terminology

  • Analytical relationships

  • Trusted measures

  • Dimensions

  • Hierarchies

An ontology serves a broader purpose. It creates a shared business vocabulary that can be reused across data sources, agents, applications, and workflows. Think of the distinction this way:

  • A Power BI semantic model describes how we analyze the business. An ontology describes what the business is.

There is overlap, of course. Both contain semantics. Both describe relationships. Both must use business-friendly terminology.

But the ontology elevates concepts such as Customer, Product, Shipment, or Distributor above any particular analytical model.

That makes those concepts reusable in a wider business context.

You're Not Starting Over

If you've followed this newsletter from the beginning, there is a theme I keep returning to:

  • Power BI teams are not starting over.

That remains true with Fabric IQ ontology. Microsoft lets you generate an ontology from an existing Power BI semantic model. When you do that, Fabric IQ can use the semantic model's structure to generate:

  • Entity types from tables

  • Properties from columns

  • Relationship types from semantic model relationships

  • Metrics from DAX measures

That gives Power BI teams a valuable starting point. The semantic modeling work you've already done can help bootstrap the ontology. But there is an equally important second half to that story:

  • Fabric IQ ontology generation is a starting point, not the finish line.

Microsoft's own guidance tells you to review and complete the generated ontology. That makes sense.

A semantic model was designed for analytics. An ontology is intended to represent business concepts and relationships more broadly. Those goals are related, but not identical.

A table that works perfectly well in a star schema is not automatically the ideal business entity. A technical relationship does not always communicate the full business meaning of that relationship. And not every important business concept may already fit cleanly into a single semantic model.

This is where ontology modeling becomes its own discipline.

Why Would You Need an Ontology If You Already Have a Semantic Model?

This was one of the first questions I had when I began exploring Fabric IQ. If the Power BI semantic model already contains business logic and semantics, why add another semantic layer?

The answer becomes clearer when you think beyond a single report or analytical domain. Imagine an organization with separate Power BI semantic models for:

  • Customer Service

  • Supply Chain

  • Sales

  • HR

Each semantic model may be excellent for its own analytical purpose. But suppose an AI agent, such as Copilot or a Fabric data agent, needs to reason across them.

Now concepts such as Customer, Product, Location, Order, Shipment, and Supplier may appear in multiple places.

  • Do those concepts mean the same thing everywhere?

  • Which definition should an agent trust?

  • How are they connected?

An ontology provides the organization with a shared vocabulary across individual analytical models and data sources. This is where Fabric IQ becomes much more than conversational analytics.

The goal is not merely to help AI answer questions about a dashboard. The goal is to give AI a coherent model of the business it is reasoning about.

Without that, good luck building a real-world Generative BI solution.

From Rows and Columns to a Business Knowledge Layer

This architectural shift is what I find most interesting. Traditional data architecture generally moves from:

  • Source systems → data platform → semantic model → dashboards

Generative BI adds another requirement. The AI agent needs a business knowledge layer. It needs to know not just where the data is stored, but what it represents.

  • What terminology does the organization use?

  • What are the important business concepts?

  • Which definitions are authoritative?

  • How are they related?

  • What rules apply?

Fabric IQ is Microsoft's solution for making that business knowledge a first-class part of the data platform. And Fabric IQ ontologies are central to that strategy.

And don't make the mistake of thinking an ontology is isolated metadata sitting off to the side.

Fabric IQ binds ontology concepts to actual data in OneLake and makes those concepts available to downstream experiences, including Copilot and Fabric data agents.

That is what makes crafting ontologies more than a documentation exercise. The semantic meaning is connected to the data.

Why This Matters for AI Agents

Large language models (LLMs) reason well with language. But enterprise AI needs grounding. Without grounding, an AI system has enormous freedom to interpret a question based on general language patterns.

That is useful when writing an email. It's dangerous when answering a question about revenue, inventory, customers, or operations.

An ontology provides structured business context.

Instead of asking an agent to infer what "Customer" means from a collection of unrelated tables, the organization can define Customer as an enterprise concept.

Instead of asking the agent to infer how Customers relate to Orders, Products, or Locations, you can make those relationships explicit.

The goal isn't to eliminate AI reasoning. It's to give that reasoning better boundaries. That's the same principle I've been discussing throughout this newsletter:

  • The better you describe the business, the less AI has to guess.

Power BI Semantic Models and Fabric IQ Ontologies Work Together

I think this is the most important takeaway for Power BI professionals. Don't think:

  • Semantic model or ontology?

Think:

  • Semantic model and ontology.

The semantic model remains extremely valuable for governed analytics, measures, KPIs, and reporting. The ontology creates a broader shared language of business concepts and relationships that can support reasoning across domains.

Microsoft Fabric IQ is explicitly designed around those layers working together. That is why the work I've discussed in the previous articles still matters.

  • Clear names matter.

  • Good descriptions matter.

  • Authoritative measures matter.

  • Well-designed relationships matter.

Semantic enrichment makes real-world Generative BI possible. A stronger semantic model gives you a stronger foundation for moving into Fabric IQ.

A Simple Way to Think About It

If you're new to ontology, here's the mental model I would use:

  • Data tells AI what happened.

  • An ontology helps tell AI what the business means.

  • A semantic model tells AI how the business analyzes what happened.

That isn't a perfect technical definition. But I think it captures why ontologies matter for Generative BI. The objective is to move AI closer to the language and concepts that business stakeholders actually use.

  • Not tables.

  • Not foreign keys.

  • The business itself.

Start With the Foundation

If your organization already uses Power BI, I would not rush to design an enterprise ontology from scratch. I would start with the semantic models you already trust.

  • Is important business knowledge explicit rather than trapped in someone's head?

  • Are the important business concepts clearly represented?

  • Are the names and descriptions useful?

  • Are relationships understandable?

  • Are the measures authoritative?

Those questions matter before Fabric IQ ontologies enter the picture.

Where We Go Next

An ontology sounds simple when we describe it in terms of entities, properties, and relationships. Designing a good one is harder.

  • How should you model relationships that carry their own business meaning?

  • Should an ontology mirror the dimensional model underneath it?

  • Which concepts deserve to become entities?

  • How granular should they be?

And what happens when the same concept appears across multiple data sources?

Those are ontology modeling questions. And they are exactly where things start getting interesting. I'll tackle those questions next.

Next up: How Do You Model an Ontology in Microsoft Fabric IQ?

Greetings! I’m Dave Langer

Author | Microsoft MVP | LinkedIn Top Voice

I help Power BI teams move past dashboards to Generative BI using Microsoft Fabric and Fabric IQ.

If your organization is serious about enterprise-class conversational analytics, we should talk.

Explore Services →