Built with Tutify.io

    AIStudyLabs

    Ontology vs Taxonomy vs Knowledge Graph: Key Differences

    Ontology vs Taxonomy vs Knowledge Graph: Key Differences

    Ask three data architects to explain ontology vs taxonomy and you may get three answers, plus a fourth about knowledge graphs. Product material often uses the terms loosely, which doesn't help. The terms do have precise meanings, and the differences matter when you decide how much modelling effort a project deserves.

    This article sorts them out. It is part of the series that starts with ontology in data and AI, which covers why shared meaning matters in the first place. Here the focus is narrower: what each structure holds, how they build on each other, and how to pick the lightest one that solves your problem.

    The short answer

    All five organize information about meaning, with increasing formality: four describe it, and the fifth holds data that follows it.

    | Structure | Holds | Machine can | Typical format | |---|---|---|---| | Controlled vocabulary | A fixed list of approved terms | Check a value is allowed | Enum, lookup table | | Taxonomy | Terms in a broader/narrower hierarchy | Roll up and drill down | SKOS | | Thesaurus | Hierarchy plus synonyms and related terms | Match synonyms, suggest related terms | SKOS | | Ontology | Classes, properties, individuals and logical axioms | Infer new facts, detect contradictions | RDFS, OWL 2 | | Knowledge graph | Entities and their relationships as data | Traverse and query connected facts | RDF, property graphs |

    The first four are ways of describing meaning. The knowledge graph is the data itself. That split is the one people miss most often, and it is the key to the whole comparison.

    Controlled vocabulary: agreeing on the words

    A controlled vocabulary is a list of terms everyone agrees to use, each with one meaning. The status column that may only hold open, pending or closed is one. So is an ISO country code list.

    It solves the simplest version of the meaning problem: two systems spelling the same thing differently. It has no structure. A controlled vocabulary can tell you that smartphone is a valid product type, but not that a smartphone is a kind of phone.

    Use one when you need consistent values in a field and nothing else. It costs almost nothing to maintain, and most data teams already have dozens of them hiding in lookup tables.

    Taxonomy: adding a hierarchy

    A taxonomy arranges controlled terms into a tree of broader and narrower concepts:

    That single relation gives you a lot. Sales can be rolled up from Smartphones to Phones to Electronics. A search for Phones can include everything below it. Product managers can browse the tree. Most e-commerce category menus, document filing schemes and support ticket categories are taxonomies.

    The weakness is that a taxonomy only knows one kind of link. It can't say that a smartphone runs an operating system, or that a laptop is sold with a charger. Teams that need those links often start bolting extra meaning onto the hierarchy, putting "Accessories for Smartphones" as a child of Smartphones. Now the tree mixes "is a kind of" with "goes with", and every roll-up report is wrong. That is a common mistake in taxonomy design, and the sign you have outgrown one.

    Thesaurus: synonyms and related terms

    A thesaurus is a taxonomy plus two more relations: equivalence (synonyms) and association (related terms). "Cell phone" and "mobile phone" point to the same concept. "Smartphone" is related to "mobile app" without being its parent or child.

    The W3C standard for taxonomies and thesauri is SKOS, a Recommendation since 2009. In SKOS each concept gets one preferred label per language, plus any number of alternative and hidden labels, and links to other concepts with skos:broader, skos:narrower and skos:related.

    @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix shop: <https://example.org/shop#> .

shop:smartphones a skos:Concept ;
    skos:prefLabel "Smartphones"@en ;
    skos:altLabel  "Mobile phones"@en, "Cell phones"@en ;
    skos:broader   shop:phones ;
    skos:related   shop:mobileApps .

    Two details catch people out. First, skos:broader is not transitive by itself; SKOS provides skos:broaderTransitive for that. Second, the SKOS Reference states plainly that SKOS is not a formal knowledge representation language. Its relations are facts about the vocabulary, not logical claims about the world. Saying Smartphones is narrower than Phones does not let a reasoner conclude that every smartphone is a phone.

    Ontology vs taxonomy: what the extra formality buys

    In the ontology vs taxonomy comparison, the key difference is that an ontology models the domain itself, not just the words for it. It has:

    The same product domain in OWL looks like this:

    @prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix shop: <https://example.org/shop#> .

shop:Phone a owl:Class .
shop:Laptop a owl:Class ;
    owl:disjointWith shop:Phone .

shop:Smartphone a owl:Class ;
    rdfs:subClassOf shop:Phone .

shop:runsOS a owl:ObjectProperty ;
    rdfs:domain shop:Smartphone ;
    rdfs:range  shop:OperatingSystem .

    With that, software can do things a taxonomy can't. If a record says a device runs Android, a reasoner infers it is a smartphone, and therefore a phone. If someone tags the same item as a laptop, the disjointness axiom flags a contradiction. Notice where the first inference comes from: rdfs:domain. Because the domain of runsOS is Smartphone, any laptop recorded with an operating system would also be inferred to be a smartphone, and the reasoner would report every such laptop as inconsistent. Domain declarations infer types rather than check them, so a property shared by phones and laptops needs a broader domain, such as Device. The languages that make this possible, and their limits, are explained in RDF, RDFS, OWL and SHACL compared.

    Ontology and taxonomy side by side

    | Question | Taxonomy | Ontology | |---|---|---| | Relations available | Broader, narrower (plus related in a thesaurus) | Any property you define | | Meaning of the hierarchy | Loose: "file under" | Strict: every member of the subclass is a member of the parent | | Rules and constraints | None | Cardinality, disjointness, equivalence, inverses | | Can infer new facts | No | Yes, with a reasoner | | Typical effort (rough guide) | Days to weeks | Weeks to months for a real domain | | Who maintains it | Librarians, content teams, product managers | Data modellers with domain experts |

    In practice the ontology vs taxonomy choice is rarely either-or. Many ontologies contain a taxonomy as their class hierarchy, and many organizations keep a SKOS taxonomy for navigation and link its concepts to ontology classes for reasoning.

    Knowledge graph: the data, not the model

    A knowledge graph is a set of entities and the relationships between them, stored as a graph. In RDF it is literally a set of triples: subject, predicate, object.

    @prefix shop: <https://example.org/shop#> .

shop:pixel9 a shop:Smartphone ;
    shop:manufacturedBy shop:google ;
    shop:runsOS shop:android .

    The classes and properties in that snippet, Smartphone, manufacturedBy, runsOS, come from the ontology. The facts come from your data. That is the relationship in one sentence: the ontology is the schema, and the knowledge graph is the instance data that follows it.

    Large public examples make the scale clear. Wikidata holds well over 100 million items. The DBpedia ontology that types much of DBpedia's data has 768 classes and about 3,000 properties. A model of a few hundred classes types a graph many times its own size.

    A knowledge graph can exist without a formal ontology. Many property-graph databases hold labelled nodes and edges with no shared definitions behind the labels. That works inside one team. It breaks when a second team adds Company nodes next to your Organization nodes, and nobody can say whether they are the same thing. The value of putting an ontology underneath is consistency across sources, which is the subject of ontology-based data integration.

    How the pieces fit together

    In a mature setup you will often find all of them working at once:

    1. A controlled vocabulary keeps field values clean at the source.
    2. A taxonomy or SKOS thesaurus drives navigation, search facets and tagging.
    3. An ontology defines the classes, properties and rules shared across systems.
    4. A knowledge graph holds the connected facts, typed by the ontology.
    5. Applications, analytics and AI systems query the graph.

    LLM systems sit at the top of that stack. When a GraphRAG pipeline extracts entities from documents, the ontology decides which entity types and relationships are allowed, so the resulting graph stays consistent. That pattern is covered in knowledge graph retrieval with an ontology, and the wider role of a domain model in grounding model output is in ontologies and LLMs.

    Is a knowledge graph the same as an ontology?

    No, although the two are often sold as one product. The confusion comes from the fact that both can be stored as RDF triples in the same database. A triple that says shop:Smartphone rdfs:subClassOf shop:Phone is part of the model. A triple that says shop:pixel9 shop:runsOS shop:android is part of the data. They sit side by side, and a SPARQL query can read both in one pass.

    The practical test is change rate. The model changes when the business changes its mind about what things are, which happens far less often than the data changes. The data changes every time a product ships, a customer signs up or a ticket is closed. If you find yourself editing class definitions every day, you are probably storing facts as classes, a common modelling slip. If the graph keeps sprouting new edge labels nobody agreed on, it is missing an ontology.

    Taxonomy or ontology: a worked example

    Consider a support team that tags tickets. They start with a controlled vocabulary of twelve tags, billing, login, export and so on. After a year there are 140 tags and agents pick inconsistently, so they organize them into a taxonomy: Account > Login > Password reset, Account > Billing > Refunds. Reporting improves at once, because "all Account tickets" is now a single roll-up.

    Then product management asks a different question: which tickets involve a feature that was released in the last 30 days, for customers on the enterprise plan? The taxonomy can't answer it. It knows that Password reset sits under Login. It does not know which product feature a ticket concerns, which release shipped that feature, or what plan the customer is on. Those are relationships between different kinds of things: tickets, features, releases, customers, plans.

    That question is the signal to model an ontology. You define classes for Ticket, Feature, Release, Customer and Plan, properties such as concernsFeature, shippedIn and subscribedTo, and keep the tag taxonomy as a SKOS scheme linked to tickets. The taxonomy keeps doing what it is good at, which is navigation and roll-ups. The ontology handles the questions that cross entity types. Neither replaces the other.

    The cost difference is real. The taxonomy might take a team a couple of afternoons. The ontology needs agreement from support, product and billing on what a feature and a release are, which is mostly a conversation, not a coding task. Budget for those meetings; they are where the value comes from.

    Which one do you need?

    Pick the lightest structure that answers the questions you actually have:

    The ontology vs taxonomy decision comes down to one test. If you only ever need "file this under that", stay with a taxonomy. If you need software to know what a thing is, what it can relate to and what can't be true at the same time, you need an ontology.

    Common mistakes to avoid

    Getting hands-on

    Building a tiny version of each makes the difference concrete. Ten SKOS concepts for a product menu take minutes and give you navigation. The same domain modelled with OWL classes, a few properties and some instance data lets you query and infer. The walkthrough in how to build an ontology in Python with RDFLib covers the second half: classes and properties in code, instance data, SPARQL queries, RDFS inference and SHACL validation.

    Key takeaways

    Related articles in this series