Structure vs. Concept

Why Taxonomies and Ontologies Are Not the Same Thing

---

---

Kurt Cagle & Chloe Shannon | The Ontologist

---

Heather Hedden, author of The Accidental Taxonomist and one of the clearer voices in the controlled vocabulary world, recently posed a question on her blog that turns out to be deceptively subtle: Is a taxonomy an ontology? The question came up at this year’s Knowledge Graph Conference, where she noted that many practitioners conflate the two — treating taxonomies as merely “simpler” ontologies, or assuming that synonyms and alternative labels belong to the ontological layer rather than the taxonomic one.

Heather’s answer is characteristically practical: taxonomies and ontologies are distinct in purpose, even if a taxonomy can be modelled as an instance of an upper ontology (because SKOS is itself defined in OWL). On the W3C semantic stack, she draws the line cleanly: taxonomy = SKOS, ontology = RDFS + OWL. That is a genuinely useful heuristic — clear, teachable, and grounded in the actual data models.

I largely agree. But I want to push deeper, because the distinction I draw is not purely a matter of which W3C specification you happen to be using. It is a distinction about what kind of knowledge you are trying to capture.

Structure Versus Concept

An ontology, in the sense I use the term professionally, is a structural and logical definition. It describes the shape of a domain: what classes exist, what properties those classes may bear, what constraints are in force, what inferential rules apply. When you write an OWL or RDFS schema — or, increasingly, a SHACL shape set — you are defining a kind of grammar for your data. The schema tells a machine (and a reasoner, and a validator) what counts as a well-formed assertion in your domain.

Notice what is conspicuously absent from that definition: it says almost nothing about what the concepts in your domain actually mean to the people using them. An ontology tells you that a character:Character may have a character:createdBy property pointing to a person:Person instance. It tells you nothing about what it means to be a character, what cultural roles fictional characters play, or how you would recognise one in the wild.

A taxonomy is doing something entirely different. It is a conceptual framework. SKOS makes this explicit: a skos:Concept is not a class or a type; it is a unit of thought. The machinery of SKOS — preferred labels, alternative labels, broader/narrower hierarchies, scope notes, editorial notes, related concepts — is machinery for capturing the way human minds organise ideas. It is similarity-space infrastructure. It is metadata that humans can curate and machines can navigate.

The asymmetry is real, and it matters.

Why Taxonomies Matter to Language Models

Here is where the conversation at the KGC probably did not go, and where my own thinking has shifted substantially over the past few years: a taxonomy is precisely the layer that an LLM can use.

A language model operates on a latent space — a high-dimensional geometry constructed by smearing billions of documents, conversations, books, and transcripts across a learned embedding. What that geometry encodes, fundamentally, is similarity. Words, phrases, and concepts cluster near one another when they co-occur in similar contexts, when writers reach for them in the same kinds of sentences, when readers associate them with the same kinds of situations.

This is why a well-constructed taxonomy is extraordinarily valuable in RAG (retrieval-augmented generation) architectures and in hybrid search. The preferred labels, alternative labels, scope notes, and editorial notes in a SKOS taxonomy are exactly the kind of similarity-laden text that helps a retrieval layer locate the right things. The structural properties of your OWL ontology — the axioms, the restrictions, the property chains — are largely invisible to a dense vector retrieval system, which has no intrinsic concept of logical entailment.

An ontology tells a reasoner what is true. A taxonomy tells a retrieval system what is near.

These are different services. Both matter. Neither substitutes for the other.

The Curation Argument

There is a second, more practical dimension to this separation that I have come to appreciate particularly in enterprise settings: humans can agree on concepts far more readily than they can agree on structure.

If you ask a business unit to formally characterise every entity in their domain — to specify the full set of valid properties, the cardinality constraints, the inverse relationships, the SHACL rules — you will be waiting a long time. Structural definition is painstaking work. It requires a depth of knowledge about internal architecture that goes beyond what most domain experts want to engage with, and it requires the kind of consensus that organisations are generally bad at.

Ask the same business unit to reach agreement on the canonical labels for the thirty most important concepts in their domain, add preferred and alternative terms, write a one-paragraph scope note for each, and indicate which concepts are broader or narrower — and you are describing a job that a skilled taxonomist can lead in a series of focused workshops. Domain experts are usually quite willing to argue about what a term means. They find structural definition tedious; conceptual negotiation, at least at the level of “what do we call this and what do we mean by it,” they will engage with.

This means that a taxonomy can be built, validated, and maintained by a much broader coalition of stakeholders than an ontology. It is the public-facing layer of the knowledge model: the part that information workers, curators, and end users can actually touch.

Separating the Layers in Practice

This is why I have increasingly adopted an explicit separation between the conceptual and structural layers in my own ontology work. Consider the following, using the extremely battered example of Batman:

concept:Batman a skos:Concept ;
    skos:inScheme conceptScheme:FictionalCharacters ;
    skos:prefLabel "Batman" ;
    skos:altLabel "The Dark Knight" ;
    skos:altLabel "Bruce Wayne" ;
    skos:description """The archetype of the trauma-driven vigilante: a hero
    motivated not by altruism but by wound. Visually coded in black and dark
    grey, drawing on the bat as simultaneous symbol of knighthood and moral
    ambiguity. One of the foundational figures in the superhero canon."""^^xsd:string ;
    skos:broader concept:Superhero ;
    skos:related concept:Vigilante ;
    .

character:Batman a class:Character ;
    entity:concept concept:Batman ;
    rdfs:label "Batman" ;
    character:createdBy person:BobKane, person:BillFinger ;
    character:firstAppearance publication:DetectiveComics27 ;
    character:publisher org:DCComics ;
    .

The first block is conceptual. It lives in a concept scheme alongside other fictional characters. It carries the kind of rich descriptive metadata that makes it discoverable — by a search system, by an LLM retrieval layer, by a human browsing the taxonomy. It can be maintained independently by someone with no knowledge of the structural schema.

The second block is structural. It describes the shape of the instance — what properties it has, what relationships it participates in. Multiple different ontologies, with different structural commitments, could all point to the same concept:Batman without polluting one another’s namespaces. A comics ontology and a film theory ontology and a cultural studies ontology might represent Batman’s structural relationships very differently — but they can all share the same conceptual anchor.

A reader familiar with SKOS might ask: why not simply use skos:exactMatch here? The answer is that skos:exactMatch is defined in the SKOS specification as a mapping property between two skos:Concept instances — it is a statement about conceptual equivalence, symmetric and bidirectional. Applying it to character:Batman would implicitly assert that a structural instance is a concept, which collapses the very separation the design is meant to enforce. It would also invert the epistemic direction. entity:concept originates on the structural side and points toward the conceptual layer: the structural entity knows about its conceptual grounding; the concept does not need to know about every structural entity that references it. That asymmetry is load-bearing. A comics ontology, a film theory ontology, and a cultural studies ontology can all independently bind to concept:Batman without any awareness of one another, and without the concept scheme acquiring structural entanglements it has no business carrying. The governance consequence is equally important: the concept scheme is maintained by one community (curators, domain experts, taxonomists), and the structural ontology by another (modellers, developers). The direction of the property enforces that separation at the data level. The concept layer remains sovereign.

This is not merely tidy. It reflects a genuine difference in epistemic status. The concept is relatively stable; Batman’s meaning in cultural discourse changes slowly. The structural representation is contingent on what you are trying to do with the data; it may vary substantially across applications.

Are You Confusing Structure and Concept?

When I am evaluating a new ontology — my own or someone else’s — I now apply a diagnostic question early in the process: are you confusing structure and concept?

The signs of confusion are recognisable. An ontology that carries long, prose-heavy rdfs:comment values on every class and property is probably doing taxonomic work in an ontological container. An ontology where the class hierarchy is doing double duty as a conceptual classification scheme — where the subclass relationships reflect editorial judgement about what things are “like” rather than formal subsumption — is probably conflating the two layers. An ontology where the same class is being asked to serve both as a structural type and as a search target is going to be difficult to maintain and difficult to query efficiently.

The solution is usually not to redesign the entire ontology. It is to recognise that you need two layers, and that building both — a structural schema and a SKOS concept scheme, linked via entity:concept or skos:exactMatch or whatever binding property suits your architecture — is less work than trying to make one artefact do both jobs.

Heather is right that maintaining the distinction has practical value. My argument is that the practical value traces to something real: the conceptual and structural layers are genuinely different kinds of knowledge, optimised for different consumers (humans, reasoners, retrieval systems), and they are most effectively maintained when they are allowed to evolve independently.

A taxonomy is not a simple ontology. It is an orthogonal one.

---

Kurt Cagle is a consulting ontologist, knowledge graph architect, and technical author. He publishes The Cagle Report and AI+Semantics NewsBytes on LinkedIn, and The Ontologist and Inference Engineer on Substack. Kurt Cagle is based in Olympia, Washington. He has an open coffee hour at https://calendly.com/thecaglereport, if you want to chat.

Chloe Shannon is an AI collaborator and co-author working with Kurt Cagle on The Ontologist and Inference Engineer. She can be reached at chloe@holongraph.com.