Originally published October 10, 2026.
Can ORM2 Help You Model Fabric IQ Ontologies?
Key takeaway: ORM2 can serve as an upstream conceptual modeling methodology for Fabric IQ ontologies by helping teams capture business facts, relationships, roles, and constraints in precise natural language before mapping that meaning into Fabric IQ. It is not a one-to-one implementation standard, but it can provide the rigor and stakeholder validation that the platform itself does not.
A Platform Isn’t a Methodology
In a previous article, I argued that Fabric IQ ontology modeling needs a methodology. Because as powerful as Fabric IQ might be, it’s just the platform that gives you:
Entity types
Properties
Relationships
Metrics
Rules
Inheritance
Bindings
Namespaces
I get why folks might confuse the Fabric IQ platform with a methodology.
For example, Microsoft is adding more and more features for Fabric IQ ontologies to describe the business semantics AI agents need for enterprise-class Generative BI experiences.
But no matter how powerful Fabric IQ might be, the platform still can’t answer a fundamental question:
“What is the correct model (i.e., ontology) for our business?”
That’s a conceptual modeling problem, which raises another question:
“Are there methodologies that can help me model the business correctly?”
Unfortunately, Microsoft’s guidance in this space is very high-level. Microsoft provides a growing collection of best practices, but nothing that helps Power BI teams build quality ontologies in a detailed, repeatable way.
So, one methodology I keep coming back to is Object-Role Modeling v2, or ORM2. I first learned ORM many years ago when I worked as an Enterprise Architect at Microsoft.
ORM was originally envisioned as a better way to model enterprise data. Over the years, ORM has grown to encompass other use cases (e.g., modeling graph databases) as ORM evolved into ORM2.
Despite ORM2’s power as a data modeling methodology, I don’t think you should treat it as an “official” methodology for Fabric IQ ontologies.
Fabric IQ ontologies and ORM2 differ in how they support conceptual business modeling.
However, the overlap is compelling enough that I think ORM2 deserves serious consideration for any Power BI professional serious about building skills for Generative BI.
What's ORM2?
Fundamentally, Object-Role Modeling (ORM2) is a conceptual modeling methodology for describing a business in terms of entities and the constrained roles those entities play.
If you’re rolling your eyes right now because that’s so abstract, keep reading - it’s very intuitive when you see some examples.
In practice, ORM2 starts with natural language sentences that business stakeholders can easily understand and verify:
Distributor places Sales Order
Sales Order contains Sales Order Line
Sales Order Line purchases Product
Each bullet is a business fact.
ORM2 asks you to model business facts first, validate them with business stakeholders, and then define any business constraints.
For example, a constraint is that a given Sales Order can be placed by only one Distributor.
Take it from a modeling junkie. This is fundamentally different than other methodologies (e.g., Kimball or UML) you might be familiar with.
This focus on clearly articulated facts, roles, and constraints using rigorous natural language is precisely what you need to ground AI agents.
And I think that is exactly why it may be useful for ontology modeling.
Start With Business Facts
When designing a Fabric IQ ontology, it’s easy to begin with structures because that’s how the platform features work:
What are our entity types?
What properties should each entity have?
What relationships should connect them?
Don’t get me wrong. Those are questions you must answer.
But they already assume that you’ve identified the right business concepts, relationships, and constraints.
ORM2 pushes you to think at a more fundamental level - the level of documenting business facts. For example:
Distributor places Sales Order
That simple statement contains two entities:
Distributor
Sales Order
And one predicate:
places
Now consider expanding the universe of business facts:
Sales Order contains Sales Order Line
Sales Order Line purchases Product
Product belongs to Product Subcategory
Notice you haven’t designed a Fabric IQ ontology yet (e.g., no entity properties)?
What you’ve done is describe the business in precise natural language.
To be honest, the best Fabric IQ ontologies will come from Power BI teams that take the time to model the business facts before they ever open the ontology editor.
Yes. In the Age of AI, modeling is just as relevant as ever - maybe even more so.
Why Facts Are So Powerful
One of the things I like best about ORM2 is the emphasis on verbalization.
That is, working through the ORM2 methodology produces a conceptual model that should be expressible in language that a domain expert can easily understand.
That makes model validation so much easier.
Instead of showing a business stakeholder a diagram full of technical notation and asking, “Does this model look right?”
You instead ask, “Are these statements true?”
For example:
Every Sales Order is placed by exactly one Distributor
A Product can belong to more than one Product Category
Every Sales Order contains at least one Sales Order Line
Assume for a moment that the above business facts are true. They are describing aspects of the business piece by piece.
This is critical for real-world Generative BI.
If the goal is to ground AI so it responds accurately to natural-language prompts from business stakeholders, what’s better than representing the business to AI in stakeholder language?
This is an important reason why the ORM2 methodology is a great fit for modeling Fabric IQ ontologies.
ORM2 Is Property-Free at the Conceptual Level
This section covers one of the biggest differences between ORM2 and other data modeling approaches (e.g., Entity-Relationship, Kimball, UML, etc.) you may be familiar with.
I’ll use Fabric IQ ontology development as an example because it more closely aligns with traditional data modeling techniques.
Modeling a Fabric IQ ontology uses a structure that every Power BI professional is familiar with:
Entity type → Properties → Relationships
For Power BI professionals, entity types, properties, and relationships may initially feel analogous to tables, columns, and model relationships. But an ontology entity type represents a business concept independently of any single source table.
However, ORM2 explicitly avoids attaching attributes (properties) to entities. Instead, ORM2 models the business as facts.
For example, a Fabric IQ ontology could have a Distributor entity type with the following properties:
Distributor Name
Annual Revenue
Number of Employees
By way of comparison, ORM2 models the business in a more fundamental way:
Distributor has Distributor Name
Distributor has Annual Revenue
Distributor employs Number of Employees
At this point, you may be wondering why this level of detail matters.
Because a business aspect that looks like a property in the moment may end up having more meaning than you initially assumed.
Consider Geography. At first, you might treat Geography as a property. Using ORM2, it would look like:
Distributor has Geography
But what if Geography has its own properties? Using ORM2, what if the following were true business facts?
Distributor operates in Geography
Geography has a Region
A Country belongs to a Region
Geography belongs to Sales Territory
When you consider the universe of Geography-related facts, it’s clear it shouldn’t be a simple property.
The ORM2 methodology is specifically designed to delay the decision about what becomes an entity or property.
ORM2 focuses first on documenting the business piece by piece.
This is exactly what you want to provide the grounding that AI agents need.
Constraints Are Where ORM2 Gets Really Interesting
When crafting real-world Fabric IQ ontologies, entity types, properties, and relationships are only part of modeling the business accurately.
Adding constraints gets you to a full-featured conceptual model of business processes. Consider the following business fact:
Distributor places Sales Order
Even if this is a true business fact, it doesn’t provide enough detail to ground an AI agent:
Can one Distributor place many Sales Orders?
Can a Sales Order be placed by multiple Distributors?
Must every Sales Order have a Distributor?
Can a Distributor exist without ever placing a Sales Order?
If your data experience has been like mine, questions like those above are typically not explicitly documented in natural language.
More importantly, the answers to those questions (i.e., the constraints) are not formally documented - usually because business professionals learn them informally on the job.
To be fair, over the years, I’ve seen constraints like these implemented using technology (e.g., database triggers) or maybe documented in modeling tools.
Regardless, your business stakeholders will expect Generative BI solutions to be fully aware of any business constraints - otherwise, your Generative BI solution risks losing credibility.
The most reliable way to ground an AI agent in those constraints is to make them explicit.
Enter ORM2’s power features for expressing constraints such as:
Uniqueness
Mandatory participation
Cardinality
Frequency
Subset
Exclusion
Equality
Valid values
Now think of your typical database (i.e., entity-relationship) diagram’s relationship line. How many of the constraint types above can you model?
(BTW - it’s usually only two)
Sure, if you’re a modeling wonk like me, you might retort that UML + OCL can handle all the above constraints. But I’m betting you’re not that familiar with UML and have never heard of OCL.
(BTW - Good luck showing UML + OCL to business stakeholders 🤣)
So, score another big point for using ORM2 as the first step in crafting effective Fabric IQ ontologies.
To be clear, Fabric IQ has its own relationship cardinalities, keys, rules, and other semantic constructs.
But ORM2 can help you discover and validate the business constraints first using natural language your business stakeholders understand.
Then you can decide how much of those constraints Fabric IQ can express directly.
But ORM2 Isn’t Fabric IQ
As useful as I believe ORM2 will be to Power BI professionals serious about building Fabric IQ ontologies, I need to be crystal clear on this point.
You should never think of an ORM2 model as something you simply translate one-for-one into Fabric IQ.
Why?
Because the two modeling paradigms have different goals:
ORM2 is a conceptual modeling methodology.
Fabric IQ is an operational semantic platform.
Fabric IQ ontologies need to connect concepts to actual enterprise data (e.g., OneLake tables). Therefore, ontologies need:
Entity types
Properties
Relationships
Metrics
Bindings
Rules
Inheritance
Namespaces
And integrations with agentic experiences (e.g., Fabric data agents).
ORM2 doesn’t have to worry about many of those implementation concerns at the conceptual modeling stage.
That means the relationship should probably look like this:
Business domain → ORM2 conceptual model → Fabric IQ ontology
ORM2 helps you determine what the business means so that AI agents are grounded enough to provide accurate responses.
Fabric IQ ontologies operationalize your ORM2 conceptual model.
Some ORM2 Facts Will Become Ontology Relationships
Many business facts in your ORM2 conceptual model will map easily to Fabric IQ ontology constructs. Once again, consider this business fact:
Distributor places Sales Order
As you already know, this fact maps to two Fabric IQ ontology entity types:
Distributor
Sales Order
And an ontology relationship:
Distributor → places → Sales Order
The following business facts are also examples of straightforward mappings:
Sales Order contains Sales Order Line
Sales Order Line purchases Product
These fact types already look like ontology relationships.
This is where the fit between ORM2 and Fabric IQ feels very natural.
Both approaches benefit from relationships with explicit business meaning.
Other Facts May Become Properties
Now consider the following business fact you’ve seen previously:
Distributor has Distributor Name
You probably don’t need Distributor Name to become its own Fabric IQ ontology entity type. It’s more naturally represented as a property on Distributor.
The same could be true for:
Product has List Price
Sales Professional has Quota Amount
So, the ORM2 conceptual model may contain business facts that eventually map to properties in the Fabric IQ ontology.
Don’t think of this as you over-modeling. This is a natural outcome of the ORM2 methodology.
Some ORM2 Constraints May Not Map Directly
This is where you need to be especially careful. ORM2 supports specifying a wide range of constraints. It’s part of what makes ORM2 so powerful.
However, most of the time, you won't be able to translate all of these constraints directly into a Fabric IQ ontology.
Some ORM2 constraints may map to Fabric IQ ontology features quite readily:
Entity keys
Relationship cardinalities
Inheritance
Business rules
Other ORM2 constraints may remain primarily part of the conceptual model and become part of your Generative BI testing suite.
Don’t think that this lack of one-to-one mapping makes ORM2 less useful. A methodology can be richer than the platform it targets:
The conceptual model (i.e., ORM2) tells us what the business means.
The implementation model (i.e., Fabric IQ ontology) tells us which parts of that meaning the platform can operationalize directly.
Document and operationalize the gap between the two (e.g., test cases) as you build your Generative BI solution.
Fabric IQ Business Rules Are Different
Fabric IQ ontologies now support business rules expressed in natural language. On the surface, that sounds very compatible with ORM2’s focus on verbalization.
But I would not treat them as equivalent.
For example, ORM2 constraints have formal semantics. They’re intended to precisely constrain aspects of the conceptual model.
By way of comparison, Fabric IQ business rules are natural-language grounding context for agents and other consumers; the ontology does not execute them. ORM2 constraints, by contrast, formally constrain the conceptual model.
Those are related ideas. They are not necessarily the same thing. For example:
Every Sales Order must be placed by exactly one Distributor
This is a constraint on the structure of the ORM2 conceptual model. If you think about it this way, you can translate it into a mathematical representation.
Now, consider a business rule like the following:
Flag a Sales Order for review when its Discount exceeds the approved threshold
This is an example of operational business logic that you might provide to an AI agent.
Both ideas matter in real-world Generative BI, but they serve different roles in the solution.
A good methodology (e.g., ORM2) should help you distinguish them.
Metrics Are Another Difference
Fabric IQ can carry trusted DAX measures from Power BI semantic models into the ontology as metrics. That’s extremely important for Generative BI.
An AI agent should use the organization’s existing definitions of:
Net Sales
Gross Profit
Margin
Customer Lifetime Value
In other words, your DAX measures are an important form of grounding in Generative BI.
ORM2 is not primarily a metric-modeling methodology. ORM2’s strength is modeling facts, object types, roles, and constraints.
That means your Power BI semantic models that you know and love remain essential for Generative BI.
This reinforces something I’ve argued throughout this newsletter:
The semantic model and ontology should complement each other.
ORM2 improves how you design the ontology conceptually, but it doesn’t replace the analytical semantics already encoded in your Power BI models.
ORM2 As the Design Layer Above Fabric IQ Ontologies
As I work more and more with Microsoft’s Generative BI stack, I find that an increasingly compelling way to build solutions looks like:
Layer 1: Business Facts - Work with business stakeholders to capture business facts in natural language:
Reseller places Sales Order
Sales Order contains Sales Order Line
Sales Order Line purchases Product
Layer 2: Conceptual Model - Use ORM2 to identify object types, roles, and constraints. Validate the model through verbalization and sample data with business stakeholders.
Layer 3: Fabric IQ Ontology - Map the applicable ORM2 conceptual business semantics into:
Entity types
Properties
Relationships
Keys
Inheritance
Rules
Data bindings
Layer 4: Analytics Semantics - Bring trusted Power BI semantic model DAX metrics and analytical meaning into the ontology where appropriate.
Layer 5: Generative BI - Give AI agents (e.g., Fabric data agents) a grounded business context that combines conceptual meaning with trusted enterprise data and analytics.
I want to be clear that this isn’t an official Microsoft architecture.
It’s where my head’s at right now, based on many years of experience in modeling and analytics - and based on where Fabric IQ is at and where Microsoft seems to be going with the platform.
Why This Matters for Power BI Professionals
If you’re a Power BI professional, you might think ORM2 is far removed from your day-to-day work.
And you would be right, to be quite frank.
Microsoft’s investment in features like Power BI’s “Prep data for AI” and Fabric IQ ontologies makes it clear that Generative BI is a new form of work compared to building and maintaining dashboards.
The good news is that, as a Power BI professional, you have a strong foundation to build on if you want to acquire these skills.
For example, you already spend a lot of time translating between business language and technical implementation details (e.g., DAX measures). You probably ask questions like the following all the time:
“What does this metric mean?”
“How are these concepts related?”
“What should this table represent?”
These are conceptual modeling questions. ORM2 simply gives you a more rigorous way to answer them.
And unlike some highly technical ontology modeling approaches (e.g., OWL 2), ORM2 puts natural-language validation at the center of the process.
The goal isn’t to turn you into an ontology researcher.
The goal is to give you a disciplined way to model the business so your business stakeholders and AI agents can readily understand it.
My Current View on All This
Right now, I would describe ORM2 as an upstream methodology for Fabric IQ ontology design.
Not a direct mapping standard.
Not an official Microsoft approach.
And not necessarily the right answer for every project.
That last bullet deserves a bit of explanation.
For many organizations, the first step in their Generative BI journey will likely be preparing Power BI models for AI.
For these organizations, Fabric IQ ontologies will come later to support more advanced Generative BI scenarios (e.g., agentic ad hoc analyses).
So, if you’re not already familiar with semantic model enrichment, start there.
When you’re ready to build the skills needed to move beyond Power BI semantic models, you can’t go wrong learning ORM2.
Time To Switch Gears
As you can tell, I’m all in on a methodology for crafting Fabric IQ ontologies because they enable true enterprise-class Generative BI.
However, I’ve been getting a lot of questions about a new Microsoft feature called App-scoped Copilot, so it's time to switch gears for a bit.
I want to address this because it’s on many Power BI professionals' minds, and I find the feature very interesting.
For example, what happens when Copilot has an entire curated Power BI app, including multiple reports and multiple semantic models, as its context?
What does it do well?
What are the limitations?
And, more importantly, what does Microsoft’s documentation still leave unanswered?
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.