Ontologies for Data Engineers: Beyond Tables and Schemas

Short answer: an ontology is a written, machine-readable statement of what your data means. A schema says how data is stored. An ontology says what the things in it are and how they relate. Most teams do not need a formal one. Many teams need the habit behind it.

This essay is for data engineers who know tables, keys and dimensional models well, and who keep hearing the word "ontology" without a clear picture of what it adds.

What a schema cannot say

A table definition tells you a column is called status, that it is a string, and that it may not be null. It does not tell you:

• whether "active" means the same thing in billing and in support;
• whether a cancelled order is still an order;
• whether two rows in two systems describe the same real customer.

Those are questions of meaning. Today they live in people's heads, in a wiki that is out of date, or in the WHERE clauses of a dozen dashboards. That is the gap an ontology tries to close.

The three parts of an ontology

An ontology has three kinds of parts. You already use rough versions of each.

Concepts (classes). The kinds of thing in your domain: Customer, Subscription, Invoice. A concept is not a table. One concept can span several tables, and one table can mix several concepts.

Relationships (properties). How concepts connect: a Customer holds a Subscription; an Invoice bills a Subscription. This looks like a foreign key, with two differences. The relationship has a name and a direction that carry meaning. And it is stated once, apart from any one table.

Rules (axioms). Statements that must be true. A Subscription has exactly one billing Customer. Every Invoice belongs to a Subscription. A Customer that is also a Supplier is one entity, not two. Rules are where formal semantics comes in: they are written so a program can check them, and sometimes derive new facts from them.

A small example

Here is a tiny piece of domain, written as subject-predicate-object statements. This is the shape most formal ontology languages use:

acme      is_a        Customer
plan-7    is_a        Subscription
acme      holds       plan-7
inv-102   bills       plan-7

Now add one rule: anything that holds a Subscription is a Customer. If a source system loads globex holds plan-9 and says nothing else about globex, software can conclude that globex is a Customer. No one wrote that row. The rule produced it.

That is the practical difference. A schema stores the facts you give it. An ontology can also state what follows from them.

How this relates to what you already do

Ontologies do not compete with dimensional models or normalised schemas. They sit above them.

• Dimensional model. Built for fast, clear analytics. It answers "how do I query this?" An ontology answers "what does this mean, across every source?"
• Data catalog and glossary. A glossary is an informal ontology: concepts with definitions. Adding named relationships and checkable rules is the step from glossary to ontology.
• Data contracts. A contract fixes the shape and quality of one feed. An ontology gives the shared vocabulary that many contracts refer to.
• Entity resolution. Deciding that two records are one customer is a rule about identity. An ontology is a good place to write that rule down once.

In short: schemas describe storage, models describe analysis, ontologies describe meaning. You can have the first two without the third. Trouble starts when meaning is implicit and every team fills it in differently.

When it is worth the effort

A formal ontology earns its cost in a few cases:

• Many source systems must agree on what a word means, and they currently do not.
• Software must reason over the data, not only report on it. Approval-gated AI workflows are one example: an agent that acts on "the customer's open invoices" needs a firm answer to what that phrase covers.
• Natural-language questions are asked of your data, and the system must map words to the right tables and joins.
• Domain rules change often, and you want to change them in one place.

It is probably not worth it when you have one or two sources, a small team, and a glossary that people actually read.

A lazy path that works

You do not need an ontology language to get most of the benefit. Start here:

1. List the ten or so core concepts of your business. Write one plain sentence defining each.
2. For each pair that connects, write the relationship as a sentence with a verb: "A Customer holds a Subscription."
3. Write the rules that must always be true. Turn the ones you can into tests that run on your pipelines.
4. Keep the file in version control, next to the code.
5. Only if you hit a need that a plain file cannot meet, such as inference across sources, move it into a formal language and a tool that reads it.

Step three is where data engineers have the edge. A rule that you can express as a test is a rule you can enforce.

Costs and limits

Ontologies cost real effort. Agreeing on definitions is a people problem more than a technical one. A formal model that nobody maintains is worse than a short glossary that is current. And a rich ontology over dirty data only makes the dirt more precisely described. Fix the data first.

Who should not hire me for this

I am one person, and I do not run ontology or knowledge-graph programmes. If you want a formal semantic model built across a large organisation, you need a different kind of team. What I do is look at a data platform, find where meaning is unclear or where cost is leaking, and fix the part that pays back first.

Where to go next

If you want to see where your own platform stands, the free Data Platform Teardown is a checklist you run yourself, with no sign-up. If it shows problems you want help with, the paid audit is the next step after that.