Ontology: Meaning Beyond Tables

In manufacturing and software we have worked with tables for a long time. Rows, columns, primary keys. A product here, a machine there, a tool somewhere else. The systems run, the reports come out. But the moment you ask a question, things change: “Which machine, with which tool, in whose shift was this product made?” The tables don’t answer — because they don’t hold the relationship, only the data.

In this post I’ll explain what an ontology is, what it means in technology, with a simple example and how to move beyond current table-based systems.

Explanation: what is an ontology?

An ontology is a structure that explicitly and shared-ly defines the concepts of a domain and the relations between those concepts. The word comes from philosophy, and it says exactly that: “the study of what exists.”

In a factory, an ontology answers these questions:

• Which concepts exist? (Product, Machine, Tool, Operator, Shift, Order, Defect)
• What are they?
• How are they connected? (Product is produced on Machine, Machine uses Tool, Operator works in Shift)
• What rules govern these connections? (A tool cannot be in two machines at once)

The difference: a table stores data, an ontology stores meaning. A table record is meaningless alone; an ontology record sits inside its context.

What it means in technology

In software, an ontology is the ground that lets machines “understand” a domain.

• ERP/MES/MOM systems process data but often don’t understand each other. An ontology creates a shared language across them.
• The semantic layer we talk about is the application of ontology: data now flows as related objects.
• AI makes a prediction, and because ontology provides context, it knows which product and which machine that prediction belongs to.
• Search, recommendation, root-cause analysis work over relations, so they stay incomplete without an ontology.

In short: ontology turns scattered data into a system where parts talk to each other.

Example diagram

A simple production ontology:

[Product A]
   │ is produced on
   ▼
[Machine 3]
   │ uses
   ▼
[Tool 2]
   │ operated by
   ▼
[Operator X] ── works in ──▶ [Shift-1]

[Order 100] ── requests ──▶ [Product A]
[Defect-7] ── affects ──▶ [Product A]

Here the arrows are not just links, they carry meaning. “is produced on”, “uses”, “operated by”, “requests”, “affects” — all are defined relation types. When a system reads this diagram, it can answer “what does Defect-7 affect?” in a single query.

Where should table-keepers start?

Most companies today keep data in tables but don’t build semantic relations between them. To grow an ontology from such a system, start with these questions:

1. What are our core concepts? (Product, customer, order, machine, defect…)
2. Do these concepts really exist, or are they reporting shortcuts? Drop the unnecessary ones.
3. What kind of relation is there between A and B? (“belongs to”, “produces”, “causes”)
4. Is a relation one-way or two-way? (Product→Machine is not the same as Machine→Product)
5. Is there a rule for this relation? (A tool cannot be in two machines at once)
6. Is the same concept named differently in different places? (ERP “Material”, MES “Raw” → define one type)
7. If a record is deleted, what happens to its links? (If an order is cancelled, what does the production order do?)

When you answer these, a relational ground emerges beyond your tables. That ground gives birth to your ontology.

Closing

An ontology is nothing to exaggerate. It is not a complex tool, it simply says “these concepts exist and they connect like this”. But this small step lets systems understand each other, lets AI sit in context, and lets humans ask the right question in the right place.

Keep your tables — but beyond them, define the connection between them. The rest flows on its own.