The blind spot in every data project
Imagine receiving a table with 50,000 rows. Column headers: “event”, “date”, “source”, “value”. The data is complete. The data is current. And still, nobody in the room can say what it means.
Why? Because the table contains facts, but no context. It says that something happened. It does not say what it means, why it matters or how it relates to the other 49,999 rows. An event remains an event. A source remains a source. What is missing is knowledge about how these concepts relate to each other and which conclusions are valid.
This is not a fringe problem. It is the normal state of many public institutions, security organizations and industrial companies. Data exists, but it does not speak to other data.
The reason has a name: a missing ontology.
What an ontology is and what it is not
An ontology is not a database schema. It is not a glossary. It is not a classical taxonomy either.
An ontology is a formal model of reality: it defines which concepts exist, how they relate to one another and which rules apply to those relationships.
A simple example from the security domain:
“Vehicle” is a concept. “Person” is a concept. “License plate” is a concept. An ontology defines that a vehicle has a license plate, that a person may drive a vehicle, that a license plate is registered with an authority and that this authority is responsible for a certain area.
Once these relationships are formally encoded, something decisive happens: a system can derive conclusions from the data that are not present in any single row. It can recognize connections that a human analyst might only see after hours of work, or not at all.
The three layers of the data problem
To understand why ontologies matter so much, it helps to look at the three layers where data projects typically fail.
Layer 1: Syntax. Data comes in different formats: CSV here, XML there, a proprietary database somewhere else. Modern ETL tools handle this well. It is solvable.
Layer 2: Semantics. What does “event” mean in system A, and what does “incident” mean in system B? Are they the same? Often they are not. This is where the real problem begins.
Layer 3: Pragmatics. What is the consequence of this event for the goals of my organization? Which action should be triggered?
Without an ontology, every data integration remains stuck at layer 1. With an ontology, layers 2 and 3 become manageable.
Why this matters for authorities and critical infrastructure
In companies, missing data context is expensive. In public authorities, security organizations and critical infrastructure, it can be dangerous.
When an operations center receives messages from twelve different systems, access control, cameras, registry data, patrol reports and external feeds, it does not only need a surface that displays everything. It needs a layer that understands what these data points mean together.
That is what a domain ontology provides. It is both the memory and the grammar of the system. It makes it possible to combine heterogeneous data sources not just technically, but meaningfully.
What this means in practice
A well-modelled ontology enables:
- Cross-connections between data points that are not explicitly linked in any source dataset
- Rule-based inference: if A and B are true, C follows, automatically, traceably and auditable
- Explainability: every statement of the system can be traced back to its basis
- Adaptability: new concepts and relationships can be introduced without rebuilding the foundation
That is the difference between a system that displays data and a system that understands data.
MAKOR: ontology as core technology
MAKOR is not a visualization tool that makes data look nicer. MAKOR is an ontology-based analysis platform. Domain knowledge about security situations, processes and relationships is not hidden in the interface. It is formally modelled, machine-readable and reviewable.
In the next article, we explain what this means in practice: why the intelligent layer above the data does not only make systems smarter, but also safer.