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

How Do You Model an Ontology in Microsoft Fabric IQ?

Key takeaway: Modeling a Fabric IQ ontology is not the same as converting tables into entities. Start with the business concepts people and AI need to understand, define their grain, properties, and meaningful relationships, then use existing Power BI semantic models as evidence and a starting point—not as the finished ontology design.

Fabric IQ Ontologies Are Not Power BI Semantic Models

Microsoft Fabric IQ can generate an ontology from an existing Power BI semantic model. That's super useful.

It's also potentially misleading.

If a Power BI semantic model contains a DimDistributor table, Fabric IQ can create a DimDistributor entity type. If it contains a DimProduct table, Fabric IQ can create a DimProduct entity type.

If those tables are related, Fabric IQ can create a corresponding relationship type.

That gives you a working starting point very quickly. But it raises a much more important question:

  • “Is converting tables into entities actually the same thing as designing an ontology?”

The short answer is no.

Generating the structure is the easy part. The harder part is deciding what the business concepts should be in the first place.

That requires a different way of thinking from traditional BI modeling.

Start With the Business Concepts

Power BI professionals are accustomed to modeling data for analysis. You ask questions such as:

  • What is the grain of the fact table?

  • Which dimensions should filter it?

  • Which relationships are needed?

  • Which measures should we create?

  • How should the model support the reports users need?

Those are exactly the right questions for analytical modeling. Ontology modeling starts somewhere else. It starts with:

  • “What are the things in the business that humans and AI need to understand?”

Microsoft makes this distinction explicit in its Fabric IQ documentation. Ontology modeling is concept-driven rather than primarily use case-driven. That's an important shift.

Suppose you're working with distributor sales data. From an analytical perspective, you might have a star schema containing:

  • FactDistributorSalesOrderLine

  • DimSalesTerritory

  • DimDistributor

  • DimProduct

  • DimDate

That's a perfectly reasonable Power BI semantic model.

But an ontology asks you to step back from those tables. What are the actual business concepts? Perhaps:

  • Distributor

  • Sales Order

  • Sales Order Line

  • Sales Territory

  • Product

  • Product Category

Those concepts don't have to match the tables one-for-one.

In fact, the most useful ontologies will often look different than your Power BI semantic models.

And that's where ontology design begins.

A Table Is Not Automatically an Entity

This may be the most important idea in the entire article:

  • Just because something is a table doesn't mean it should automatically become an entity type in the ontology.

A business concept may deserve to become an entity even if it doesn't exist as its own table. Consider a typical sales fact table. A row in this table might contain:

  • DistributorID

  • OrderDateID

  • SalesOrderNumber

  • SalesOrderLineNumber

  • ProductID

  • QuantityOrdered

  • SalesOrderLineTotalAmount

From a dimensional modeling perspective, this might be exactly what you want. The grain is one sales order line. But from a conceptual perspective, that one table combines two business concepts:

  • Sales Order and Sales Order Line

The fact that the analytical model stores them together does not mean the ontology needs to treat them as one concept (and probably shouldn't).

This is one reason I would be cautious about mechanically accepting a Fabric IQ ontology generated from a Power BI semantic model as the final work product.

A generated ontology reflects the Power BI semantic model's structure.

A good ontology should reflect the business's true nature.

Grain Still Matters

As a Power BI professional, you already understand grain. That skill transfers extremely well to ontology modeling. The difference is that instead of asking:

  • "What does one row in this table represent?"

You also need to ask:

  • "What does one instance of this entity represent?"

Suppose you create an entity called Order. What exactly is an Order?

  • A Customer purchase?

  • A Distributor purchase?

  • A Shipment?

  • An Invoice?

If different people in your organization will answer "What is an Order?" differently, the concept probably isn't defined clearly enough yet.

A good entity type should represent one recognizable kind of thing. For example:

  • Sales Order - One commercial order placed by a Distributor.

  • Sales Order Line - One Product purchased as part of a Sales Order.

Those definitions establish conceptual grain.

And once the grain is clear, the properties and relationships become much easier to reason about.

Properties Describe the Entity

After identifying a business concept, the next question is:

  • "What facts describe this thing?"

For a Distributor, properties might include:

  • Distributor Name

  • Distributor Type

  • Annual Revenue

  • Employee Count

For a Sales Order, they might include:

  • Sales Order Number

  • Order Date

  • Ship Date

For a Sales Order Line:

  • Quantity Ordered

  • Unit Price

  • Discount Amount

  • Sales Order Line Total Amount

This seems straightforward, but there's an important modeling decision hiding underneath it:

  • Should something be a property? Or should it be another entity?

Take Product Category. You could model Product Category as a text property of Product. Or you could model Product Category as its own entity with the following defined relationship in the ontology:

  • Product belongs to Product Category.

Which is better? There isn't a universal answer.

The question is whether Product Category has meaning of its own:

  • Do you need to describe categories?

  • Reuse them across data sources?

  • Relate them to other concepts?

  • Ask questions about them independently?

If so, treating Product Category as an entity in the ontology will be more useful than treating it as just another field.

That is conceptual modeling.

You're deciding which ideas deserve to exist as first-class business concepts in the ontology.

Relationships Should Say Something About the Business

Traditional Power BI semantic models contain relationships. But those relationships mainly exist to make filtering and aggregation work correctly. Ontology relationships serve an additional purpose:

  • They express business meaning.

Consider these concepts:

  • Distributor

  • Sales Order

  • Sales Order Line

  • Product

A dimensional model tells you which keys connect the corresponding tables. A Fabric IQ ontology uses relationships to describe the business:

  • Distributor places Sales Order.

  • Sales Order contains Sales Order Line.

  • Sales Order Line purchases Product.

Those relationships matter. They turn structural connections into business statements. And those statements are much closer to the language a business user, or an AI agent like Copilot, will encounter.

Instead of expecting AI to infer the meaning of a foreign key relationship, we can make the meaning explicit.

Providing this meaning to AI agents is critical for building real-world Generative BI solutions.

Model Relationships as Verbs

A simple technique I find useful is to try expressing each relationship as a sentence. For example:

  • Distributor places Sales Order.

The two entity types are nouns. The relationship is a verb.

Now ask whether the sentence makes sense to someone who understands the business but has never seen the database. If it does, you're probably modeling at the right level. Compare that with:

  • Distributor relates to Sales Order.

Technically, that's a relationship. Semantically, it tells us almost nothing. The same applies to names like:

  • associated with

  • connected to

  • has

Sometimes generic relationships are unavoidable. But whenever possible, the relationship should explain why the two concepts are connected.

That's what turns connectivity into business meaning.

Don't Let the Star Schema Dictate the Ontology

This point deserves special attention for Power BI teams. Star schemas are excellent analytical structures.

  • They simplify filtering.

  • They make aggregation predictable.

  • They work extremely well with Power BI.

That doesn't mean an ontology should reproduce the star schema exactly. The two models solve different problems. A star schema asks:

  • "How should we structure data for reliable and efficient analysis?"

An ontology asks:

  • "How should we represent the concepts and relationships that define this business domain?"

Sometimes those answers align beautifully. DimProduct may map very naturally to a Product entity. DimDistributor may map naturally to a Distributor entity. Other times they won't:

  • A flattened dimension might contain several concepts that deserve separate entities.

  • A fact table might combine attributes from several conceptual levels.

A role-playing date dimension might be essential to analytical modeling in Power BI, while dedicated Order Date and Ship Date entities fit the ontology better because they make the business explicit to an AI agent.

The analytical model should inform the ontology.

It should not automatically dictate it.

So Why Generate an Ontology From Power BI at All?

Because it can save a tremendous amount of work. A mature Power BI semantic model already represents years of decisions about:

  • Business concepts

  • Relationships

  • Terminology

  • Measures

Ignoring that investment would be foolish.

Fabric IQ's ability to generate an ontology from a semantic model can give Power BI teams a very strong head start.

Fabric IQ currently supports creating entity types from semantic model tables, properties and data bindings from columns, relationship types from model relationships, and ontology metrics from DAX measures.

Microsoft also explicitly recommends reviewing and completing the generated ontology afterward.

That last part is important. Think of automatic Fabric IQ ontology generation as:

  • Ontology bootstrapping, not ontology design.

It gets the initial concepts onto the canvas. Then the modeling work begins.

  • Are these really the correct entities?

  • Should some entities be split?

  • Should others be combined?

  • Are the entity keys correct?

  • Are the relationships meaningful?

  • Is anything missing?

Does the ontology represent the business the way stakeholders actually think about it?

Those are human modeling decisions.

Use the Semantic Model as Evidence

This gives you a useful middle ground. I wouldn't start by ignoring the Power BI semantic model and designing an ontology in a vacuum. I also wouldn't assume the Power BI model is the ontology.

Instead, here's the 2-step process I strongly recommend:

  1. Enrich the Power BI semantic model for use with AI agents.

  2. Use the enriched semantic model as a starting point for the Fabric IQ ontology.

A table suggests that a concept may exist. A relationship suggests that two concepts may be connected. A column suggests that something may be an important property. A measure suggests that the business cares about a particular calculation.

But each of those feeds into the ontology design process. They're not the final answer.

This distinction matters most in mature Power BI environments. Semantic models contain reporting decisions. Those decisions may include:

  • Role-playing dimensions

  • Measure tables

  • Bridge tables

  • Hierarchies

These structures can be excellent for analytics but poor candidates for direct representation as business concepts.

The ontology lets you separate how the data is implemented from what the business means.

Ask Questions the Business Can Answer

One way to keep ontology modeling grounded is to avoid beginning with technical questions. Don't start with:

  • "Which tables should become entities?"

Start with:

  • "What are the important things in this part of the business?"

Then:

  • "What do we need to know about each thing?"

  • "How are those things related?”

For Distributor sales, a conversation with a stakeholder might reveal:

  • Distributors place Sales Orders.

  • Sales Orders contain one or more Sales Order Lines.

  • Each Sales Order Line represents a purchase of a Quantity of Product.

  • Products belong to Product Categories.

  • A Distributor operates within a Sales Territory.

That already looks like the beginnings of an ontology. No SQL required. No star schema required. No Fabric IQ required. Only after the concepts are clear do you ask:

  • "Where does the data for each concept live?"

That sequencing is powerful. It separates the semantic design problem from the data binding problem.

Fabric IQ even supports defining untyped properties before binding them to source data, which reinforces this idea:

You can model what the business means before deciding exactly how the concept maps to physical data.

Don't Try to Model the Entire Enterprise

Here's another trap I would avoid. Once you begin thinking conceptually, it's easy to imagine creating one giant ontology that models the entire organization (i.e., "One ontology to rule them all"):

  • Customer

  • Product

  • Employee

  • Supplier

  • Order

  • Shipment

  • Contract

  • Location

  • Campaign

  • Asset

  • Etc.

That sounds comprehensive. It also sounds like trying to boil the ocean and is very likely to fail.

Instead, I would start with a bounded business domain and a real Generative BI need. For example:

  • Distributor sales performance.

Identify the concepts needed to understand that domain. Model them well. Bind them to trusted data. Test how effectively AI can answer meaningful business questions using them.

Then expand deliberately.

The long-term goal may be shared enterprise semantics.

The practical starting point should be much smaller.

A Simple Ontology Design Checklist

Before accepting an ontology design, I would ask:

  • Concepts - Are the entity types recognizable business concepts rather than simply copies of database tables?

  • Grain - Can we clearly state what one instance of each entity represents?

  • Properties - Do the properties genuinely describe the entity they belong to?

  • Relationships - Can each important relationship be expressed as a meaningful business statement?

  • Language - Would a business stakeholder understand the entity and relationship names without seeing the source schema?

  • Separation from implementation - Are we modeling the business rather than accidentally reproducing technical structures?

  • Scope - Is the ontology focused enough to solve a useful business problem without trying to model everything?

  • Source alignment - Can the concepts ultimately be grounded in trusted data?

If you can answer those questions well, you're doing more than translating a data model.

You're designing a semantic representation of the business.

The Bigger Shift for BI Professionals

This is where ontology modeling becomes especially interesting to me. BI professionals like you already have many of the skills required.

  • You understand grain.

  • You understand relationships.

  • You understand business terminology.

  • You understand how analytical models represent the business.

But ontology modeling asks us to move up one level. Instead of beginning with:

  • "How should we structure this data?"

You begin with:

  • "How should we describe this business?"

That is a subtle but significant shift. I think it will become increasingly important as AI agents become another major consumer of enterprise data.

The quality of the answers won't depend only on the LLM.

It will depend on the quality of the business model we give the LLM to reason over.

The Next Question Is Methodology

Once you accept that ontology design is more than converting tables into entities, another question follows naturally:

  • "How do we do this consistently?"

In other words, what are the practices that any Power BI team can use for any Generative BI project to answer all of the following:

  • "How do we discover the right business concepts?"

  • "How do we define them precisely?"

  • "How do we validate relationships?"

  • "How do we avoid modeling the same concept differently across domains?"

  • "How do we capture business rules that are more complex than simple entity-property-relationship structures?"

Those are not really Fabric IQ questions. They are modeling methodology questions.

And I think that is where the conversation around Generative BI is going to get very interesting.

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 →