Originally published September 27, 2026. Updated October 2026 to reflect current Fabric IQ terminology and capabilities.
Fabric IQ Ontologies Require a Modeling Methodology - Here's Why
Key takeaway: Fabric IQ provides the tools to create an ontology, but the platform cannot decide what your business means. A scalable ontology requires a repeatable modeling methodology to discover concepts, define meaning and grain, model relationships and constraints, resolve ambiguity, and validate the model with business stakeholders.
Ontologies Are All About Modeling
Microsoft Fabric IQ gives you the tools to create an ontology so that Fabric data agents and other supported AI experiences can work with explicit business meaning.
You can even generate a Fabric IQ ontology from an existing Power BI Semantic model.
All of that is useful, but none of it answers a fundamental question:
"How do we know whether we modeled the business correctly?"
As a former Enterprise Architect, I think about this gap a lot. I've used many modeling tools and languages over my long career, including:
Unified Modeling Language (UML)
Entity-Relationship (ER) Diagrams
Object-Role Modeling (ORM)
They all represent abstract concepts, but they require a backing methodology (e.g., the Rational Unified Process + UML) to provide the discipline needed to consistently deliver results that are valuable to the business.
If you're serious about building true enterprise-class Generative BI, you must be serious about your Fabric IQ modeling methodology.
Tools Tell You What You Can Build
Microsoft's current Fabric IQ guidance is clear about the mechanics of ontology creation. You can:
Create entity types
Add relationships
Define properties and keys
Generate an ontology from a Power BI semantic model
Model business concepts before binding them to physical data
Connect the ontology to OneLake data sources
Use the resulting ontology for powerful Generative BI experiences
Those capabilities are important. But they still leave many design questions unanswered. For example:
Which business concepts deserve to become entities?
Which concepts should remain properties?
How granular should an entity be?
When should one concept be split into two?
How should relationships be named?
How do we handle overlapping definitions across departments?
How do we validate that the ontology matches the business rather than just the source data?
How do we keep the ontology consistent as it grows?
Those are not product-feature questions. They are modeling questions.
A Tool Can Create Structure Without Creating Clarity
Imagine that you generate an ontology from a Power BI semantic model. The semantic model contains:
Sales Territories
Distributors
Products
Sales Order Lines
Fabric IQ can use that structure to create a starting ontology. That's certainly helpful. But what if the business actually thinks in terms of:
Distributor
Sales Order
Sales Order Line
Product
Product Category
Sales Territory
The ontology generated from a Power BI semantic model reflects the analytical model, not the business's true nature. In other words, you must go further than semantic models when you craft ontologies.
That's why you should think of generating a Fabric IQ ontology from a Power BI semantic model as bootstrapping.
Bootstrapping creates an initial ontology quickly. It does not eliminate the need for a disciplined approach to modeling the business.
This modeling requires a repeatable way to answer questions the software cannot answer for us. Otherwise, your Fabric IQ ontologies will never grow to become the backbone of your enterprise Generative BI solution.
"Model the Business" Sounds Easy
In my previous article, I argued that ontology modeling should start with the business, not simply reproduce database tables. That sounds straightforward.
Ask: "What are the important things in the business?"
Then: "What do we need to know about them?"
Then: "How are they related?"
That is a good start. But real organizations get messy very quickly.
Ask three departments what a Customer is, and you may get three different answers.
Finance might define a customer as an entity that has been invoiced.
Support might define a customer as any account entitled to service.
Sales might define a customer as any account with an opportunity.
Which one belongs in the ontology? Maybe all three. Maybe none of them should be called simply Customer.
Now we're doing more than identifying nouns and verbs. We're resolving meaning.
That requires a methodology if you want consistent results as your ontology grows over time (and it will).
Grain Needs a Consistent Definition
BI professionals already understand grain. In Kimball-style dimensional modeling, you ask:
"What does one row represent?"
In ontology modeling, you ask:
"What does one instance of this entity represent?"
But even that question can become difficult. Suppose one team talks about Order. Do they mean:
A customer request?
A purchase order?
A sales order?
An order line?
An invoice?
A methodology should force you to define the concept precisely enough that different people use it consistently. For example:
Sales Order - One commercial order submitted by a Distributor.
Sales Order Line - One product purchased within a Sales Order.
Those definitions establish the conceptual grain. But the process shouldn't depend entirely on whoever happens to be in the room.
We need a repeatable way to surface ambiguity and resolve it.
Entity or Property?
Another deceptively simple question is whether you should model a business concept as an entity or a property. Take Product Category as an example.
You could model it as a property of Product. That might be completely appropriate.
Or Product Category could be its own entity because the business naturally thinks about relationships that way. For example:
A Product belongs to a Product Category
Which is better? The answer depends on the business meaning.
Does Product Category have properties of its own?
Does it participate in relationships?
Is it reused across multiple domains?
Do business users ask questions about categories independently of products?
Do different systems define categories differently?
These are conceptual questions.
A modeling methodology helps you answer them consistently, rather than relying on intuition every time.
Relationships Need More Than Names
Relationships are another area where methodology matters. Fabric IQ ontologies let you connect entity types. But consider these two relationships:
Distributor → related to → Sales Order
Distributor → places → Sales Order
The second is much more meaningful. Now imagine two teams independently modeling the same domain.
One uses: Customer places Order
The other uses: Order belongs to Customer
Both may represent the same underlying business fact. But if every team invents relationship semantics independently, the ontology can become inconsistent quickly.
Your modeling methodology should answer questions like:
Which direction should the relationship take?
How should it be phrased?
What does the relationship mean?
Is it mandatory or optional?
Is it one-to-one, one-to-many, or many-to-many?
Does the relationship have meaning or attributes of its own?
The relationship line on the canvas is the easy part. The semantics behind it are the real work.
Business Language Is Often Inconsistent
This may be one of the hardest practical problems in real-world Generative BI. Organizations rarely have one perfectly consistent vocabulary.
Different departments use different terms. The same term can mean different things. Different terms can mean the same thing. For example:
Customer
Client
Account
Buyer
Subscriber
Are these synonyms? Different roles? Different lifecycle stages? Different concepts entirely?
An ontology should create shared business meaning. But before you can get to shared meaning, you must resolve the disagreements.
A methodology needs a way to capture terminology, definitions, synonyms, distinctions, and exceptions.
Otherwise, you risk encoding ambiguity into the ontology instead of removing it.
Conceptual Modeling Must Be Separate From Physical Modeling
One current Fabric IQ capability I find especially important is support for untyped properties. That may sound like a small product detail.
Conceptually, it is much more interesting.
It lets you define a business property before deciding what physical data type or source column will implement it. In other words:
Define what the business means first.
Decide how the data represents it second.
That separation is central to good conceptual modeling.
Suppose the business says: Customer has Lifetime Value
Before you worry about whether Lifetime Value is stored as a decimal, calculated from transactions, imported from a CRM system, or derived from a semantic model, you should define what Lifetime Value actually means.
Only then should you bind the concept to data.
This is exactly the kind of discipline a modeling methodology should reinforce.
Bindings Should Not Drive Meaning
The temptation with any data platform is to start from what already exists. You have tables. You have columns. You have Power BI models. So, you naturally ask:
"How do I map these into the ontology?"
That's useful. But the danger is that the physical implementation begins driving the conceptual model.
The result is an ontology that describes the database, not the business. A better process is:
Define the business concepts.
Define their meaning.
Define their properties.
Define their relationships.
Validate the model with business stakeholders.
Then determine how those concepts bind to physical data.
The source data still matters. But it should provide evidence and implementation support.
It shouldn't be the sole authority on what the business means.
Validation Has to Involve the Business
A technically valid ontology can still be conceptually wrong. That makes stakeholder validation essential.
But "Does this look right?" is not enough. A methodology should give you better ways to test the model. For example:
1 - Can a business stakeholder read a relationship as a sentence and agree that it is true?
Distributor places Sales Order
2 - Can they distinguish one entity from another?
What is the difference between Sales Order and Sales Order Line?
3 - Can they explain the grain?
What does one instance of Customer represent?
4 - Can they identify missing concepts?
Is there anything important about this process that the model cannot express?
5 - Can the ontology support representative business questions?
Which product categories are purchased by our highest-value Distributors?
Those tests help move validation from diagram review to semantic validation.
Consistency Gets Harder as the Ontology Grows
You can manage a small ontology informally. You cannot manage an enterprise ontology that way. And successful Generative BI initiatives quickly morph into enterprise imperatives.
For example, consider a CEO using Generative BI. They'll naturally take a broader view of the enterprise.
Now, suppose one BI team creates Customer in the ontology
Another team creates: Client
A third team creates: Account
Later, someone discovers that all three refer to overlapping populations. Someone will have to bring the bad news to the CEO.
The CEO's been making decisions with incomplete or missing data.
Now consider teams that generate Fabric IQ ontologies from their Power BI semantic models.
One semantic model domain models Geography as a table.
Another models Region as a column.
A third models Sales Territory as something else entirely.
None of those choices is necessarily wrong. But without a methodology, inconsistency accumulates.
That creates exactly the kind of ambiguity the ontology was supposed to solve. A scalable approach for building real-world Generative BI needs conventions for:
Naming
Definitions
Entity grain
Relationship semantics
Reuse
Ownership
Review
Versioning
Conflict resolution
At that point, ontology modeling starts looking much more like a governance discipline than a drawing exercise.
BTW - None of this is new. I worked as an Enterprise Architect at Microsoft back in 2009, and I faced these exact same problems in modeling Microsoft's business.
Fabric IQ IS NOT the Methodology
I want to be careful here. This isn't a criticism of Fabric IQ.
Fabric IQ is the platform. It gives you the mechanisms to define and operationalize shared business semantics.
Microsoft's current training teaches how ontology modeling starts with business concepts, how entity types and relationships work, and how ontologies can be created manually or generated from Power BI semantic models.
That's exactly what the product documentation should do. But the platform cannot decide what your business means.
It can't decide whether your organization has one Customer concept or five.
It can't decide whether Product Category deserves to be an entity.
It can't decide how Finance and Sales should resolve conflicting definitions of Revenue.
Those decisions require a modeling process.
What Should a Methodology Provide?
At minimum, I think a useful ontology modeling methodology for Generative BI should help you do five things.
Discover Concepts - Identify the important things, events, roles, and business facts within a domain.
Define Meaning - Give those concepts precise definitions and clear conceptual grain.
Model Relationships - Capture how concepts relate using business language rather than technical connectivity.
Capture Constraints - Document the rules that determine what combinations of concepts and relationships are valid.
Validate With Stakeholders - Give business experts a practical way to confirm that the model represents the domain correctly.
Notice what is missing from the list:
Fabric
Power BI
SQL
OneLake
Those technologies matter when you implement the model.
But the methodology should begin with the business.
BI Professionals Already Have a Head Start
The good news is that BI professionals are not starting from zero. Dimensional modeling already teaches you several useful disciplines:
Defining the grain
Understanding business processes
Distinguishing measures from descriptive attributes
Modeling relationships deliberately
Using business terminology
Validating analytical meaning
Ontology modeling extends those instincts. But it also asks you to be more explicit about semantics.
You're not only designing a structure that produces correct calculations.
You're designing a structure that tells humans and AI what the business means.
That is a higher bar.
Do We Already Have Methodologies for This?
As someone who has spent years modeling software, data, and businesses, this leads to the question I find most interesting:
"Do we actually need to invent a new ontology modeling methodology?"
Conceptual data modeling has existed for decades. Knowledge representation has existed for decades. Ontology engineering has existed for decades.
Established approaches exist to identify concepts, express relationships, capture constraints, and validate meaning.
One methodology I am particularly interested in is Object-Role Modeling, specifically ORM2. ORM2 begins with simple facts expressed in natural language. For example:
Distributor places Sales Order
Sales Order contains Sales Order Line
Sales Order Line purchases Product
Sound familiar?
That doesn't mean ORM2 is automatically the right methodology for Fabric IQ. Fabric IQ's ontology model has its own capabilities and limitations. And ORM2 wasn't designed specifically for Generative BI.
But the overlap is interesting enough that I think it deserves serious investigation.
The Next Question
Fabric IQ gives you the technology to operationalize business semantics. The harder challenge is determining what those semantics should be.
That is why I think ontology modeling needs more than a product interface.
It needs a methodology. And the next question I want to explore is:
"Can ORM2 provide that methodology for 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.