Ontology, Knowledge Graph, Data Catalog, and Semantic Layer: Understanding the Differences

These four things get mixed up because they all "add meaning to data." They do it in different ways, for different readers. Here is the short answer.

• Ontology: defines what kinds of things exist and how they relate.
• Knowledge graph: holds the actual things, linked by those relations.
• Data catalog: tells people what data exists, where it lives and whether to trust it.
• Semantic layer: defines business metrics once, so every tool computes them the same way.

Each one owns one job. Trouble starts when a team expects one of them to do another's job.

Ontology: the model of the domain

An ontology is a written model of a domain. It says that a Customer can hold many Contracts, that a Contract belongs to one legal entity, and that an Invoice is not the same thing as a Payment.

It is about meaning, not storage. An ontology can live in a diagram, a text file or a formal language. It holds no rows. Its value is that people and systems agree on what the words mean.

It answers: what do we mean by this term, and what rules hold between terms?

Knowledge graph: the data, linked by that model

A knowledge graph is the instance data. It holds Acme Ltd, its three contracts and the invoices raised against them, joined by the relations the ontology defined.

You can build a graph without a formal ontology. It then drifts, because nothing says what a link means. You can also write an ontology and never build a graph. Then you have a good document and no data.

It answers: what is connected to this thing, and how?

Data catalog: the inventory

A catalog is an inventory of your data assets. It lists tables, columns, owners, freshness, lineage and notes. Its reader is a person who asks, "Which table has revenue, and can I use it?"

A catalog does not define what revenue means. It points to the table and records who owns it. It describes data. It does not model the business.

It answers: what data do we have, where is it, and who stands behind it?

Semantic layer: metrics defined once

A semantic layer sits between the warehouse and the tools that query it. It holds the definitions: what counts as an active customer, how net revenue is computed, which date a sale belongs to. Dashboards, notebooks and AI queries all read the same definition.

It is narrower than an ontology. It deals in measures, dimensions and joins, not in the full set of things and rules in a domain. That narrowness is why it is practical.

It answers: what is the number, and why do two reports agree?

How they fit together

Think of a flow from meaning to use.

1. The ontology fixes the vocabulary and the rules.
2. The catalog records which physical tables hold each concept, and who owns them.
3. The semantic layer turns the concepts that matter for reporting into metrics.
4. The knowledge graph holds the linked instances where relations, not aggregates, are the point.

A concrete case: the ontology says a Customer is a legal entity with at least one active Contract. The catalog says that fact lives in two tables and names the owner of each. The semantic layer defines "active customers" from them. The graph answers "which customers share a parent company?" The same word means the same thing at every step.

Common mistakes

• Buying a catalog to fix conflicting numbers. A catalog lists the conflict. It does not resolve it. A semantic layer does.
• Building a graph before agreeing on terms. You get connected data with no shared meaning.
• Writing an ontology nobody reads. If it never reaches the catalog or the metric definitions, it stays a diagram.
• Calling a semantic layer an ontology. It covers metrics, not the whole domain.

Which one first

Start with the problem you can name. If two reports disagree on a number, define the metric in a semantic layer. If people cannot find or trust tables, set up a catalog and name owners. If the same word means different things across systems, write the ontology. Build a graph only when relations between things are what you need to query.

Small teams rarely need all four. Fewer parts that someone owns beat more parts that nobody does.

Who should not hire me for this

If you want a formal ontology programme or a graph database project, I am the wrong fit. I work alone, and I build lean data platforms and approval-gated AI workflows on a company's own data. I do this work when the aim is a platform whose definitions are clear enough that a person, or an AI workflow, can rely on them.

Check your own platform first

Before adding any of these, look at what you have. The free Data Platform Teardown lets you check your platform yourself, with no signup.