What Is Ontology Management?
Key takeaways
- Every company already has ontologies. They sit on whiteboards, in spreadsheets, in explainer docs and in people's heads.
- Formalization requires giving up individual control to create a shared reality. That is the hard part, and it is organizational.
- Informal models fail in five ways: clashes, gaps, desired inconsistency, ambiguity, and localization across domains.
- Six capabilities decide whether a system can manage ontologies: governance on shape, change history, versioning, audit, access, and automation.
Ontologies hold the meaning that interconnects data. Used accurately and widely, an ontology gives a common interpretation of the core elements the business runs on. Its references. Its entities. Its processes. And the rules attached to them. This is what the original semantic layer was built around, before the term drifted toward metric definitions.
Ontology management is the practice of operating an ontology as an enterprise asset. It carries agreed meaning across the domains, systems and agents that depend on it, and holds it under the named ownership, approval and change control that keep it ground truth instead of inference.
Does your company already have ontologies?
They exist informally, in everyday speech. Ask anyone in the business how the company works and you will get one. Customers have products. Products have prices. Prices depend on geography, demography and contract terms. Nobody calls that an ontology. It is one.
What varies is the form they are captured in. Whiteboards from a workshop two years ago. A spreadsheet tab mapping one system's product codes to another's. Explainer documents written for onboarding and never updated. Implicit knowledge held by the person who has been there nine years. And now, increasingly, models autogenerated by AI from schemas and query logs.
Every one of those is a real model of the business. None of them is authoritative.
What is ontology management in an enterprise?
It is the formalization of those implicit and inferred sources. The relationships are already described somewhere; collectively they live in the brain and the code of your company. Formalization moves them into one place where a system can read them and a person is accountable for them.
The reason this is hard has little to do with modelling notation. Across all those informal sources there is no authoritative truth, so there is no answer to the only question that matters: which ontology is the ontology?
Five ways informal models fail
- Clashes. Two definitions of the same concept, both in active use, both correct inside their own system, producing two different numbers for one question.
- Gaps. Concepts everyone assumes are modelled somewhere and which are modelled nowhere, discovered at the moment something depends on them.
- Desired inconsistency. Two teams holding two definitions that do not need reconciling. Risk means something different in credit from what it means in operations, and forcing those into one definition destroys information.
- Ambiguity. One term, several readings, none written down, each reader confident they hold the common one.
- Localization and cross-domain operations. A definition correct in one region, one regulatory regime or one business unit, and silently wrong the moment work crosses that boundary.
Desired inconsistency is the one most programmes get wrong. The instinct is to reconcile everything, and reconciling a difference that exists for a good reason is how a formalization effort loses the people whose agreement it needed. A system that cannot represent a deliberate difference will be worked around.
What are the elements of an ontology management programme?
Formalization requires giving up individual control to create a shared reality. That is the whole of it, and it is why this is organizational work. The programme exists so subject matter experts can collectively define the relationships the business runs on. Each of them accepts an answer they did not author.
Six elements make that possible. A programme missing any of them degrades predictably.
| Element | What it means | What goes wrong without it |
|---|---|---|
| Ownership | A named person accountable for each contested definition, not a team or a function | A disagreement has nowhere to go. A team cannot be asked why |
| Approval | A standard to approve changes against: competency questions, consuming systems, external commitments | Approval becomes a rubber stamp and a regulatory commitment breaks silently |
| Review trail | What changed, who approved it, what it replaced, when | Last quarter's number cannot be explained, because nobody knows which definition produced it |
| Change policy | Which classes of change apply automatically, which are proposed for review, which are blocked | Either definitions move with nobody asked, or every trivial addition queues behind a human and people route around the model |
| Expiry | A review date set when the definition is agreed | Definitions nobody revisits quietly stop describing the business |
| Downstream tracking | Which systems still consume the previous version | A change nobody notices surfaces six weeks later as an argument about a number |
Deciding the change policy once per class of change is what makes the rest tractable. Deciding it per change is what makes it impossible. The method is in keeping an ontology current.
What is the impact of getting it right?
- Disputes end with a citation. The definition, its owner and its approval date settle an argument that used to take a meeting.
- Numbers become defensible. A figure going to a regulator or a board traces to the definition that produced it and the person who agreed it.
- Agents can act. A system resolving meaning against a governed model is acting on something the organization stands behind, which is the precondition for letting it act unsupervised.
- Integration stops being bespoke. Systems sharing no schema share semantics, so an integration survives one side changing.
- Onboarding compresses. New staff read how the business works instead of absorbing it by rumour over two years.
- Entity resolution stops repeating. Deciding once that these three records are one customer means the next project inherits the decision.
Why manage ontologies as enterprise artifacts?
Because an ontology encodes agreements that exist nowhere else, and it is the only asset that spans domains. That is exactly why no single domain owner can govern it alone.
Your definition of a customer is not a CRM concern. Finance uses it to recognise revenue. Legal uses it to determine which contract governs. Support uses it to establish entitlement. And now every agent acting on any of those. Hand it to one of those functions and they will optimise it for their own use, correctly, and the others will quietly keep their own version. The intellectual property point and the named ownership point are the same point. This is company knowledge. It spans the company, and it needs an owner who answers to the company. The artifact itself, and how it differs from a data model, is covered in what an ontology is.
What capabilities does an ontology management system need?
Six, and they are the criteria worth taking into any evaluation.
| Capability | What it has to do | Why a general data tool struggles |
|---|---|---|
| Governance on the shape of an ontology | Review and approve changes to classes, properties, relationships and constraints | Most governance is built for tables and columns, so it governs the container and not the meaning |
| Change history | Every change to a definition, with its author and its reason, queryable | History designed for data assets records that something changed, not what it now means |
| Versioning | Named versions consumers can pin to and migrate between | Without it, every change is a breaking change to somebody downstream |
| Audit | Evidence that a definition in production was approved by someone with standing | A log of edits is not an audit trail of decisions |
| Access | Control over who may propose, who may approve and who may publish | Read and write permissions do not express an approval role |
| Automation | Detect change at the source, draft proposals, route them, enforce constraints | Automation that applies changes with no approval step is drift with a scheduler |
Automation belongs on that list without apology. Detection and drafting are genuinely better done by machine, and AI can generate a usable first draft. The distinction is that proposing and committing are separate acts, and only one of them can be automated.
Why a separate system?
So you are not trapped. Open standards are the point. A model expressed in RDF, OWL, SKOS and SHACL is readable by tools that have nothing else in common, so it outlives the platform holding it today. TopQuadrant's team helped author those standards, and the practical test for any vendor, this one included, is simple: if you left, what would you take, in what format, and what would stop working?
Interoperability. The model should feed and drive many systems while locking you into none of their designs. That is only possible when the model is expressed in something none of them owns.
Specialized capability. Governing the shape of an ontology is a different job from governing a table, and the six capabilities above are not a subset of catalog features. They are a different feature set that happens to sit nearby.
The curators are specific people. The teams who know and curate these assets are modellers and subject matter experts, and tools built for data stewards do not serve them well. Reuse matters here too: starting from one of 300+ reusable standards-based models means an SME reviews recognisable concepts instead of notation, and validation with SHACL turns each agreement into something a system can enforce.
Why can't I manage ontologies in my catalog?
You can, if your catalog has the six capabilities above. The question deserves a serious answer, because a catalog is genuinely the right home for finding data, describing it and knowing who touched it. Several catalog vendors now ship ontology capability on the same open standards described here, so anyone claiming catalogs cannot do ontologies is making a claim you can disprove in a click.
The question is not whether a catalog can hold an ontology. It is whether it can govern one.
Here is how the three catalogs most often proposed as an alternative measure against those six capabilities, as of October 2026. This market moves fast. An early-access product now may be generally available by spring, so date anything you carry out of this section.
| Platform | What it is built for | Where it falls short |
|---|---|---|
| Atlan | One metadata graph, with a glossary linked to the tables beneath it and agents that bootstrap a model automatically. |
|
| Collibra | Glossary-led governance over what terms mean, which data is certified, and who may access it. |
|
| Alation | Cataloguing data assets and governing their use. It positions itself beneath semantic layers and ontologies, not as the place you build one. |
|
How to read it
Collibra governs the assets and leaves the model to IT. There are two layers in their platform: the operating model, which is the shape, and the assets that sit on it. Workflows and approvals reach the assets. The shape is changed by a platform administrator. So renaming a business term earns you a review workflow, and redefining what a Customer is becomes an administration task nobody reviews. That is backwards for anyone whose actual problem is the model.
Atlan sells a versioning story the product does not deliver. Branching, staged rollouts and rollbacks are the pitch. What the product builds is a repository that goes from Draft to Active, and a change log that covers the glossary rather than the model. When they demo it, ask to see a rollback on the model itself. Watch which surface they open.
Alation is not ready, and says so. Ontologies entered early access in September 2026 with no versioning, no change history, no audit, and no access control. The extraction step is well judged: experts correct a candidate before it counts. Everything that keeps that decision true six months later is still missing.
All three generate models with AI, and only one of them stops to ask. Alation puts an expert in front of the candidate. Atlan lets high-confidence output apply itself and pauses only on asset selection. Collibra's agents are in preview with no approval step at all. Automation that commits without a signature is not governance. It is drift on a schedule.
And none of them carries the approval forward. The named owner, what the definition replaced, what is still pinned to the old version: that record exists in no catalog in this comparison. A model that exports cleanly and leaves its governance behind has handed you the file and kept the agreement. Ask every vendor for it, this one included. It is the question that separates a model you own from a file you downloaded.
Which questions should guide your decision?
- Which definition is contested right now? If you cannot name one, you do not need this yet.
- Who would sign it? If no individual can, you have an authority problem, and no tool fixes that.
- What happens to the model if you change platforms? Ask it of every vendor, including this one.
- Can a change be proposed, reviewed and approved as separate acts? If approval is just write access, there is no governance.
- What downstream is pinned to the current version? If nobody knows, a change is a silent outage waiting for a quarter end.
Start with one definition two teams have already argued about this year. Give it a named owner, record what changed and who agreed it, set a review date, and wire it into one system that consumes it. One definition governed properly tells you more about whether your organization can do this than a complete model nobody has signed. The practical shape of that first step is in scoping an ontology so it ships, and the platform side is TopQuadrant's ontology tooling.
So what should I take away?
Ontology management is critical to managing my enterprise data systems. Without a dedicated tool and system, I will be struggling to wrangle meaning across my teams and domains. With it, I really can unlock the potential for AI.
The ontologies already exist in my organization. The only open question is whether anyone owns them. TopQuadrant exists to make that question answerable.
