​

Ontology & Knowledge Graph

Telling you what exists is the easy part: this table has these columns, this dashboard reads that table. A Context Platform has to tell you what it means: that cust_acct_bal_amt is a Customer Account Balance, that a Customer Account Balance is calculated from Transactions, that Transactions are regulated by AML, and that anything regulated by AML must be retained for seven years. That second kind of knowledge is what an ontology captures — and once it is captured, OpenMetadata projects it, together with every asset in your catalog, into a single knowledge graph that people and AI agents can query.

​

What Is an Ontology?

An ontology is a formal, machine-readable model of the concepts in a domain, the properties those concepts have, and the relationships between them. A glossary tells you that “Churn Rate” exists and gives you a paragraph of prose. An ontology tells you, in a form software can act on:

• Churn Rate is a Metric.
• It is calculated from Active Subscriptions and Cancelled Subscriptions.
• It is part of the Retention concept.
• It has the attributes unit = percentage and grain = monthly.
• It is exactly equivalent to fibo-fnd:CustomerAttritionRate in an external standard.
• calculatedFrom is not symmetric, so nothing can silently infer the reverse.

The difference matters because the second version is computable. Ask “what breaks if the Cancelled Subscriptions definition changes?” and you get an answer, because the derivation is written down as data rather than described in a paragraph.

​

Why Ontologies Matter Now

Ontologies are a decades-old idea from the semantic web. They are having a moment for a specific and practical reason: LLMs are extremely good at language and extremely bad at knowing which table you meant.

​

Retrieval Is Not the Bottleneck; Disambiguation Is

Ask an agent “what was revenue last quarter?” and it will happily find fourteen tables with a revenue column. Semantic search narrows that down by similarity — but similarity cannot tell you that Recognized Revenue is the one Finance signs off on, that it is calculated from Booked Revenue minus Deferred Revenue, and that the revenue_v2_final table is deprecated. Only a model of the business can. An ontology gives the agent a small, dense, human-curated map of the domain to reason over, instead of asking it to reconstruct that map from thousands of column names on every request.

​

Graph Shape Beats Chunk Shape

RAG over text chunks answers “what does the docs say about X.” Enterprise questions are usually multi-hop and structural:

• “Which dashboards would break if we drop this column?”
• “Everything classified PII that flows into a system outside the EU.”
• “Which of my Tier-1 tables have no owner and no data contract?”

Those are graph traversals, not similarity lookups. A knowledge graph answers them exactly, in one query, with no hallucination surface — because the answer is a set of edges, not a generation.

​

Agents Need Guardrails They Can Read

An agent acting on your data needs to know not just where the data is but what it is allowed to conclude. Typed relationships carry logical characteristics — symmetric, transitive, functional — and OWL axioms carry constraints like disjointness. That is a contract the agent can consult and that OpenMetadata can validate against, rather than a convention living in someone’s head.

​

Semantics Outlive Pipelines

Tables get renamed, warehouses get migrated, dbt models get refactored. The concept Customer does not. Modeling meaning separately from storage is what lets the catalog survive a re-platform — and what lets two systems that disagree about column names still agree about concepts.

​

How OpenMetadata Implements It

OpenMetadata does not ask you to stand up a separate semantic-modeling tool and then reconcile it with your catalog. The ontology is built on top of the glossary you already have. Two consequences worth understanding before you go further:

1. Your relational database stays authoritative. Concepts, relationships, attributes, axioms, and mappings are stored as ordinary OpenMetadata entities with versioning, ownership, reviewers, and change events. Authoring, import/export, impact analysis, and even glossary-scoped SPARQL all work with no triple store deployed.
2. The RDF knowledge graph is a projection. When you enable RDF, OpenMetadata mirrors the ontology and every other entity in the catalog into an Apache Jena Fuseki triple store as a derived index — the same way it mirrors entities into Elasticsearch/OpenSearch for search. That projection is what unlocks catalog-wide SPARQL, reasoning, SHACL validation, graph insights, and the knowledge-graph MCP tools.

​

The Pieces

​

Where to Go Next