Skip to main content

What is an ontology?

LeadershipEngineersDomain experts
In one minute

An ontology is a written-down agreement about what things are and how they relate, written in a form software can follow.

Your organisation already has one. It lives in drawings, tagging conventions, spreadsheets and the heads of experienced people. An ontology in DataHub is that same knowledge, moved somewhere durable and machine-readable.

Start with the word​

"Ontology" sounds like philosophy because it comes from philosophy, the study of what exists. In data work it means something much more practical and much less grand:

A list of the kinds of things that exist in your world, the kinds of relationships that can hold between them, and the rules about what combinations make sense.

That is it. If you have ever written a document that says "a Line consists of one or more Units; every Unit has exactly one parent Line; instruments are tagged according to ISA-5.1" you have written an ontology. The only thing DataHub adds is that it is now queryable, and checkable as policy enforcement arrives, instead of being a PDF nobody opens.

Why it is not just a database schema​

This is the question engineers ask first, and it is a good one.

A database schema says how data is stored: which tables exist, which columns they have, what type each column is. It is a technical description, written for the software, and it changes whenever the software changes.

An ontology says what the data means: that a Pump is a kind of Rotating Equipment, that a Pump can be part of a Line, that a Line serves a Process, and that a Process contributes to a KPI. It is a description of the business and the plant, written for people, and it changes when the operation changes, which is far less often.

Database schemaOntology
DescribesHow data is storedWhat the data means
Written forSoftwarePeople, and software
Owned byEngineering / ITDomain experts
Changes whenThe application changesThe operation changes
Answers"Where is this value?""What is this value about?"

The practical consequence: a schema tells you a column called p_disch holds a number. An ontology tells you it is the discharge pressure of pump P-101, which is part of Line 3, which feeds the separation process, which is the one the plant's throughput target depends on. The second one is what lets a person, or a model, reason.

The three things an ontology records​

Every entry in a DataHub ontology carries three pieces of information. You met them on the resource form; here is what each one is doing.

What is this thing called?

The name, the readable label a person scans in a list. "21-PT-1234 Separator inlet pressure". It can be changed at any time, because nothing depends on it.

In formal ontology terms this is the rdfs:label.

What kind of thing is it?

The label, the class the resource belongs to: Pump, Separator, Site, PressureTransmitter. This is the single most powerful field in the model, because it is what lets you ask about all pumps rather than one pump at a time.

In formal terms this is rdf:type. Write classes in the singular, each word capitalised.

How do systems refer to it, permanently?

The external id, a stable identifier that must never change and never be reused. Imports, integrations and the SDK all match on it.

In formal terms it is the part of the IRI that follows the namespace. Why stability matters →

Plus the fourth thing, which lives on the connections rather than the things:

  • Relationships, the named, directional links between resources: contains, feeds, monitors, powers. These are what turn a catalogue into a knowledge graph.
One entry, three promisesThe resource form's three fields, and the standard role each one plays.A resource in the ontologyName, changes freely21-PT-1234 Separator inlet pressurerdfs:labelfor people; rename freelyLabel, the kind of thingPressureTransmitterrdf:typefor querying whole kinds at onceExternal id, never changes21-PT-1234the IRIfor systems; matched on, forevermonitorsV-201the separator it monitorsthe predicaterelationships make it a graphThe same three roles RDF defines, which is why your model is portable rather than proprietary.
The anatomy of one entry. Each field plays a role that RDF standardised long before this product existed, and the relationship underneath is what turns a catalogue of entries into a graph.

Seeing it written out​

DataHub stores your model as a graph, which is the same idea RDF describes. The same asset, written in RDF, looks like this:

@prefix ex:   <https://example.org/plant/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:21-PT-1234
    a               ex:PressureTransmitter ;      # the label  (rdf:type)
    rdfs:label      "21-PT-1234 Separator inlet pressure" ;   # the name
    ex:monitors     ex:V-201 ;                    # a relationship
    ex:partOf       ex:Line3 .

You never have to write this. It is here to show that the three fields on the console form are not an invention: they are the standard way of describing a thing, and that means your model is interoperable with the wider world of standards and tools rather than trapped in one product.

The alignment is exact rather than approximate, because the external id is stored exactly as you write it. The local part of an IRI is case-sensitive, so ex:21-PT-1234 above is your tag, not a rewritten version of it that every consuming system would have to reproduce.

Why an ontology is worth building​

Four reasons, in the order most organisations come to appreciate them.

⚡
Immediate
Questions get cheap

Once relationships are recorded, a new cross-system question is a traversal instead of an integration project. The marginal cost of the next question drops toward zero.

🧠
Within a year
Knowledge stops walking out the door

The mapping between the historian tag, the equipment number and the physical pump moves from an individual's memory into the organisation's asset base.

🧾
At reporting time
Reports become auditable

A figure that knows what it is about, and what it was computed from, can be defended to a regulator or an auditor rather than merely asserted.

🤖
The long game
Automation becomes possible

Predictive and autonomous capability, the top rungs of the digital twin ladder, needs context to reason over. The ontology is that context. Nothing above it works properly without it.

What a good ontology looks like​

Some hard-won rules of thumb, expanded in Building your model:

  • Small. A first model with 15–25 classes is healthy. One with 200 is a sign somebody modelled the source systems instead of the operation.
  • In your own words. Use the terms your operators and engineers already say out loud. If the plant calls it a "train", the class is Train, not ProcessingUnitAssembly.
  • Grown, not designed. Model the part of the operation your first question touches, get it working, then extend. A model designed in full before any data lands is almost always wrong in ways nobody can see yet. The same logic is why a digital twin is grown, not built.
  • Owned. Somebody must be accountable for it. An ontology with no steward drifts into inconsistency within months. Who does what →
You probably do not start from zero

If your facility follows a tagging standard, ISA-5.1 instrument tags, IEC/ISO 81346 reference designations, NORSOK Z-DP-002, CFIHOS equipment classes, then a large part of your ontology is already specified and in use. Mirror it rather than inventing something new. Standards and naming →

Ontology, taxonomy, knowledge graph​

These three get used interchangeably and they are not the same thing. The short version:

  • A taxonomy classifies: a Pump is a kind of Rotating Equipment.
  • An ontology adds relationships and rules: a Pump can be part of a Line, and must have exactly one.
  • A knowledge graph is the result once you fill it with your real assets: Pump P-101 is part of Line 3. Keep it in step with live data and it becomes a digital twin.

The full comparison →

External references
Go deeper