Fabric IQ Ontologies Explained

Navy Solv Systems title card reading 'Fabric IQ Ontologies' with a blocks motif.

In Short: What Fabric IQ Ontologies Are

An ontology in Fabric IQ is a shared, machine-readable description of your business: the things that matter (customers, orders, assets, stores), their properties, how they relate, and the rules and metrics that give them meaning. You bind those definitions to data you already have in Fabric, so people, applications and AI agents all work from the same vocabulary.

The ontology item is still in preview. At FabCon Europe 2026 Microsoft announced a new agentic experience for creating ontologies from semantic models, OneLake data and other context documents, and the ability to carry Power BI measures into an ontology. Microsoft Learn now documents a new ontology experience, and the old one retires on 31 January 2027. This post explains what an ontology adds on top of a semantic model, how it connects to data agents, Copilot and graph, where Apache Ossie fits, and whether you should start now.

Where Ontologies Sit in Fabric IQ

Fabric IQ is the pillar of Microsoft IQ that gives agents context about your structured business data. Microsoft Learn describes three layers: unified data in OneLake, business intelligence in Power BI semantic models, and operational intelligence in ontologies. The two core items in the IQ workload are the semantic model and the ontology.

The parts are at different stages, and the labels matter:

Fabric IQ in Microsoft Copilot Chat and Cowork - generally available, announced at FabCon Europe 2026. We cover it in what Fabric IQ means for Power BI users
Ontology item - preview, including generation from semantic models, metrics and the ontology agent
Graph materialised from an ontology - preview
Ontology as a context source in a Fabric data agent - preview
Expansion of Fabric IQ to answer from data agents and ontologies - preview
The IQ workload in Fabric - labelled "IQ (preview)" on Microsoft Learn

The Copilot experience most users see today is grounded in semantic models and reports. Ontologies are the next layer, and they are not production-ready yet.

Ontology vs Semantic Model: What Each One Does

If you already have good semantic models, the obvious question is why you would need anything else. A semantic model is built for analytics: tables, relationships, measures and hierarchies tuned for fast, interactive reporting. It answers "what is the number?" very well.

An ontology describes the business rather than a report. Microsoft Learn lists what it adds:

Entity types that represent business concepts independently of any single table, including keyless entity types and relationships without join tables
Rules written in natural language and linked to entities, properties and relationships, so the same business logic is available to every agent instead of being copied into each prompt
Bindings to many sources at once: semantic models, lakehouses, eventhouses, warehouses, SQL databases, mirrored databases and OneLake shortcuts, views and materialised views
Namespaces, inheritance and shared properties for larger models that span several domains
Version history, plus import of RDF, Turtle and OWL definitions and export to RDF or Turtle

The ontology is not a data store. Microsoft describes it as a virtual semantic and context layer: data stays in the system that owns it, and the consuming experience runs the query against the bound source.

Our view is simple. A semantic model is still where your measures should live. An ontology is worth adding when questions cross domains that sit in separate models, when you need real-time or operational data next to analytical data, or when you have business rules that agents keep getting wrong.

Reusing Power BI Measures: How Metrics Work

This is the part most Power BI teams will care about. You can select Generate ontology on a semantic model and Fabric creates an ontology item with:

entity types that match the model's tables
properties from the columns, with data bindings
relationship types that follow the model's relationships
metrics from the model's DAX measures

Metrics are references, not copies. Microsoft Learn says ontology metrics "proxy measures instead of copying them": the metric keeps a link to the source model and pulls the DAX expression on demand. The formula is read-only in the ontology, so you change it in the semantic model. Descriptions you edit in the ontology stay in the ontology, where agents use them, and never change the model.

The documentation lists a few practical points:

Generating an ontology, and querying semantic models through it, needs both Read and Build permission on the semantic model.
Viewing a measure's underlying DAX needs write permission on the source model.
Each measure appears under the entity for the table it is defined on, even if its DAX references several tables.
Metrics do not update automatically. When a measure changes, you refresh the ontology.
After generation you still have work to do: bind time series data, check entity keys, bind relationship types, rename things into business language, and review the result.

You can also combine several semantic models into one ontology through the ontology agent, which reconciles overlapping tables such as a shared customer table. Today that is the only way to add a second semantic model to an existing ontology.

An ontology generated from a model with cryptic names and no descriptions inherits those problems. Fix the model first using our guide to preparing a semantic model for AI.

Ontologies, Data Agents and Copilot

An ontology does not answer questions on its own. Agents use it as context.

In a Fabric data agent, you can add an ontology as a context source, in preview. The agent uses the ontology's entity definitions, relationships, synonyms and bindings to work out which underlying source answers the question, then generates a source-native SQL, KQL or DAX query and runs it with the requesting user's permissions. You cannot select individual entities, and topics are not supported for ontology sources. A data agent can use up to five sources in any combination. If you are new to data agents, start with how to build a Fabric data agent.

The ontology agent is built into the ontology item. It helps generate definitions and bindings, answers business questions against the ontology, and proposes changes for you to review before they apply.

For Copilot, Microsoft lists an expansion of Fabric IQ to answer from data agents and ontologies as a preview. Separately, Microsoft announced IQ sharing in preview, with native support for Fabric IQ ontologies and Power BI semantic models on the roadmap. Microsoft has not given a date for either reaching general availability.

Security follows the data. Microsoft Learn says authoring and querying respect access to bound data, including OneLake security and source-enforced row-level, object-level and column-level security. That only helps if those controls are right, so test them with real users before you put an agent in front of them.

Graph Analytics Over an Ontology

Some questions depend on the path between things, not a total. Which customers are affected if this supplier fails? These are graph questions.

Every ontology can produce a schema graph, but Fabric does not load instance data into it unless you opt in. When you choose Manage graph, you select the entity and relationship types you need, and Fabric materialises them into a graph in Microsoft Fabric, where entities become nodes and relationships become edges. You can then explore it in a queryset, including path queries. Materialising a graph from an ontology is in preview.

The limitations are significant for Power BI-led estates:

Only delta tables from lakehouses or mirrored databases are supported. Entities bound to a semantic model are not eligible.
Each entity needs an entity type key.
Entities or relationships with multiple backing tables are not eligible.
Materialisation can take from several minutes to several hours, depending on data volume.
The graph does not see source changes automatically. You trigger a refresh or set a refresh schedule on the graph model.

Cost matters too. Microsoft Learn says graph CPU uptime costs 10 CU-seconds per second of your Fabric capacity, with a minimum of 100 GB of storage billed at the OneLake Cache rate. Materialise only the entities a specific question needs.

Apache Ossie: Why an Open Standard Matters

At FabCon Europe 2026 Microsoft affirmed its commitment to Apache Ossie (incubating), which it describes as "a community-led effort to establish a vendor-neutral standard for exchanging semantic metadata". Ossie began as the Open Semantic Interchange (OSI) initiative. Snowflake reports that Microsoft engineers contributed an initial Power BI Ossie converter, and that DAX has been added as a recognised query expression language in the specification.

Treat it as early. Ossie is an incubating project, not a full Apache project, and InfoWorld reports that the current specification is version 0.2, labelled a development draft, which does not yet treat row-level security or access policies as first-class elements. Microsoft has not said how or when Fabric ontologies will exchange definitions through Ossie. Until it does, RDF, Turtle and OWL import and export is the practical route, and Ossie is worth watching rather than planning around.

Should You Start With Ontologies Now?

Our advice depends on where your semantic models are.

Start experimenting now if your semantic models are well named, documented and trusted, you have questions that cross domains held in separate models, or you run operational data in eventhouses or lakehouses that agents need to reason over alongside your KPIs.

Wait, and fix the foundations first, if your measures have names only the author understands, the same KPI is defined differently in different models, or row-level security has never been tested properly. An ontology will expose those problems, not solve them.

If you do start, keep it small:

Ask a Fabric administrator to enable Users can create ontology (preview) items and Users can create Fabric items, in a non-production workspace.
Pick one domain and one set of real questions business users struggle to answer today.
Generate the ontology from your best semantic model, then review keys, relationships and names by hand.
Add a few natural-language rules for the logic agents keep getting wrong.
Connect it to a test data agent and compare answers with your existing reports.
Materialise a graph only if a question genuinely depends on relationship paths.

If you built an ontology in the old experience, use the in-product copy to move it to the new experience before 31 January 2027, then reconnect agents and dashboards and recreate any rules and Activator alerts.

Do not put a preview ontology behind a business-critical process. Statuses and behaviour can still change.

How We Help

We help organisations get the foundations right before adding new layers. That means semantic models named in business language, consistent measures, tested security, and a clear view of which questions an ontology or data agent should answer. Our AI and automation team designs and builds ontology pilots and Fabric data agents grounded in your existing Power BI models, with the governance in place before anything reaches users.

Sources and Further Reading

Frequently asked

An ontology is a Fabric IQ item that describes your business in business terms: entity types such as Customer or Order, their properties, relationships, natural-language rules and metrics. You bind those definitions to data already in Fabric so people, applications and AI agents share one vocabulary. The ontology item is in preview.

A semantic model is built for analytics and fast reporting, with measures, relationships and hierarchies. An ontology describes the business across sources: it can bind to semantic models, lakehouses, eventhouses, warehouses and more, and adds rules, namespaces, inheritance and versioning. Measures should still live in the semantic model; the ontology references them as metrics.

No. When you generate an ontology from a semantic model, measures appear as metrics that proxy the source measure. The DAX expression stays owned by the semantic model and is read-only in the ontology. Metrics do not update automatically, so refresh the ontology when a measure changes.

Yes, in preview. You add the ontology as a context source; the agent uses its definitions and bindings to pick the right underlying source, then runs a SQL, KQL or DAX query against that source with the user's own permissions. Entity selection and topics are not supported for ontology sources.

Not directly. Materialising a graph from an ontology is in preview and currently supports only delta tables from lakehouses or mirrored databases. Entities bound to a semantic model are not eligible, and each entity needs an entity type key.

Apache Ossie (incubating), formerly the Open Semantic Interchange, is a community effort to create a vendor-neutral standard for exchanging semantic metadata. Microsoft affirmed its commitment at FabCon Europe 2026 and contributed an initial Power BI converter. The specification is still an early draft, so treat it as something to watch.

Experiment now if your semantic models are well named, documented and trusted and you have questions that cross domains. If measures are cryptic, KPIs are defined inconsistently or row-level security is untested, fix those first. Either way, keep ontologies away from business-critical processes while the item is in preview.