Taxonomy vs Thesaurus vs Ontology vs Knowledge Graph
“Do we need a taxonomy, an ontology, or a knowledge graph?” is the question that stalls more semantic projects than any technical obstacle. The four terms get used interchangeably in vendor decks and job adverts, yet they name genuinely different artifacts with different costs, different tooling and different failure modes. This lesson gives you clean definitions, the standards behind each artifact, and a decision aid you can put in front of a steering committee. Get this lesson right and you will save your organisation from the two classic wastes: building a full OWL ontology where a controlled vocabulary would do, and shipping a schemaless graph that collapses the moment anyone asks it a precise question.
The four artifacts, defined properly
A controlled vocabulary is the simplest member of the family: an agreed list of terms for a domain, with one preferred label per concept. Its job is consistency of naming, nothing more.
A taxonomy adds hierarchy. Concepts are arranged in broader and narrower relationships, typically a tree: Beverages, then Coffee under it, then Espresso under that. The governing standard in the English-speaking world is ANSI/NISO Z39.19, which specifies how to construct controlled vocabularies, and internationally ISO 25964 covers thesauri and their interoperability. A taxonomy answers one question well: where does this thing file? It deliberately says nothing about how things interact.
A thesaurus is a taxonomy with two additions: equivalence relationships (synonyms and preferred versus non-preferred terms, so “heart attack” and “myocardial infarction” resolve to one concept) and associative relationships (the deliberately loose “related term” link connecting, say, Coffee and Caffeine). On the web, the standard carrier for taxonomies and thesauri is SKOS, the W3C Simple Knowledge Organization System. SKOS gives you skos:broader, skos:narrower, skos:related, skos:prefLabel and skos:altLabel, and crucially its semantics are intentionally weak: skos:broader carries no logical entailment beyond what it says. That weakness is a feature. It lets librarians and information architects publish useful structures without committing to formal logic.
An ontology crosses the line into logic. Instead of terms arranged for navigation, you have classes, properties and axioms with formal, machine-interpretable semantics, usually expressed in OWL. A taxonomy can say Espresso is narrower than Coffee. An ontology can say every Espresso is a Coffee, that Coffee is a Beverage made from an ingredient that is a CoffeeBean, that hasIngredient is transitive across mixtures, and that nothing can be both a Beverage and a Utensil. Those axioms are not documentation; a reasoner uses them to derive facts you never stated and to detect contradictions in your data. This is where the genus-and-differentia definitions from lesson 1 become executable.
A knowledge graph is a different kind of thing from all three: it is data, not just schema. A knowledge graph is a large set of assertions about individual entities: this specific customer placed this specific order on 14 March 2026; pump P-101 is installed at site Aberdeen-2. The ontology (or a lighter schema) supplies the semantic layer that says what those assertions mean; the graph is the mass of instance-level facts underneath it. Google popularised the term in 2012, and today the label covers both RDF graphs governed by ontologies and property graphs in engines such as Neo4j.
The questions everyone asks, answered head-on
What is the difference between an ontology and a knowledge graph? The ontology is the schema-with-semantics; the knowledge graph is the populated data governed by it. An ontology might define 60 classes and 80 properties in a few thousand axioms. The knowledge graph built on it might contain two billion assertions about individual people, products and events. You maintain them on different lifecycles: the ontology changes by governed release, the graph changes continuously. A useful test: if deleting all instance data would leave your artifact intact, you are looking at the ontology; if deleting the schema would leave a pile of edges nobody can interpret, the rest was the graph.
What is the difference between a taxonomy and an ontology, and where does a data model end and an ontology begin? A taxonomy has one working relationship (broader/narrower) and no logic; an ontology has arbitrary, formally defined relationships and axioms a reasoner can act on. The boundary with data models is subtler, because an entity-relationship diagram also has classes and relationships. The differences are purpose and semantics. A database schema is scoped to one application, optimised for storage and retrieval, and its meaning lives in developers’ heads and documentation. An ontology is scoped to a shared domain, optimised for unambiguous meaning across systems, and its meaning lives in the axioms themselves under an open-world logic (lesson 4). When your “data model” starts being reused by systems that were never in the original design, carries textual definitions with genus and differentia, and needs to say things like “every X must relate to some Y” as a matter of meaning rather than storage, you have crossed into ontology territory whether you used the word or not.
Do I need an ontology at all to build a knowledge graph, or can I just extract triples with an LLM? You can absolutely build a graph without one; the 2024 wave of GraphRAG tooling did exactly that, extracting entity-relation soup from documents with no schema. The honest answer from the 2025-2026 evidence is that schema came back fast. The systems now winning benchmarks (KAG, OG-RAG, Youtu-GraphRAG, AutoSchemaKG) all reintroduce a schema, whether authored by humans, induced automatically, or anchored to a curated ontology, because schemaless entity soup cannot support aggregation, deduplication or precise multi-hop queries. Microsoft’s own ontology-grounded OG-RAG measured 55% higher fact recall than standard RAG. The practical rule: for a throwaway demo, extract freely; for anything that must answer precise questions repeatably, put at least a lightweight ontology under it. Module 6 treats this in depth.
Worked example · the Aberdeen-2 asset register
Where we left it: a question (“how many pumps?”), three sources that disagree for principled reasons, and nothing explicit yet.
Express the same fragment of the pump domain as each of the four artifacts and the differences stop being abstract:
# taxonomy: files things
ex:CentrifugalPump skos:broader ex:Pump .
# thesaurus: reconciles vocabulary
ex:CentrifugalPump skos:altLabel "pumping unit"@en .
# ontology: commits to meaning
ex:CentrifugalPump rdfs:subClassOf ex:Pump .
ex:Pump owl:disjointWith ex:Pipeline .
# knowledge graph: asserts facts about particulars
ex:P101 a ex:CentrifugalPump ;
ex:installedAt ex:Aberdeen2 .Each layer earns its keep against a specific Aberdeen-2 problem. The thesaurus line is what lets the contractor spreadsheet’s “pumping unit” rows join the count at all. The ontology lines are what make “how many pumps” computable: they state what counts as a pump and what cannot be one. And the instance triples are the register itself, the mass of facts the other layers give meaning to. The artifacts nest, exactly as the decision table says: the register will carry all of them in one store.
State of the register: decided. A knowledge graph governed by an ontology, with a SKOS layer to absorb the messy source vocabularies. Next problem: what happens to the graph when the physical world changes underneath it.
What breaks · filing P-101 into the taxonomy
A reasonable-sounding shortcut: the taxonomy already has Pump and CentrifugalPump, so add each physical unit one level down and keep everything in one tidy tree:
ex:P101 skos:broader ex:CentrifugalPump . # unit filed as a narrower TERMThis puts a particular where only universals belong, and every SKOS-aware tool takes the modelling at its word. Concept counts now inflate by one for every unit installed, so the vocabulary report claims hundreds of “kinds” of pump. Faceted navigation offers P-101 as a filing category with nothing filed under it. And when P-101 is scrapped, vocabulary governance says concepts are deprecated rather than deleted, so the dead pump haunts the taxonomy indefinitely. This is lesson 1’s universals versus particulars error again, wearing SKOS syntax: hierarchy notation cannot express “is an instance of”, and skos:broader silently records the wrong claim instead of failing.
The decision aid
| Your dominant requirement | Right artifact | Governing standard or carrier | Typical build effort |
|---|---|---|---|
| Consistent naming and tagging of content | Controlled vocabulary | ANSI/NISO Z39.19, published as SKOS | Days to weeks |
| Navigation, faceted search, filing hierarchy | Taxonomy | ANSI/NISO Z39.19, SKOS | Weeks |
| Search recall across synonyms; editorial cross-references | Thesaurus | ISO 25964, SKOS | Weeks to months |
| Shared meaning across systems; inference; consistency checking | Ontology | OWL 2 (W3C), often with SHACL for validation | Months, then governed releases |
| Answering questions over large volumes of connected instance data | Knowledge graph | RDF store or property graph engine, governed by one of the above | Ongoing pipeline, not a project |
Read the table bottom-up when planning budgets: a knowledge graph project nearly always contains at least a taxonomy, and the strongest ones contain an ontology. The artifacts nest rather than compete. SKOS itself is defined in OWL; a well-run enterprise graph will often carry a SKOS taxonomy for content tagging, an OWL ontology for core business semantics, and billions of instance triples, all in one store.
Failure modes on both ends
Over-engineering is the classic consultancy failure: eighteen months of OWL axioms modelling the metaphysics of “agreement” while the business needed faceted product search that a three-week SKOS taxonomy would have delivered. Signs you are over-engineering: nobody can name the query that any given axiom enables; the reasoner has nothing to detect because no data ever loads; stakeholders review class hierarchies instead of competency questions. Lesson 18 gives you competency questions precisely to prevent this.
Under-engineering is the newer, LLM-flavoured failure: a schemaless extracted graph that demos beautifully and then cannot answer “how many distinct suppliers do we have in Germany?” because “Siemens”, “Siemens AG” and “SIEMENS” are three nodes and nothing defines what a supplier is. Deduplication, aggregation and compliance queries all require identity criteria and typed relationships, which is to say, an ontology, even a small one. The teams that recover fastest are those that treat the extracted graph as a draft and retrofit a governed semantic layer, validating with SHACL (lesson 11).
Check yourself
The Aberdeen-2 audit turns up four information assets. Which one is the knowledge graph?
- A 9,000-record dataset with typed links between individual units, sites and work orders.
- A tree of 60 equipment categories used to file inspection documents, with no definitions.
- A 300-term list mapping contractor phrases such as “pumping unit” to preferred labels, with related-term links.
- A 45-class OWL file declaring disjointness and cardinality rules, containing no instance data.
Show the answer, and why each wrong option is wrong
A is correct. Typed assertions about individual entities at scale is precisely what a knowledge graph is: data, not schema. Apply the lesson’s deletion test: remove the schema and A degrades into uninterpretable edges, which tells you A was the graph.
B trades on “it has a hierarchy and hierarchies are graphs”. Shape is not the criterion; B organises terms for humans and contains no assertions about any individual thing, so it is a taxonomy. C trades on “it links things together”. The links are between words, not entities; equivalence plus related-term structure is a thesaurus. D is the strongest distractor because it lives in a triplestore and uses the most sophisticated formalism in the list. But delete all instance data everywhere and D survives untouched: it is pure semantic layer, the ontology. Calling the OWL file “our knowledge graph” is the exact confusion this lesson exists to kill.
What to take forward
Keep four sentences within reach. A taxonomy organises terms for humans. A thesaurus adds synonymy and association for retrieval. An ontology defines meaning formally enough for machines to reason. A knowledge graph is the connected instance data those definitions govern. In interviews and steering meetings, the ability to make these distinctions crisply, and to argue for the cheapest artifact that meets the requirement, is itself a differentiating skill; the confusion in the wider market is your opportunity. If you want to drill the standards side further alongside this course, the semantic standards deep-dive course works through SKOS, OWL and SHACL with graded exercises.
Next we confront the question that separates casual modellers from serious ones, and that none of these definitions has yet answered: when the data changes, what stays the same? Identity, change and time, and the 3D versus 4D split that shapes entire national modelling programmes, are the subject of lesson 3.
