Ontology vs. Taxonomy vs. Knowledge Graph

What is the difference between an ontology, a taxonomy and a knowledge graph?

Three sentences, before any elaboration.

A taxonomy arranges things in a hierarchy of broader and narrower terms. An ontology says what things are, how they relate, and what must hold true of those relationships, which lets a system infer facts nobody wrote down. A knowledge graph is the populated thing: instance data held together by an organizing principle, and an ontology is one type of organizing principle.

Anyone comparing ontology vs taxonomy is usually deciding which to build. They are layers, so the useful question is which comes first.

What a taxonomy does, and where it stops

A taxonomy puts terms in order. Product categories, a subject hierarchy, a chart of accounts. It answers what is this a kind of, and that single relationship is the whole of its expressive power.

That is not a weakness. Most organizations need a good taxonomy more urgently than anything cleverer, and a clean one solves real problems in search and reporting. TopQuadrant has a deeper reference on how controlled vocabularies, taxonomies and thesauri relate.

Where it stops is anything that is not a hierarchy. A taxonomy cannot say that an order must have exactly one billing account. It cannot say that a clinical site and a trial centre are the same thing under two names. It cannot say that anyone supervising a regulated process must hold a current certification. Those are constraints and equivalences. Parent-child links do not express them.

What an ontology adds

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 two questions. What are the organization's core things, and how do they relate? Every person, system and agent then resolves those questions the same way.

Two misreadings are worth heading off here, because this is where both usually happen.

An ontology is no tidier way to draw a data model. A data model describes how data is structured inside one system. An ontology describes what that data means across the business. That is why two warehouses can each be internally correct and still disagree.

Nor is an ontology a graph database feature. The graph is somewhere to put it. The agreement exists whether or not anybody has chosen a store, and it survives changing stores, which is most of the point.

The word carries other senses. Philosophy has its branch of metaphysics. Biology has the Gene Ontology. Some analytics platforms call the object layer of their own workspace an ontology. What an ontology is sorts those out properly.

What a knowledge graph is

A knowledge graph is where the instances live. Customer as a concept belongs to the ontology. The four million actual customers belong to the graph, connected to actual orders and actual accounts.

So the graph holds the facts, the ontology states what those facts are allowed to mean, and the taxonomy is often the first organizing principle a graph gets. For a while it is enough.

The row that matters is the second to last. A taxonomy and a graph both describe. Only the ontology records what the organization decided, which is why it is the layer that needs ontology management.

Do you need an ontology to build a knowledge graph?

No, and a page claiming otherwise would be selling something. Plenty of knowledge graphs start with a simple type system and add formal semantics only when they have to.

The honest part is naming when that stops being fine, and either of two conditions is enough. The first is two teams needing the same word to mean the same thing. That is the point where informal agreement starts producing two correct answers to one question. The second is an agent acting on an answer without a person checking it. An inferred structure can tell you how data is currently used. It cannot tell you what anyone agreed that data means. Whether you actually need one deserves more than a clause here.

What each layer has to stay connected to

• The taxonomy to the ontology, so a term in the hierarchy resolves to a typed concept.
• The ontology to the data, through constraints that can be validated, which is what SHACL is for.
• The graph to the ontology, so instance data is checkable against what the business agreed, and not only against its own shape.
• All three to the systems that consume them, at query time, or the agreement stays a document.

Those connections are the part that breaks silently. A taxonomy that has drifted from the model, or a graph validated against nothing, still looks healthy from the outside. This is why the three are worth treating as one governed asset in open standards. RDF, OWL, SKOS and SHACL are readable by tools that have nothing else in common. The connections then survive any one product being replaced. That is the work TopQuadrant's platform is built around.

Common questions

What are the four types of ontology? The classical split is by scope. Upper ontologies cover concepts general enough for any domain. Domain ontologies cover one field. Task ontologies cover an activity. Application ontologies serve one system. Organizations build domain and application ontologies almost without exception.

What are the four types of taxonomy? There are four. Flat is one list with no levels. Hierarchical is strict parent-child. Network lets a term be reached by more than one path. Faceted classifies one item along several dimensions at once, such as size, colour, and material. The further down that list you go, the closer you are to wanting an ontology.

What is the difference between a skills ontology and a skills taxonomy? A skills taxonomy lists skills in a hierarchy, so Python sits under Programming. A skills ontology records more. Python is evidence of software engineering capability. A certification expires. One role requires a skill that another merely prefers. That lets a system reason about who can do a job, instead of matching keywords.

Can you provide an example of a taxonomy and an ontology? A product taxonomy says road bike is a kind of bicycle, which is a kind of vehicle. A product ontology adds that every bicycle has exactly one frame size, and that a discontinued product may still have open warranty claims. The taxonomy helps someone browse; the ontology stops two systems disagreeing about what is in stock.

Keeping any of this true as the business changes is a separate discipline, and it is what ontology management covers.

So what should I take away?

Taxonomies arrange my terms. Knowledge graphs hold my instances. Neither can say what must be true. Without an ontology constraining it, my graph will store two customers that are the same company and serve both to an agent with equal confidence.

So treat the three as one asset. Three separate projects is how the connections rot. The ontology is the layer that makes the other two answerable to something, and TopQuadrant builds exactly that: the agreed model, in open standards, with the rules that let a graph be checked against it.