Ontologies are not new. The standards are open, well-documented, and decades old.

What is new is that major vendors are now selling them. A good reason to understand what we're being sold before we buy.

• Term: the string "customer"
• Concept: what you mean by it
• Referent: the actual person

A database column is a term. The semantics live in the concept, which usually lives nowhere except in someone's head.

• Universe: everything we model lives in Thing.
• Class: a set of things (Person, City, Organisation).
• Subclass: a set inside a set (Company ⊆ Organisation).
• Disjoint: sets that share nothing (Company ∩ NonProfit = ∅).
• Element: an instance of a class (Alice ∈ Person).
• Relationship: directed between classes.

Not metaphysics. Just disambiguation at scale, that machines can check.

Everything in this section so far has come from two old traditions:

Philosophical logic gives us concepts, terms, definitions, categories. What we mean.

Mathematical logic gives us sets, relations, inference. How machines can check what we said.

Strings are ambiguous. The atom of a knowledge graph is the IRI: a globally unique identifier.

<crm:cust-4711>     a  ex:Customer .

<billing:acct-882>  a  ex:Account .

<zendesk:user-39>   a  ex:Contact .

Three systems, three IRIs, three meanings. No more COALESCE on email columns hoping that two systems spelled it the same way.

This is how schema.org, Wikidata, and Google Knowledge Graph all work.

It's not exotic. It's the quiet backbone of the modern web.

Subject — Predicate — Object. That's it.

<ex:Alice>  a                   ex:Customer .
<ex:Alice>  ex:hasSubscription  ex:ProPlan .
<ex:Alice>  ex:signedUpOn       "2026-01-15"^^xsd:date .

URIs are global identifiers. Same URI in two datasets = same thing. This is the whole basis for federation.

Classes, subclasses, properties with domain and range. Nothing more.

# Schema
ex:Customer  rdfs:subClassOf  ex:Party .
ex:hasSubscription
              rdfs:domain      ex:Customer ;
              rdfs:range       ex:Subscription .

# Data
ex:Alice ex:hasSubscription ex:ProPlan .

If you only ever do this much, you've already eliminated half the ambiguity in your data warehouse.

OWL is RDFS with set theory turned on.

• Disjoint classes
• Cardinality restrictions
• Inverse and transitive properties
• Equivalence axioms

A reasoner can now derive facts you never stated explicitly. That's the magic, and the responsibility.

# Already declared in the schema:
ex:hasSubscription rdfs:range ex:Subscription .

# Then we state this fact:
:Alice ex:hasSubscription :ProPlan .

# Reasoner concludes:
:ProPlan rdf:type ex:Subscription .

# Without anyone writing it down.

Where OWL says what can be inferred, SHACL says what must hold.

ex:CustomerShape a sh:NodeShape ;
  sh:targetClass ex:Customer ;
  sh:property ex:HasSubscriptionShape .

ex:HasSubscriptionShape a sh:PropertyShape ;
  sh:path     ex:hasSubscription ;
  sh:minCount 1 ;
  sh:class    ex:Subscription .

This is what makes semantic tech production-ready:

• Closed-world: silence is denial
• Validation reports, not inferences
• Complements OWL, doesn't replace it
• Standardised in 2017, mature tooling

Most enterprise pipelines need SHACL more than OWL. Start here.

PREFIX ex: <https://ex.org/>

SELECT ?customer ?planLabel
WHERE {
  ?customer a                   ex:Customer ;
            ex:hasSubscription  ?plan ;
            ex:signedUpOn       ?date .
  ?plan     rdfs:label          ?planLabel .
  FILTER(?date >= "2026-01-01"^^xsd:date)
}

If you can read SQL, you can read this.

The real superpower: federated queries across multiple SPARQL endpoints in a single statement.

from maplib import Model
import polars as pl

m = Model()

# Integrate heterogeneous sources
m.map_default(pl.read_delta("s3://lake/customers"),    primary_key_column="customer_iri")
m.map_default(pl.read_delta("s3://lake/subscriptions"), primary_key_column="sub_iri")

# Model business concepts
m.read("ontology.ttl")

# Reason and query
m.infer(open("rules.dlog").read())
df = m.query(open("customers_with_pro_plan.rq").read())

# Validate
m.read("shapes.ttl", graph="urn:g:shapes")
report = m.validate(shape_graph="urn:g:shapes")

One script. Four jobs:

• Integrate two Delta tables into one graph through shared IRIs (no JOIN, no COALESCE).
• Model business concepts by loading the ontology you already wrote.
• Reason over the data using Datalog or SPARQL rules.
• Validate against SHACL shapes and get a structured report back.

All on a Polars-backed engine. DataFrame speeds, semantic richness.

Built on the EU's SEMIC work, mandated for public-sector data:

• DCAT-AP-NO: data catalogues
• SKOS-AP-NO: controlled vocabularies
• DCAT-AP-NO-SSB: statistical data
• Begrepskatalogen: shared business concepts
• data.norge.no: built on this stack

If your platform makes it hard to expose data as DCAT-AP-NO or hold a SKOS vocabulary, your platform makes compliance hard. That is a real cost, paid by real teams.

Gartner's strategic planning assumption for 2027:

And yet: only 26% of D&A leaders polled at the 2026 Gartner summit said they were already using ontologies in AI projects.

The gap between expected impact and current adoption is where the opportunity sits.

What Gartner recommends:

• Prioritise ontology development in the use cases where it pays off fastest.
• Adopt standards-based approaches (W3C) for long-term value and interoperability.
• Collaborate across teams — business and technical experts together.
• Use agile methods: minimum viable ontologies, minimum viable graphs.

An LLM can be fluent. Fluency is not accuracy.

When an agent does something — approves an expense, transfers data, contacts a customer — you need more than confident output. You need:

• A formal model of what things mean
• Constraints the agent cannot violate
• A semantic audit trail for every decision
• Federation across decoupled systems

That's a knowledge graph. SHACL gives you the guardrails; the ontology gives you the meaning; the graph gives you the audit.

The semantic web community has been building exactly this infrastructure for two decades.

Agents are finally creating the demand to use it.

You now have the vocabulary. Brian will show you how Fabric IQ implements this thinking in the Microsoft stack.

A few questions worth holding in your head:

• What is the Ontology item built on, RDF or LPG?
• What's the query language? What goes in, what comes out?
• How does it meet DCAT-AP-NO and SKOS-AP-NO?
• If I leave the platform, what comes with me?

These aren't gotcha questions. They're the ones you need answered to build responsibly.