Build a Fabric Ontology over Your Data

Learning Objectives

• Understand what a Fabric Ontology is and when to add one to a workspace.
• Create an Ontology item in your workspace.
• Define entity types (Patient, Train, Region) and bind them to your Lakehouse + Eventhouse data.
• Define relationships across domains so cross-domain questions become traversal, not joins.

Why Add an Ontology?

Up to this point you've built a complete data stack: a real-time Eventhouse, a Lakehouse, a Direct Lake semantic model. Every consumer - dashboards, reports, agents, Copilot - still has to know which table holds which fact and how to join them. That overhead is paid on every new question.

A Fabric Ontology removes that overhead. You define the conceptual model once - "a Patient has Vitals, is admitted to a Hospital, and lives in a Region. A Train runs on a Line and serves Regions" - and bind each entity to the tables that already exist in OneLake. Every Data Agent, M365 Copilot prompt, and Foundry orchestrator you build downstream then speaks the same vocabulary.

The UrbanPulse Ontology You'll Build

Below is the entity-relationship sketch for this lab. It spans both customer domains (health, transit) plus a shared Region entity that stitches them together. That shared entity is what enables cross-domain questions in Module 9.

Step 1 - Create the Ontology Item

1. Open your workspace

   From the Fabric portal, navigate back to urbanpulse-{your-user-id}. By now you should have: a Lakehouse, a Mirrored DB, an Eventhouse, a Real-Time Dashboard, and a Direct Lake semantic model.

2. Create a new Ontology

   Click + New item → search "Ontology" → pick Ontology (preview).

   Name it: ont_urbanpulse → Create.

   📷

   SCREENSHOT NEEDED

   module-7/01-create-ontology.png

   "New Ontology" item creation dialog with name ont_urbanpulse

   ⓘ

   Ontology item vs. semantic model. A Power BI semantic model (Module 6) is tabular and tuned for measures + reports. A Fabric Ontology is a graph, tuned for entity-centric questions and AI grounding. They coexist and complement each other.

Step 2 - Define Entity Types & Bind to OneLake

An entity type is "the conceptual thing" plus a binding to where its data actually lives.

1. Add the Patient entity

   In the Ontology editor, click + Add entity type. Configure:

   • Name: Patient
   • Display name: Patient
   • Source: Eventhouse eh_urbanpulse_rti → HospitalVitals
   • Identity property: patient_id
   • Other properties: age, gender, condition, diagnosis_code

   📷

   SCREENSHOT NEEDED

   module-7/02-entity-patient.png

   Entity type editor for Patient with binding to HospitalVitals KQL table

2. Add Train the same way

   Repeat the pattern with this binding:

   Entity	Source	Identity	Properties
   Train	Eventhouse → TrainTelemetry	trainId	line, status

3. Add the cross-domain entities

   Two entities don't come from the streaming KQL tables. They're logical, bound to existing tables already in the Lakehouse from Module 2:

   • Hospital → Lakehouse lh_urbanpulse_bronze → mirrored SQL table Hospitals
   • Region → Lakehouse regions table (mirrored from Cosmos)

   ✓

   Both tables already exist in lh_urbanpulse_bronze from Module 2's mirror + shortcut steps - no extra setup required. If you skipped Module 2, the rest of the ontology still works without these two entities.

Step 3 - Define Relationships

This is where an ontology earns its keep. You're declaring the meaningful connections between entities so a downstream agent can traverse them without having to know SQL joins.

1. Add the same-domain relationships

   In the Ontology editor, click + Add relationship and create these three:

   From	Name	To	Cardinality
   Patient	admitted_to	Hospital	many-to-one
   Train	on_line	Line (or store as a string property if you skipped Line as an entity)	many-to-one

2. Add the cross-domain relationships

   These cross-domain relationships are what enable Module 9 to answer questions spanning hospitals and transit without bespoke SQL:

   From	Name	To	Why it matters
   Hospital	in_region	Region	"How's hospital load in this region?"
   Line	serves_region	Region	"Are trains for this region delayed?"

   📷

   SCREENSHOT NEEDED

   module-7/03-relationships.png

   Ontology relationships pane showing the three cross-domain edges into Region

What You Just Built

• An Ontology item ont_urbanpulse in your workspace.
• Four entity types - Patient, Train, Hospital, Region - bound to your Eventhouse + Lakehouse data.
• Four relationships, two of which cross domain boundaries via the shared Region anchor.
• A validated semantic graph that the Module 8 Data Agent (and the optional Module 9 multi-agent catalog and Module 10 orchestrator) will ground on.

References

• OneLake Catalog Overview - discover, govern, and reason over your data estate.