Ontology vs. Taxonomy vs. Knowledge Graph vs. Semantic Layer vs. Context Graph: A Field Guide

“We need an ontology.” “Isn’t that just a knowledge graph?” Five terms, used almost interchangeably, that actually describe distinct layers of a knowledge architecture, from “how do we name and organise things” up to “what does an AI agent actually load into its context window.” Here’s the map.

1. The one-glance version

• Taxonomy = a tree. Things are organised into categories and subcategories (is-a / part-of hierarchy). No formal reasoning, just classification.
• Ontology = a schema/vocabulary with rules. Defines types of things, their properties, and the relationships allowed between them, often with logical constraints a machine can validate or reason over.
• Knowledge graph (KG) = actual data (instances) connected by typed relationships, usually conforming to an ontology/taxonomy as its schema. It’s the populated database, not the blueprint.
• Semantic layer = a business-facing translation layer that maps raw data (tables, columns, metrics) to consistent, governed business terms (“revenue”, “active customer”) so humans and BI tools query concepts, not SQL.
• Context graph = a retrieval/assembly structure (increasingly used in AI/LLM systems) that selects and links the relevant subset of knowledge (entities, documents, relationships, session state) and hands it to a model as context for a specific task.

They’re not competitors; each builds on or feeds the one before it.

2. Taxonomy: classification

What it is: a hierarchical classification scheme. Every item belongs to exactly one (or a few) categories, and categories nest inside broader ones.

Example:

Animal
├── Vertebrate
│   ├── Mammal
│   └── Bird
└── Invertebrate
    └── Insect

Characteristics:

• Relationships are almost always just “is-a” (parent/child) or “part-of”.
• Simple, intuitive, easy for humans to browse (think: website navigation menus, product catalogues, library classification systems like Dewey Decimal).
• No formal logic. A taxonomy can’t tell you why a dog is a mammal or infer new facts.

Use it when you just need consistent labelling/navigation (content tagging, product categories, org charts).

3. Ontology: formal meaning and rules

What it is: a taxonomy is a subset of what an ontology can express. An ontology defines:

• Classes/types (e.g. Person, Company, Drug)
• Properties/attributes each type can have (Person.birthDate)
• Relationships between types, not just hierarchy (Person worksFor Company, Drug treats Disease)
• Constraints and axioms (a Person cannot be their own parent; every Employee is a Person)

Because it’s logically formal (often built with standards like RDF/RDFS/OWL), software can reason over it: infer new facts, check consistency, validate data.

Example: an ontology might state that Drug —treats→ Disease and Disease —hasSymptom→ Symptom are valid relationship types. It defines the grammar, not any specific drug or disease yet.

Ontology vs. taxonomy in one line: taxonomy answers “what kind of thing is this and what’s it under?” Ontology answers “what kinds of things exist, what properties/relationships are legal between them, and what can we logically infer?”

Use it when you need a shared, machine-interpretable vocabulary across systems/teams, especially where correctness and inference matter (life sciences, finance, enterprise data governance).

4. Knowledge graph: the populated data

What it is: the ontology is the schema; the knowledge graph is the database, actual nodes (entities/instances) and edges (relationships) that conform to that schema, at scale.

Example (instances, not types):

(Aspirin) —treats→ (Headache)
(Aspirin) —manufacturedBy→ (Bayer)
(Bayer) —headquarteredIn→ (Germany)

Here Aspirin, Bayer, Germany are specific real-world entities, not classes.

Relationship to ontology: a KG can be built directly on a formal ontology (this is the “textbook” version, think Google’s original Knowledge Graph, or enterprise KGs using RDF triple stores like Amazon Neptune or GraphDB). Neo4j is often mentioned in the same breath, but it’s natively a labelled property-graph database rather than an RDF store. It uses its own query language, Cypher, and only speaks RDF via an add-on (e.g. neosemantics). In practice, many production knowledge graphs use a lighter, looser schema than a full OWL ontology, but the concept is the same: typed nodes plus typed edges plus instance data.

Why people build them:

• Answer multi-hop questions (“which companies headquartered in countries where Aspirin is manufactured also make painkillers?”) that relational joins handle poorly.
• Power search/recommendation (“people who bought X also…”).
• Give LLMs a structured, explainable fact base (retrieval-augmented generation over graphs, entity linking).

Use it when you have richly interconnected entities and need traversal/inference across relationships, not just lookups.

5. Semantic layer: the business translation layer

What it is: this one comes from the data/BI world, not the AI/reasoning world, and it’s a different axis entirely. A semantic layer sits between raw data infrastructure (warehouses, lakes) and the people/tools querying it. It maps physical data (fct_orders.amt_usd) to governed business concepts (Revenue), with consistent definitions, metrics, and dimensions, so that:

• “Revenue” means the same thing whether queried from Tableau, a Python notebook, or a chatbot.
• Business users write queries in business language, not SQL joins.

Examples of tools: dbt Semantic Layer, LookML (Looker), Snowflake Semantic Views (powers Cortex Analyst), Databricks Unity Catalog Metric Views.

How it relates to ontology/KG:

• A semantic layer is ontology-like in spirit (it defines types of things, metrics, dimensions, entities, and relationships between them), but it’s scoped narrowly to analytics/BI metrics and governed reporting, not general-purpose knowledge or reasoning.
• It typically sits on top of structured tabular data (warehouse tables), whereas a knowledge graph typically stores graph-native entity/relationship data.
• The two are converging in modern “semantic/metrics layers powering AI agents”, where an agent asks “what was our revenue last quarter” and the semantic layer resolves that to the right governed metric definition plus SQL.

Use it when you need one consistent definition of business metrics/entities across many consumption tools (dashboards, notebooks, AI agents).

6. Context graph: the AI-era retrieval/assembly layer

What it is: the newest and least standardised term here (popularised in the current wave of LLM/agent system design, roughly 2024-2026). A context graph is not a permanent knowledge store like a KG, it’s a structure for assembling the right, relevant slice of information (facts, documents, prior conversation turns, user preferences, tool outputs, session state) to feed into a model’s context window for a specific task, often represented as a graph of linked, relevance-scored nodes.

Key differences from a knowledge graph:

How it relates to the others: a context graph is often built from a knowledge graph and/or a semantic layer, e.g. an agent traverses a KG to pull relevant entities, resolves metric names via a semantic layer, retrieves relevant chunks from documents, and assembles all of it into a temporary context graph that gets serialised into the LLM’s prompt. It’s the “just-in-time” layer, whereas ontology/KG/semantic layer are the “always-on” infrastructure it draws from.

Use it when you’re designing retrieval/memory architecture for an LLM agent and need to decide what subset of a much larger knowledge base to include in a given prompt.

7. How the layers stack (architecture view)

Reading it bottom-up:

1. Taxonomy gives you clean categories.
2. Ontology extends that into a full formal vocabulary, types, properties, relationships, logical rules, of which taxonomy (is-a hierarchy) is one part.
3. Knowledge graph populates that vocabulary with real instance data at scale, so you can traverse and query facts.
4. Semantic layer runs in parallel, doing a similar “give things governed meaning” job but specifically for business metrics/BI over warehouse data, rather than general entity relationships.
5. Context graph is the newest, top-most layer. It doesn’t compete with the others, it consumes them (plus documents, chat history, tool outputs) to assemble the right working set of information for an AI agent’s next response.

8. Quick decision guide

9. Common points of confusion (worth internalising)

• “Ontology” is often used loosely to mean “knowledge graph schema”. In casual industry usage, especially at companies like Palantir, “ontology” refers to the combined schema and the operational data layer, which blurs the ontology/KG line described above. Read context carefully.
• Context graph terminology is still unsettled: vendors don’t agree on scope. Some use it to mean “a knowledge graph optimised for RAG”, others mean “a live, session-scoped memory structure”. Treat it as an emerging pattern name rather than a fixed technology, and always check how a specific vendor/paper is defining it.