Lesson 6 of 8 · 9 min
Semantic Models and Ontologies
A semantic model and an ontology both add meaning to data, but they solve different problems.
The fastest way to remember the distinction is:
A semantic model gives analytical definitions one governed place to live and be reused. An ontology makes business relationships explicit.
Another way to picture it: a semantic model is a trusted calculator with agreed formulas. An ontology is a map of the business, showing what the important things are, how they connect, and which rules or actions belong around them.
What a semantic model provides
A Power BI semantic model organizes data for analytics.
It defines:
- Measures
- Dimensions
- Hierarchies
- Relationships
- Calculation logic
- Security
It is excellent for questions such as:
- What is retention by program?
- How many high-risk students are assigned to each advisor?
- How did attendance change by term?
The questions are primarily about trusted numbers under a defined filter context.
What an ontology provides
The ontology item in the preview Fabric IQ workload models the business through:
- Entity types
- Properties
- Relationships
- Rules
- Action context
Instead of seeing only tables, the system can reason about concepts such as:
- A Student enrolls in a Program.
- A Student is assigned to an Advisor.
- A CourseAttempt belongs to a Course.
- A RiskAssessment describes a Student at a point in time.
- An Advisor can initiate an intervention.
This becomes useful when a question crosses concepts or needs an operational next step. The ontology supplies meaning and context; a consuming agent, such as an operations agent, is responsible for executing governed actions.
A practical comparison
Consider:
Which programs have the lowest retention rate?
A semantic model is likely enough. The question asks for a trusted metric grouped by a dimension.
Now consider:
Which high-risk students are affected by courses with rising failure rates, who advises them, and which intervention applies?
This question crosses students, courses, programs, advisors, risk assessments, and intervention rules. An ontology can make those relationships and actions explicit.
They work together
The choice is not always semantic model or ontology.
A production architecture may use:
- The semantic model for trusted measures
- The ontology for business entities and relationships
- The data agent as the conversational analytical interface
- A Foundry agent for broader orchestration
Fabric IQ can generate a starting ontology definition from a semantic model. That can preserve terminology and accelerate modeling, but it does not eliminate the design work.
Table relationships do not automatically become a complete business ontology. Rules, operational relationships, actions, ownership, and exceptions still need to be defined.
Generation also has important preview limitations. Import, DirectQuery, and Direct Lake models can contribute definitions, but usable data bindings are primarily supported for qualifying Direct Lake models. Import and DirectQuery generation does not create queryable data bindings, measures and calculated columns are not available through generated bindings, and relationship bindings require keys and careful review.
Current preview boundaries
Ontology capabilities and generation from semantic models are currently preview features. Preview behavior and limitations can change.
Current constraints can include workspace, connectivity, storage-mode, table-management, relationship, and data-type limitations.
Do not make a preview feature the only path to a critical production outcome without:
- Confirming tenant availability
- Reviewing supported configurations
- Testing deployment and security
- Defining a fallback
- Rechecking documentation before release
Decide whether you need one
Use a semantic model alone when:
- Questions remain inside one analytical domain
- Trusted measures already exist
- Relationships are primarily used for grouping and filtering
- The agent only needs to answer what happened
Consider an ontology when:
- First-class entity traversal is central to the experience
- A shared cross-domain vocabulary is a major requirement
- Entity-level relationships, constraints, or rules must be explicit
- Preview status is acceptable for the workload
An ontology can provide context for an operational decision, but it does not authorize, confirm, or execute the action. Those responsibilities remain with the consuming agent and action tool.
Exercise: model one decision
Choose one decision from your reliability contract.
Create two diagrams. They can be simple boxes and arrows. The purpose is to expose what the decision requires, not to produce presentation-quality architecture.
Semantic view
List:
- Measures
- Dimensions
- Filter paths
- Required security
Ontology view
List:
- Entity types
- Relationships
- Rules
- Permitted actions
Now ask:
- Can the decision be supported by metrics alone?
- Does it require tracing relationships?
- Does the agent need to recommend or initiate an action?
- Is preview acceptable for this workload?
Use the answers to choose the simplest sufficient architecture.
Carry this forward
The Fabric Data Agent is now a reliable analytical specialist over your governed data and business context.
In the next lesson, we will place that specialist inside a broader Foundry agent workflow so data analysis can support a multi-step business outcome.