What Is an Ontology?
Key takeaways
- Every serious definition of an ontology agrees. They differ on what happens after the definition ends.
- An ontology has four components: classes, properties, relationships and rules. Rules are the part most explanations skip.
- Rules are written in SHACL, a W3C standard, which is what turns a description into something a machine can enforce.
- Ontology programmes fail on scope, not on difficulty. Start with one definition two teams already argue about.
Ask four vendors what an ontology is and you get four versions of the same sentence. Formal. Machine-readable. Concepts, relationships, a domain. The agreement is real and it is thirty years old. It also means the definition is not where the useful part is.
The useful part is what the definition leaves out. Who decided what went into the model, and what happens when they change their mind.
What is an ontology?
An ontology is a formal, machine-readable model of the things in a domain: their types, the properties they carry, and the relationships between them.
In an enterprise, an ontology is the agreed answer to what the organization's core things are and how they relate, so that every person, system and agent resolves the same question the same way.
Two words in that sentence carry the weight.
Agreed. A named person with the authority to decide has said this is what a customer means. The decision is written down. It has a date on it. Someone can be asked why. An AI can propose that definition and propose it well. It cannot agree to it on your behalf.
Machine-readable. The model is written in open standards: RDF, OWL, SKOS and SHACL. A validator, a reporting layer and an agent framework can all read the same file without being taught how.
Three other things share the word. Ontology in philosophy is the branch of metaphysics about what exists. The Gene Ontology is a biological annotation resource. And at least one major data platform uses "ontology" to mean a tenancy scope mapped to a workspace, which is a permissions container.
What are the components of an ontology?
Four, and the fourth is the one most explanations skip.
Classes. The kinds of thing the business deals in. Customer. Order. Counterparty. Clinical trial site.
Properties. What each class carries. An order has a value, a date, a currency.
Relationships. How classes connect. A customer places an order. A product belongs to a category. A subsidiary rolls up to a parent.
Rules. What has to hold for the data to be acceptable. Every order has exactly one customer. An account number is thirteen characters. A trade with no counterparty is invalid.
Rules are where most ontology writing goes quiet, and they are the part that does the work. A class diagram describes. A rule refuses.
In practice rules are written in SHACL, a W3C standard for expressing constraints on a graph. SHACL turns "every order has exactly one customer" into something a machine checks on every record, and it reports which records failed and why. TopQuadrant's team helped author the SHACL specification, which is the reason this page treats rules as a component and not a footnote.
The mechanics are in validating an ontology with SHACL.
How is an ontology different from a data model?
A data model describes how data is structured inside one system. An ontology describes what the data means across the business.
Both are good engineering. The difference is scope and enforceability. Five properties mark the line.
- Authored. The meaning has a named owner. A schema has an owner for the table. An ontology has an owner for the definition.
- Rule-bearing. It carries constraints that get checked, as well as terms that get looked up.
- Standards-based. It is written in open W3C standards, so it moves between platforms and outlives the product it was built in.
- Versioned. Changes are proposed, reviewed, approved and recorded, and what the change replaced stays visible.
- Executable. Data and agent output can be validated against it. That is the difference between a model you consult and one that can reject a wrong answer.
A dimensional model can be stretched to imitate any one of these. Carrying all five, in a form another system reads unaided, is what it cannot do. The long version is in ontology vs data model.
Ontology, taxonomy, knowledge graph, semantic layer: what is the difference?
These get used as synonyms in sales conversations. They are four different artifacts and they answer four different questions.
| Artifact | What it holds | The question it answers | Carries enforceable rules |
|---|---|---|---|
| Taxonomy | A hierarchy of terms | Where does this category sit under that one | No |
| Ontology | Classes, properties, relationships, rules | What is true about these things, and who agreed it | Yes, in SHACL |
| Knowledge graph | Actual instances and their links | Which specific things exist and how are they connected | Only if an ontology governs it |
| Semantic layer | Dimensions, measures, joins | How is this number calculated | No |
The cleanest way to hold it: an ontology is the schema of meaning, a knowledge graph is the data that fills it, a taxonomy is one kind of relationship inside it, and a semantic layer sits over the warehouse doing arithmetic. A fuller treatment is in ontology vs taxonomy vs knowledge graph.
What are the four types of ontology?
The literature names four, by scope.
- Upper. Concepts general enough to apply anywhere: object, event, process.
- Domain. One field. Finance, clinical trials, upstream oil and gas.
- Task. One activity. Diagnosis, scheduling, claims adjudication.
- Application. One system's particular needs. The narrowest, and usually the shortest-lived.
Organizations build domain and application ontologies almost without exception. The upper ontology is the trap. Decades of attempts to build one that is both computationally precise and broadly interoperable have failed or survived by becoming so general that each domain does the real work anyway.
Why does this matter for AI agents?
A language model infers meaning from what it is shown. Column names, query patterns, how a field has been used. That inference is often right and it is genuinely useful.
What it cannot produce is standing. Ask it who decided that a customer is a party with an active entitlement, and there is no answer, because nobody decided it. The model read the data and formed an impression.
A person who gets a wrong number from a dashboard argues with it. They know the quarter closed late, or that the regional rollup double-counts. An agent receives the number, treats it as true, and does the next thing. Judgement was the control and it has been taken out of the loop.
Here is the version that made this concrete for a practitioner in a public forum, and it fits in one question: is a helicopter an aircraft?
On 14 April 1994, two US Army Black Hawk helicopters were shot down over northern Iraq by US fighter aircraft during Operation Provide Comfort. Twenty-six people died. A pilot had asked whether there were friendly aircraft in the area. The answer he got was accurate inside the system that gave it, and it was lethal, because the two sides of that exchange did not share one answer to whether a helicopter counts as an aircraft.
Neither side held bad data. No data quality programme would have found it. They held different answers to a question nobody had settled, and that is the exact thing an ontology settles.
Where do ontologies show up in an enterprise?
Anywhere two systems have to mean the same thing by the same word.
| Where it shows up | What the ontology supplies | What it is worth |
|---|---|---|
| Data governance | Agreed definitions with owners and review trails | Disputes end with a citation |
| AI and agents | Resolvable meaning at query time, validated output | An agent can act on an answer instead of a plausible one |
| Regulatory reporting | Rules that travel with the data and can be checked | The number submitted traces to the definition that produced it |
| Onboarding and training | A readable map of what the business runs on | New staff read how the business works |
| Master and reference data | Identity across systems, so the same thing is one thing | Entity resolution stops being a per-project exercise |
| Application integration | Shared semantics between systems that share no schema | Integrations survive one side changing |
None of these is a modelling problem. They are all consequences of having somewhere authoritative to put a decision.
Aren't ontologies too hard to build?
The reputation is earned. Programmes that set out to model an entire enterprise before shipping anything have a near-total failure record, and practitioners say so more bluntly than any vendor would.
The diagnosis is right and the conclusion drawn from it is wrong. Those programmes died of scope.
- Start from an argument. One definition two teams already dispute gives you an edge to cut on. A domain gives you a swamp.
- Reuse before you build. Standards-based models already exist for most of what an enterprise needs. TopQuadrant maintains 300+ of them, including FIBO, SKOS and Schema.org, so an expert reviews recognisable concepts instead of notation.
- Let AI do the first pass. Machines propose definitions, relationships and rules well, and the volume of real decisions is far smaller than the volume of metadata. The agreement step is the one that cannot be delegated.
- Ship against one consumer. An agent or application actually using the model will tell you what is missing. Completeness will not.
The method is in how to scope an ontology so it actually ships.
Where to start
Name one definition two teams argued about this year. Give it an owner. Write down what it means, who agreed it and when. Add one rule in SHACL and run it against real data. Wire it into one system that asks the question.
One definition governed properly teaches an organization more about whether it can do this than a complete model nobody has signed.
Keeping it true after that is a separate discipline, and it is the one that decides whether any of this survives contact with a reorganisation. That is ontology management, and the platform side is TopQuadrant's ontology tooling.
