Ontology, taxonomy, knowledge graph, or semantic layer: which one do you need?

Scope

Use this comparison when teams agree that data needs more meaning but disagree about the artifact to build. Begin with a workflow such as asset impact analysis, product reporting, access control, search, incident response, or customer-entity resolution.

Why it happens

The four terms are often used as product categories, so architecture discussions begin with a technology and work backward. A team may build a graph when it only needs a controlled list, or a formal ontology when it cannot yet maintain stable identifiers. Another team may call a metric catalog a semantic layer even though definitions, joins, ownership, and time rules remain inconsistent.

The result is a sophisticated representation of unresolved organizational disagreement.

Diagnosis

Write the decision and the semantic failure that currently prevents it. Then ask:

1. Do users mainly disagree about labels and category boundaries?
2. Must the system express typed entities, relations, constraints, or inference rules?
3. Are multi-hop relationships, provenance, and changing facts central to the query?
4. Do consumers mainly need consistent measures, dimensions, joins, and time semantics?
5. Who owns identity resolution, definition changes, conflicts, and exceptions?
6. How quickly must the representation reflect a real-world change?

If ownership and refresh cannot be answered, choosing a richer model increases stale certainty rather than useful meaning.

Solution

Adopt the smallest useful layer and add complexity only when a decision requires it:

Need	Start with	Core governance question
Consistent vocabulary and navigation	Taxonomy	Who owns concept, label, hierarchy, and mapping changes?
Explicit domain meaning and constraints	Ontology	Which inferences are valid, and who accepts their consequences?
Connected facts and provenance	Knowledge graph	How are identity, source, observation time, and confidence represented?
Consistent analytical measures	Semantic layer	Who owns metric formulas, joins, grains, filters, and effective dates?

The layers can share identifiers and definitions. A taxonomy can provide labels for ontology classes; an ontology can define relations used in a graph; a semantic layer can compute governed measures from graph or tabular data. Do not merge their responsibilities into one unlabeled object.

Version definitions and mappings. Preserve observed time, effective time, source, and confidence for facts that can change. Test the semantic system with real decisions: whether two users obtain the same measure, whether an impact query finds known dependencies, or whether a prohibited inference is blocked.

Artifact

For one workflow, complete this semantic decision canvas:

Field	Answer
Decision	What action or conclusion will the model support?
Consumer	Person or system using it
Required concepts	Terms that must be shared
Required relations	Connections that affect the decision
Required measures	Formula, grain, filters, units, and time semantics
Evidence	Source, provenance, confidence, observed and effective time
Owner	Definition, mapping, exception, and quality owners
Freshness	Maximum acceptable lag and detection method

Common mistakes

• Buying a graph database before defining the decision and identity rules.
• Calling a hierarchy an ontology because the name sounds more capable.
• Treating a metric name as a definition while grain, filters, and time windows differ.
• Omitting provenance and temporal meaning from facts that can change.
• Assuming formal logic makes source data correct.
• Letting an LLM resolve contested business definitions without accountable owners.