Do I need an ontology?

Usually not. If your problem is that people define a term differently, start with a glossary. If records do not join, fix shared identifiers. If numbers disagree, build a metrics layer. An ontology earns its cost only when the meaning of the relationships between things drives decisions or automation.

What is the cheapest fix for inconsistent definitions?

A written glossary with one owner per term. It costs a few pages and an hour of argument. Try it before any modeling tool.

When does an ontology earn its complexity?

When many sources describe the same things in different ways, and you need rules or inference across them, and people will keep the model current. If one of those is missing, a simpler tool is the better choice.

Do You Really Need an Ontology?

Short answer: most teams do not need an ontology. They need one of three smaller things first. I would try them in order, and stop at the first one that fixes the problem.

This essay helps you pick. It is for a founder or CTO with a small data team, not for a research group.

Start with the symptom, not the tool

People reach for an ontology when something feels inconsistent. The feeling is real. But the cause is usually narrow. Name the symptom first.

Two people use the same word for different things. This is a definition problem.
Records from two systems do not join. This is an identifier problem.
Two dashboards show different numbers for the same metric. This is a calculation problem.
You cannot answer questions that depend on how things relate, across many sources, with rules. This is the only one that may need an ontology.

Three of the four have a cheaper fix.

Rung one: a glossary

A glossary is a short document. Each term has one definition, one owner, and one place it is stored. "Customer" means a paying account, or a signed-up user, or a billing entity. Pick one meaning per context and write it down.

A glossary fixes the case where the data is fine and the words are not. It needs no new system. If people will not agree on a definition in a meeting, a model will not make them agree. It will only hide the argument inside a file.

A glossary is enough when:

the terms are few and stable,
the same people read and write the data,
nobody needs a machine to act on the meaning.

Rung two: shared identifiers

If a customer has one ID in billing and another in the product database, no model will help until they are linked. Give each real-world thing one key. Keep a mapping table from every source key to that one key. Own the table.

This is dull work, and it fixes more problems than any vocabulary. Most "we need a knowledge graph" conversations I see are really "we cannot join these two tables." Shared identifiers answer that.

Shared identifiers are enough when the trouble is joining, counting or deduplicating, and the meaning of each field is already agreed.

Rung three: a metrics layer

When the same metric gives different answers, write the calculation once and let every report read it. Revenue, active user, churn: each gets one definition, in code, under version control. A metrics layer is a semantic layer in the narrow sense. It fixes how numbers are computed, not what things are.

It is enough when your pain is in the dashboards and the disagreement is about arithmetic: which rows count, which date applies, which currency.

When an ontology earns its cost

An ontology models the things in your business and the relationships between them, with rules a machine can use. A "supplier" can be a "subsidiary" of a "parent company"; a product can be "part of" another; some relationships imply others. That is richer than a glossary, and it costs more to build and keep.

I would consider one only when all of these hold:

Many sources describe the same things in different ways, and you cannot force one schema on them.
Relationships carry the value. The questions you ask depend on how things connect, not on single fields.
You need rules or inference that people or software will act on, such as automated checks or an AI workflow that must reason across sources.
Someone will own it. A model nobody updates is wrong within months, and a wrong model is worse than none.

If you cannot tick all four, stay on the lower rungs. If you tick them, start small: model one area, prove it answers one real question, then decide whether to extend it.

The AI angle

People now ask about ontologies because AI pilots stall on messy data. That is a fair worry. But the first fix is still the plain one. An AI workflow that reads "customer" in three senses will give three kinds of wrong answer. A glossary and clean identifiers cut most of that. Richer semantics help later, once the basics hold.

This matters most when a human must approve each consequential action. The reviewer needs to trust what the workflow shows them. Clear definitions and one key per entity make that review quick. A large model that nobody checks does not.

A simple test

Ask these in order. Stop at the first yes.

Do people mean different things by the same word? Write a glossary.
Do records fail to join? Build shared identifiers.
Do metrics disagree? Build a metrics layer.
Do you still have a real question that needs rules across relationships? Now look at an ontology, and scope it to that one question.

Most teams stop at step one or two.

Who should not hire me for this

If you want a full enterprise ontology programme, I am not the right person. I work alone, and I build lean data platforms and approval-gated AI workflows. If you already know you need a large semantic model and a team to run it, hire a group that does that.

If you are not sure where your problem sits, you can check your data platform yourself first. The Data Platform Teardown is free and needs no sign-up. If the answers point to a deeper problem, a $3,000 audit is the next step. A call is never the first step.