Taxonomy, ontology, knowledge graph
Three words, often used interchangeably, that build on each other:
- Taxonomy, what kinds of things exist, arranged in a tree. A Pump is a kind of Rotating Equipment.
- Ontology, taxonomy plus relationships and rules. A Pump can be part of a Line, and is monitored by Instruments.
- Knowledge graph, the ontology filled with your actual assets. Pump P-101 is part of Line 3 and monitored by 21-PT-1234.
You need all three, and in that order. Add live data on top and the result gains a fourth name: a digital twin.
The library analogy, continued
Return to the library from What is DataHub?.
The taxonomy is the subject classification scheme, the rule that says works are sorted into Science, and within Science into Physics, and within Physics into Optics. It is a tree. Every subject has exactly one parent. It tells you what kinds of things a library can hold.
The ontology is everything the catalogue knows beyond classification: that a work has an author, that an author can have written several works, that a work can cite another work, that a translation is derived from an original. These are relationships, and they are not tree-shaped, a single work connects outward in many directions.
The knowledge graph is the catalogue once every actual book is in it. Not "a work has an author" but "Kristin Lavransdatter was written by Sigrid Undset". Real things, real connections, queryable.
Side by side
| Taxonomy | Ontology | Knowledge graph | |
|---|---|---|---|
| Answers | What kinds of things exist? | How can things relate? | What is actually out there? |
| Shape | A tree, one parent each | A network of typed relations | A network filled with real instances |
| Contains | Classes | Classes + relationship types + rules | Instances + their real relationships |
| Example | Pump is a kind of RotatingEquipment | A Pump may be partOf a Line | P-101 is partOf Line3 |
| In DataHub | Your labels | Labels + relationship types | Your resources and their relationships |
| Changes | Rarely | Occasionally | Constantly |
What each layer buys you
Taxonomy: asking about many things at once
Without classification, every question is about one named item. With it, you can ask about whole populations:
- "Show me every Pump on this site."
- "Which Instruments have not reported in 24 hours?"
- "Compare energy per tonne across all Compressors of this class."
That leap, from "tell me about P-101" to "tell me about every pump", is what a taxonomy delivers, and it is why every resource in DataHub must have at least one label. In the console, labels also colour the nodes in the graph, which is what keeps a model with thousands of nodes visually readable.
In DataHub: labels are your taxonomy. Create them deliberately, in the singular, with
spaces between words: Pump, Separator, Site, Pressure Transmitter. Names are stored
upper-cased with underscores, so that last one becomes PRESSURE_TRANSMITTER.
Three or four levels is almost always enough. Deep hierarchies feel rigorous and turn out to be unusable, because nobody can remember which of the four near-identical leaf classes a given item belongs to.
Ontology: making the relationships legal and meaningful
A taxonomy tells you a Pump exists as a kind. It does not tell you a Pump can be part of a Line, or that an Instrument monitors equipment rather than the other way round. Those are relationship types, and naming them is the step that turns a classification scheme into a model of how your operation is put together.
This is also where rules live. In DataHub, one rule is enforced structurally: a resource carries at most one type label, chosen at creation, encoding what it fundamentally is, while other labels can be added and changed freely. That keeps the classification unambiguous, an item cannot quietly be both a Pump and a Vessel, while still letting you tag things for other purposes.
In DataHub: relationship types are the names you choose when you connect two resources. Choose a small vocabulary and use it consistently. Five well-used relationships beat forty used once each. Naming relationships →
Knowledge graph: answering questions by walking
The first two layers are definitions. The knowledge graph is the populated result, and it is what you actually query. Its distinguishing feature is that questions are answered by following relationships rather than by joining tables.
Knowledge graphs in detail → · And what it becomes with live data →
Which one am I building right now?
A quick way to locate yourself:
| If you are... | You are working on... |
|---|---|
| Deciding whether "Valve" and "ControlValve" should be separate classes | Taxonomy |
| Deciding whether the link is called feeds or supplies | Ontology |
| Adding P-101, P-102 and P-103 and connecting them to Line 3 | Knowledge graph |
| Importing 4,000 tags from a historian | Knowledge graph (and finding out whether your taxonomy holds up) |
The first two are decisions made by a handful of people in a room, once, and revisited rarely. The third is continuous, mostly automated, and often high volume. Getting the first two roughly right is what keeps the third from becoming a mess.
A common mistake
Teams frequently try to build a complete taxonomy before touching real data. It feels responsible, and it produces a model that is beautifully organised and subtly wrong, because the flaws in a classification scheme only become visible when real items refuse to fit.
The better order:
Enough to cover the area your first question touches. Do not try to cover the whole company.
A few hundred, from a source you trust. This is where you find out that "Valve" needed splitting, or that two classes were really the same one.
Expect to change it. Changing it now is cheap; changing it after 40,000 items are classified is not.
Import at volume once the classes have survived contact with real data.
- What is an ontology?: the model layer explained from scratch
- Knowledge graphs: traversal, and the questions it makes cheap
- The three layers: assets, functions, business knowledge
- Naming and standards: conventions for labels and relationships
- Working with the resource graph: where all of this lives in the console