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 and the paradigm changed underneath it.
Ontology management is the practice of operating an ontology as an enterprise asset: carrying agreed meaning across the domains, systems and agents that depend on it, and holding it under the named ownership, approval and change control that keep it ground truth rather than inference.
Your company already has 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 and 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, which means 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, not once per change, is what makes the rest tractable. The method is in keeping an ontology current.
What is the impact of getting it right?
This work is usually argued for in terms of tidiness, which is why it loses budget arguments to anything with a revenue line attached. The outcomes are commercial, and they land in six places.
- AI you can actually deploy. Agents get more accurate because every one of them resolves meaning against the same shared reality and interprets the business the way the business understands itself. An agent guessing at what a customer is will be confidently wrong in a way nobody can see from the output. Governed meaning is the precondition for letting a system act without a person checking its work, which is the difference between a pilot and production.
- Regulatory and board exposure drops. A figure going to a regulator traces to the definition that produced it, the person who approved it and the date they did. Defensibility stops depending on whether the analyst who built the report still works here.
- Decisions stop stalling on definitional argument. Cross-functional disputes end with a citation instead of a meeting. What is being recovered is executive time and decision latency, not neatness, and in most organizations the same three definitions cause the same argument every quarter.
- Integration cost falls structurally rather than incrementally. Systems sharing no schema still share semantics, so an integration survives one side changing. Each new system joins against one model instead of adding another bespoke mapping to a set that grows with the square of the systems.
- Institutional knowledge stops walking out of the building. New staff read how the business works rather than absorbing it by rumour over two years, and the model held by the person who has been here nine years sits in an asset the company owns instead of in their head.
- Work done once compounds instead of repeating. Deciding that these three records are one customer, or that this hierarchy is the reporting hierarchy, is a decision every later project inherits. Without it each programme re-resolves the same entities and re-litigates the same hierarchy, and pays for it again.
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 to determine which contract governs, support 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 hold one in a catalog. Governing one is a different job, and it is the job the catalogs were not built for. Here is where each lands.
| Platform | What it is built for | What it is missing |
|---|---|---|
| Alation | Cataloguing data assets and governing their use. It positions itself as the layer beneath semantic layers and ontologies, not the place you build one. | The model does not live here. Definitions get pushed into the warehouse as views, and nothing published describes RDF, OWL, SKOS or SHACL, or approval on a model's structure. |
| Collibra | Glossary-led governance over what terms mean, which data is certified, and who may access it. | Export, not authorship. RDFS/OWL comes out as a file. The workflows govern terms and data assets, never classes, properties, relationships or constraints. |
| Atlan | Unifying metadata in one graph, with a glossary linked to the tables that implement it and agents that bootstrap a model automatically. | Generation without commitment. Versioning, change history and approval are documented for data assets; none of the three is documented for ontology elements. Nothing says who signs a generated model. |
Key questions to guide your decision
Five to put to yourself before you commit to a programme, and to any vendor before you commit to a platform. Uncomfortable answers are the useful ones.
- 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.
