Do You Actually Need an Ontology?
Key takeaways
- Sometimes the answer is no, and the people saying so are not all selling something.
- A glossary, a semantic layer or a vector index each solve a real problem, and cheaply.
- None of them can record what the organization agreed, or who agreed it, or what it replaced.
- The test is whether anything you do depends on a definition two teams would answer differently.
Do you actually need an ontology? Sometimes the answer is no, and the people telling you so are not all selling something.
What the sceptics get right
Three things, stated plainly, because any of them can sink a project.
Upper-ontology programmes have a near-total failure record, and the discipline says so itself. Practitioners writing in 2026: "Every effort to create an upper ontology that serves both as a precise computational foundation and as a broad interoperability framework has either failed outright or survived by becoming so general as to require substantial domain-specific work to make it useful." The same source concludes that for most projects you do not need an upper ontology at all.
Modelling everything before shipping anything kills the project, usually inside a year.
Most ontologies that do get built are never maintained. The incentive is to freeze definitions, because changing one in production hurts.
What the alternatives actually solve
Not grudgingly, because each of these is the right answer to a real problem.
| If your problem is | The cheaper answer | Where it stops |
|---|---|---|
| Nobody can say what a term means | A glossary | It records a definition, not an agreement, and nothing checks against it |
| The same measure is calculated differently in different places | A semantic layer | It governs measures, not the meaning of the entities underneath them |
| Retrieval is the bottleneck and answers are approximate | A vector index | It finds similar things. It cannot say two records are the same thing |
| One system needs internal consistency | A well-designed data model | Correctness inside a schema says nothing about agreement across schemas |
| Something acts on a contested definition without a person checking | An ontology, governed | This is the case the others do not cover |
A glossary fixes a definitions problem. If nobody can say what churn means, write it down. A semantic layer resolves measures well: one place where revenue is calculated, consistently. A vector index is cheaper to keep current than anything described here, for a structural reason. It is append-only by default. Nothing breaks when you add to it, because nothing was asserted.
If one of those is your problem, stop reading and go do it.
What none of them can do
Three things, narrowly.
A glossary defines a term for a human. It is not machine-readable and carries no relationships. That is why the same vendors pitching a glossary as sufficient also publish, elsewhere on their own sites, that a glossary defines the human-readable layer and an ontology is what makes that layer machine-readable. Both sentences are theirs. The second is correct.
A semantic layer resolves how a number is calculated. It says nothing about what a thing is, and it will not tell you whether two records are the same customer.
None of them records who decided. An inferred structure can tell you how people currently query the data. It cannot tell you what anyone agreed it means, what that definition replaced, or when it expires. In an enterprise, an ontology is the agreed answer to two questions. What are the organization's core things, and how do they relate? Every person, system and agent then resolves those questions the same way. The full definition is here.
That is an additional argument, and it does not replace the portability one: a model you cannot take with you is still not an asset you own.
A test worth applying, from the other side
The canonical argument against ontologies, published in 2005, is more useful than most arguments for them, because it gives conditions.
On participants it says ontology works where you have expert catalogers, an authoritative source of judgment, coordinated users and expert users. An enterprise has that entire column. On the domain it says formal categories, restricted entities and clear edges. An enterprise scores well there too.
It fails on exactly one criterion: stable entities. Products change, regulations change, and the definition of an active customer changes when somebody in finance decides it does.
So the best-argued case against doing this says an enterprise is a good candidate except that its things keep changing. That is not a reason to skip the model. It is the specification for what the model has to do, and it is why keeping an ontology current is the discipline. The essay's own example is a classification that was right when it was made, wrong later, with no mechanism for anyone to notice.
So: do you need one?
If your problem is vocabulary, a glossary. If it is inconsistent metrics, a semantic layer. If it is retrieval over documents, an index. If your problem is that two teams give different correct answers to the same question, the answer is yes. If an agent is about to act on a definition nobody owns, the answer is yes. The next question is how small you can make it. Scope it to one decision the business already argues about.
The achievable claim is narrower than the one that burned this category twenty years ago. One contested definition, governed, in production, in weeks. Not the enterprise, modelled.
What makes that version achievable now
- You are not starting from a blank page. Established standards-based models exist for most of what an enterprise needs. TopQuadrant maintains 300+ reusable models, including FIBO, SKOS and Schema.org, so the first move is extension.
- Inference does the first draft. AI proposes definitions, relationships and rules perfectly competently. Nothing becomes ground truth until the people accountable for it agree, and that review is the point.
- Open standards keep the result portable. RDF, OWL and SHACL mean the model is readable by tools other than the one you built it in. A platform decision later never becomes a re-authoring project.
- One definition is a real unit of work. It can be scoped, shipped against a single consumer, and judged, which is what scoping properly is about.
The practice of keeping that agreement true afterwards, with a named owner and a review trail behind each definition, is ontology management. The tooling side of it is TopQuadrant's platform. If the answer to the question in the title is no, none of that applies, and the glossary is the right next thing to write.
So what should I take away?
I do not need an ontology to run a dashboard. I need one the moment a system starts acting on an answer without a person checking it. By then I needed it a year ago.
So the real question is about timing. How much warning will I get before I need one? TopQuadrant's answer is to start with the single definition two teams already argue about. That is small enough to finish and real enough to matter, and it is the cheapest insurance against the day the warning does not come.
