Knowledge Graph vs Ontology: A Practical Distinction

Two layers, one stack

The cleanest way to keep these two ideas straight is to think of ontology and knowledge graph as two layers in the same stack. The ontology is the schema layer: it defines what kinds of things exist in your domain, what relationships are allowed between them, and what rules constrain the data. The knowledge graph is the instance layer: the actual nodes, edges, and properties that conform to that schema.

Tom Gruber's classic 1993 definition still holds: an ontology is 'a specification of a conceptualization' — a formal, explicit description of the concepts and relationships that exist in a shared view of a domain. Note the words 'formal' and 'explicit'. An ontology is not the implicit understanding in a domain expert's head; it is a written-down artefact, usually in a machine-readable language like OWL, RDFS, or SHACL.

A knowledge graph, by contrast, is the body of facts that lives under that ontology. The ontology says 'a Person can have an employer that must be an Organization'; the knowledge graph says 'Marie Curie is employed by the University of Paris'. Without the schema, you have raw triples; without the instances, you have a description of a world but no actual data about it.

What goes in an ontology

A useful production ontology answers four questions for every domain it covers. First, what entity types exist? In a hospital ontology you might find Patient, Encounter, Condition, Procedure, Medication, Provider. Second, what relationships are allowed between them? An Encounter has-a Patient and a Provider; a Procedure is-during an Encounter; a Medication treats a Condition. Third, what are the cardinality and obligation rules? A Patient must have exactly one date_of_birth; an Encounter must have at least one Provider.

Fourth, what disjointness or hierarchy applies? A Person and an Organization are disjoint — nothing can be both. A Surgeon is a kind of Provider; a Provider is a kind of Person. These hierarchies, called subsumption or rdfs:subClassOf relationships, let a query for 'all Providers' return Surgeons too without a separate clause.

An ontology may also encode richer constraints — disjoint property axioms, inverse properties, transitive properties — but for most engineering teams, getting types, relationships, cardinality, and hierarchy right is 90% of the value. The remaining 10% lives in OWL DL territory and pays off only in domains like life sciences where formal reasoning genuinely matters.

What goes in a knowledge graph

If the ontology is the recipe, the knowledge graph is the meal. Every node in a well-formed knowledge graph claims membership in one or more types from the ontology. Every edge claims a predicate or relationship type from the ontology. Properties are typed against the ontology's expectations — a date_of_birth that the ontology says must be an xsd:date had better not be a free-text string.

Where an ontology is deliberately small (most real-world ontologies are a few hundred to a few thousand classes and properties), a knowledge graph is typically large. Wikidata, the largest public general-purpose knowledge graph, contains more than 100 million entities and over 1.5 billion statements as of 2024. The ontology that governs Wikidata is hundreds of properties, not millions.

A knowledge graph also tends to carry provenance information that an ontology does not need. Each fact may be annotated with where it came from, when it was asserted, and by which agent. This is why production knowledge graphs are not just 'an ontology with data poured in' — the operational metadata is itself part of the graph.

An ontology has a few hundred to a few thousand classes; the knowledge graph that conforms to it can have hundreds of millions of nodes.

Why teams confuse them

Three common confusions explain almost every misuse of these terms in industry. First, in a property-graph stack like Neo4j the schema is often implicit — there is no separate schema file, and the constraints live in indexes and uniqueness rules. Teams say 'we have a knowledge graph' when in fact they have an ad-hoc graph with no published schema, blurring the line.

Second, in semantic-web stacks the ontology and the knowledge graph are stored in the same triple store, often in adjacent named graphs. A SPARQL query can join across both. This makes them feel like one artefact even though they are conceptually two.

Third, vendors muddy the waters. Marketing copy frequently calls a populated graph 'the company's ontology', or calls a schema 'the knowledge graph'. The cleanest discipline is to keep the words distinct: ontology is the spec, knowledge graph is the dataset. If you find yourself saying both interchangeably, you are probably doing one or the other thinly.

Practical advice for building both

Start the ontology before you start the graph, but keep it minimal. A first-pass ontology with five entity types and ten relationship types is enough to populate a meaningful prototype graph. Resist the urge to model every nuance up front — the second and third versions of an ontology, written after you have actual data, are always better than the first.

Version the ontology like code. Use Git, semantic versioning, and a changelog. When the ontology changes incompatibly — for instance, you split a single Person type into Researcher and Practitioner — your knowledge graph migration must be planned, not improvised.

Borrow before building. Schema.org, FOAF, SKOS, the Bibliographic Ontology, and many domain-specific ontologies (BFO, Gene Ontology, FIBO for finance) are stable, well-tested, and free. Reusing established vocabularies makes your graph interoperable with public data and saves months of bikeshedding. KnodeGraph's templates are deliberately small starter ontologies — Research, Legal, Medical, BI — designed to be cloned and extended rather than adopted wholesale.

Finally, accept that the ontology is never finished. Domains evolve, the way you describe them evolves, and so will your schema. A healthy knowledge graph project budgets time for ontology maintenance, not just data ingestion.

Related reading

• Knowledge graphs in medical research — How healthcare teams use ontologies like SNOMED CT and ICD-11 alongside their own knowledge graphs.
• KnodeGraph vs Stardog — How a heavyweight semantic-web platform with deep ontology support compares to a lightweight modern alternative.
• Knowledge graphs for pharma — Where formal ontologies (Gene Ontology, ChEBI, MedDRA) and knowledge graphs converge in life sciences.

Frequently Asked Questions

Source

Thomas R. Gruber, 'A translation approach to portable ontology specifications', Knowledge Acquisition 5(2), 1993, pp. 199–220. [link]