An Ontology Is More Than a Data Model

When people first hear the word ontology in the context of software, it can sound unnecessarily academic, but in practice the idea is quite simple.

Most software systems are built around data models. They define what information needs to be stored, how records are structured, which fields belong to them, and how those records can be retrieved. That is essential, but it is not the same as describing how an organisation actually works.

A data model might tell us that we have a pump with a serial number, installation date and manufacturer.

An ontology goes further. It describes what that pump is, what it belongs to, where it is installed, what it is connected to, what monitors it, who maintains it, which process it supports, what documentation relates to it, and potentially what depends on it.

The distinction is subtle, but important.

From storing information to describing the real world

Operational organisations are made up of things and relationships between things. For example:

There are locations.

Assets are installed at those locations.

People work at them.

Equipment forms part of processes.

Sensors monitor equipment.

Documents describe assets and procedures.

Customers receive services.

Suppliers maintain equipment.

Events happen to all of these things over time.

Traditional systems usually represent individual parts of this picture extremely well. An asset management system may know about the equipment. A document management system may know about the manuals. A monitoring platform may know about sensor readings. A CRM may know about the customer.

The difficulty comes when we need to understand how those pieces fit together. An ontology provides a common description of the operational world that sits behind those systems.

Taxonomy is only part of the picture

Taxonomy and ontology are sometimes used interchangeably, but they solve different problems.

A taxonomy helps classify things. A pump might be an asset. More specifically, it might be a centrifugal pump. A hospital might be a location. A consultant might be a person.

This classification is useful because it tells us what kind of thing we are dealing with and what characteristics we might expect it to have.

Ontology adds relationships and meaning.

The centrifugal pump is installed in Plant Room A.

Plant Room A is part of Building 3.

The pump feeds Process Line B.

Sensor 204 monitors its vibration.

Maintenance Contract 17 covers the pump.

Manual X describes how it should be serviced.

Once those relationships are represented, we are no longer simply organising records into categories. We are describing an operational environment.

Context becomes part of the information

This changes the way information can be used. Imagine an engineer investigating why a pump has failed.

The telemetry may show that vibration increased three days before the failure.

That information alone is useful, but the engineer may also need to know whether maintenance was recently carried out, whether similar pumps are experiencing the same issue, whether a component was replaced, whether an operating limit was exceeded, whether the equipment is still under warranty, and what downstream processes are affected.

None of those pieces necessarily belong in the same database.

An ontology allows them to be understood as part of the same operational context.

The important point is that the relationships themselves become information.

Knowing that Sensor 204 produced a reading is useful.

Knowing that Sensor 204 monitors Pump 12, which feeds Process Line B at Site A, gives that reading meaning.

Why this matters operationally

Most operational decisions are not made from isolated data points. They depend on understanding combinations of assets, locations, people, documents, events and measurements. This is why simply integrating more systems does not always solve the problem. Integration can make more information accessible without necessarily making its meaning clearer.

An ontology provides a structure for that meaning. It allows information from different systems to describe the same real-world environment without requiring every system to use the same database structure or application model.

This can make it easier to ask questions such as:

Which customers are affected by this equipment failure?

Which assets at this site are overdue for maintenance and currently showing abnormal readings?

Which documents are relevant to the equipment being inspected?

Which facilities contain equipment from a manufacturer affected by a recall?

Which operational processes depend on an asset that has just gone offline?

These are not simply database searches. They require an understanding of relationships.

The ontology can evolve with the organisation

Another important characteristic of an operational ontology is that it does not need to assume that every organisation looks the same.

A hospital may need to represent patients, wards, medical devices and clinicians.

A utility may represent treatment plants, reservoirs, meters and distribution networks.

A manufacturer may represent factories, production lines, machinery, products and suppliers.

The underlying concept remains the same: describe the things that matter to the organisation and the relationships between them. This also means the model can evolve. New types of assets can be added. New relationships can be introduced. New sources of information can be connected without redesigning the entire operational picture.

The ontology becomes a shared vocabulary through which different information can be understood.

From ontology to knowledge graph

Once an ontology is applied to real operational information, something interesting happens; The organisation begins to form a graph.

Assets connect to locations.

Locations connect to customers.

Sensors connect to assets.

People connect to organisations.

Documents connect to equipment and processes.

Events connect to the things they affect.

Rather than looking at information as a collection of separate records, we can start to navigate the relationships between them. That is the foundation of a knowledge graph, and it creates a very different way of thinking about operational information: not simply as data that can be searched, but as a connected representation of the organisation itself.