Untangling Data Architecture: CDM vs. Ontology vs. Knowledge Graph
In modern data discussions, terms like Canonical Data Model (CDM), Ontology, and Knowledge Graph are often mashed into a single idea. Treating them as interchangeable leads to over-engineering, confusion, and systems that try to solve everything at once.
Each concept operates at a completely different abstraction layer: Meaning, Data, or Structure.
The Three Layers Explained
-
1. Ontology (The Rulebook — Meaning): Defines concepts, relationships, and business constraints (e.g., “A Customer places an Order”). It provides the formal conceptual specification without being tied to specific payload schemas or physical database tables.
-
2. Knowledge Graph (The Reality — Data): Populates the ontology’s concepts with actual, interconnected facts and live instances (e.g., “Max Mustermann purchased Product X”). It forms an interconnected network of nodes and edges.
-
3. Canonical Data Model (The Dictionary — Structure): Provides a standardized, shared payload schema (e.g., JSON Schema, Protobuf, Avro) for message exchange across systems, collapsing $N \times (N – 1)$ point-to-point integration translations into $N$ standard mappings.
| Layer |
Primary Question |
Core Focus |
Typical Formats / Standards |
| Ontology |
What does it mean? |
Abstract concepts, relationships, and business rules. |
OWL, RDFS, SKOS |
| Knowledge Graph |
What is the actual state? |
Connected real-world instances and live relationship facts. |
Graph Databases, RDF Triples, Property Graphs |
| Canonical Data Model |
How do we format this? |
Consistent structural syntax for system-to-system integration. |
JSON Schema, Avro, Protobuf, XSD |
The Takeaway: When designing enterprise data systems or grounding GenAI applications, avoid the “one model to rule them all” trap. Keep Meaning (Ontology), Facts (Knowledge Graph), and Format (CDM) clearly decoupled.
