What is Ontology?
Also called schema, taxonomy.
An ontology is a formal specification of the entity types, relationship types, and constraints that a knowledge store is allowed to contain. It defines what a Person, Order, or Incident is, which relations may connect them, and which properties each requires. Without one, a knowledge graph drifts into inconsistent labels that queries cannot rely on.
The practical function is agreement. When extraction produces employed_by, works_at, and worksFor for the same relationship, no query can retrieve all of them reliably. An ontology fixes one name, states which entity types it may connect, and lets extraction be validated against that definition, so malformed records are rejected at write time rather than discovered during a failing query months later.
Ontologies vary widely in formality. At the lightweight end is a list of permitted entity and relation types with short descriptions, which is what most retrieval systems actually need. At the heavier end are formal web ontology languages with inheritance and inference rules that can derive new facts automatically. The heavier machinery brings modeling and maintenance costs that rarely pay off for retrieval-focused systems.
Design is a scoping exercise, not an attempt at completeness. A useful ontology covers the entity types that appear in real user questions and stops there; an ambitious one models a whole domain and collapses under its own maintenance burden. Starting from a sample of actual queries, and adding types only when a question needs them, keeps the model small enough to stay accurate.
Change management is the hard ongoing part. Renaming a relation, splitting an entity type, or tightening a constraint invalidates existing records, so ontologies need versioning and a migration path for stored facts, much like a database schema. Systems that let extraction silently introduce new types instead accumulate a vocabulary nobody documented and nobody can query consistently.
Key points
- Defines permitted entity types, relations, and constraints
- Prevents synonym drift that breaks graph queries
- Lightweight type lists suffice for most retrieval systems
- Scope it to types real user questions require
- Changes need versioning and migration like a database schema
In practice
A support knowledge graph defines four entity types and six relations, including reported_by connecting an Incident to a Customer. Extraction attempting to write raised_by is rejected and mapped to the canonical relation. A year later, every query for incidents by customer still returns complete results, because no alternative spelling of that relationship was ever allowed into the store.