Property Graphs & Knowledge Graphs
Methodology → representation
Graphs are memory with structure — but not all structure is causal.
Teams often say “knowledge graph” when they really mean “a graph database”. The difference matters because governance and meaning live in different layers than traversal and retrieval.
Two graph families (and what each optimizes)
Property graph
Purpose: engineering ergonomics and fast traversal.
Data model: nodes/edges with arbitrary key-value properties.
Typical wins: exploration, neighborhood expansion, ranking, path queries.
Knowledge graph
Purpose: semantics, interoperability, and governance.
Data model: typed concepts and relations, explicit meaning, validation rules.
Typical wins: schema discipline, policy enforcement, consistent interpretation.
Diagram: data vs meaning
flowchart LR;
PG["Property graph</br>(nodes/edges + properties)"] --> KG["Knowledge graph</br>(ontology + constraints + meaning)"];
KG --> Q["Queries with validity guarantees"];Where graphs help — and where they mislead
A graph can store "what is connected" without storing "why it is true".
Causal claims require mechanisms and counterfactual commitments; paths alone are not enough.
Great for
- Navigation: “show me what relates to X”
- Evidence clusters: “what supports this claim”
- Governance: “is this assertion even allowed”
Risky for
- Equating proximity with causality
- Mixing incompatible sources without noticing
- Smuggling policy decisions into “similarity” heuristics
Diagram: provenance as a first-class object
flowchart TB;
S["Source document"] --> V["Version + scope"];
V --> F["Claim / fact"];
F --> E["Edge assertion"];
E --> C["Constraint validation"];Practical rule
- If you need speed and flexible ingestion: start with a property graph.
- If you need governance, auditability, and correctness: add knowledge-graph semantics (types + constraints + provenance).
- If you need “why, not just what”: build causal traversal on top (paths + traces + abstention).