Triples, Ontologies and the Open World

A knowledge graph stores facts as triples: subject, predicate, object. It is a schema-light representation whose properties differ from a relational schema in ways that determine what it is good for.

What the triple model buys

Schema evolution without migration. Adding a new relation type means adding triples, not altering a table. For a domain whose structure is discovered rather than designed, integrating heterogeneous sources, modelling a field that keeps growing, this is the decisive advantage.

Sparsity without cost. Entities have wildly different attribute sets, and a triple store holds only what exists, where a wide table would hold mostly nulls.

Uniform querying across relations. Traversal is the same operation regardless of relation type, so multi-hop queries compose naturally in a way that requires a join per hop in a relational model.

The costs are equally real: no enforced structure means nothing prevents inconsistency, queries requiring many hops are expensive, and aggregation is awkward compared with a columnar store.

The open world assumption

A relational database is closed-world: a fact absent from the table is false. A knowledge graph is conventionally open-world: a fact absent from the graph is unknown, not false.

This distinction determines everything about how the graph is used. "Is there an edge between A and B" cannot be answered negatively, only as "not recorded". Link prediction exists as a task precisely because absence carries no information, and completeness cannot be assumed, so a query returning nothing has not established that nothing is there.

Local closed-world assumptions are the practical compromise: assume completeness for particular relations where the source is known to be exhaustive, such as a person having exactly one date of birth, while remaining open elsewhere. Recording which relations are closed is a schema decision that most graphs make implicitly and should make explicitly.

Ontologies

An ontology adds structure: class hierarchies, domain and range constraints on relations, and axioms such as symmetry, transitivity and inverse relations.

Its value is that it enables inference. Declaring partOf transitive means a query for what a component belongs to traverses without every intermediate fact being stored, and declaring domain and range constraints catches errors at insertion.

Its cost is rigidity, which is the property the triple model was chosen to avoid. A heavyweight ontology developed up front tends to be wrong about a domain nobody fully understood yet, and revising it invalidates data already asserted under it. Most successful production graphs use a light ontology, a handful of classes and constraints, and add structure only where it earns its way.

When it breaks

Entity identity is the hardest problem and is upstream of everything. Two nodes for the same entity split its facts and every query over it. This is entity resolution, and no amount of graph machinery compensates for getting it wrong.

Reification is awkward. Statements about statements, provenance, confidence, temporal validity, do not fit the triple model, and the workarounds, reified statements, named graphs, RDF-star, all add complexity. Any graph that needs to record when a fact was true or where it came from hits this immediately.

Open-world semantics confuse consumers. An application treating a missing edge as false is applying closed-world reasoning to an open-world store, which is the single most common source of wrong answers from a knowledge graph.

Inference must be bounded. Transitive closure over a large graph is expensive and can be unbounded, so materialising inferences trades storage and staleness against query cost, and doing it lazily trades query latency. Neither is free and the choice belongs to the workload.