Ontologies

Definition

An ontology is a formal, machine-readable model of a domain: it names the kinds of thing that exist (classes such as Gene or Disease), the properties and relationships those things can have (participates in, has symptom), the specific individuals that instantiate the classes, and — the part that makes it more than a labelled glossary — the logical axioms that state what follows from all of it. Because those axioms are written in a language a reasoner can execute, an ontology does not merely describe a domain; it lets a computer derive conclusions that nobody typed in.

That is the line between an ontology and the two things it is most often confused with. A taxonomy only arranges terms in a broader/narrower hierarchy — it can tell you a beagle is a dog, but not that a dog has exactly one biological mother, and it cannot infer anything. A knowledge graph is the filled-in data: the millions of specific facts. The ontology is the schema those facts must obey. Every ontology contains a taxonomy (the is-a backbone), but adding a hierarchy of labels does not make a taxonomy an ontology, and the instance data of a knowledge graph is not the ontology either. The classic one-line definition, from Tom Gruber's 1993 paper A Translation Approach to Portable Ontology Specifications, is "an explicit specification of a conceptualization" — later sharpened by others to formal, explicit specification of a shared conceptualization, where every adjective is load-bearing: formal so a machine can process it, explicit so nothing is left to a reader's judgement, shared so two systems mean the same thing by the same word.

What breaks if you ignore the distinction is concrete and expensive. You buy a graph database, load a taxonomy of category labels into it, and then discover the "reasoning" you were sold never materialises — a hierarchy of labels has no axioms for a reasoner to run, so nothing gets inferred. Or worse, two teams merge their data on the unstated assumption that both use patient to mean the same class, when no ontology has ever asserted that they do; the join silently produces rows that are wrong in ways no error message will ever flag. The whole reason ontologies are formal is to make that shared meaning explicit enough for a machine to check, instead of a hope living in two developers' heads.

How It Works

A fact is a triple, an axiom is a rule about triples

Almost every ontology on the web is built on the same atomic unit: the triple, a three-part statement of subject, predicate, object. IL7R participates-in IL-7 Signaling Pathway is one triple; Heart part-of Circulatory System is another. This is the RDF (Resource Description Framework) data model, and three slots is the whole of it — the same minimal shape that underlies knowledge graphs. RDF on its own only lets you state facts. The ontology layers arrive on top of it:

• RDFS (RDF Schema) adds the vocabulary of structure: Class, subClassOf, domain, range. This is where Beagle subClassOf Dog lives, and where a property can be told it only applies to a particular class.
• OWL (Web Ontology Language) adds the axioms that make reasoning powerful: a property can be declared transitive, functional (at most one value), inverse of another, symmetric; a class can be defined as the intersection of others, or as disjoint from another so that no individual can belong to both.

The distinction that matters for a newcomer is that RDFS and OWL statements are not data entry — they are rules. When you declare part-of transitive, you have not added a fact; you have told the reasoner that from Heart part-of Circulatory System and Circulatory System part-of Body it must conclude Heart part-of Body, even though nobody wrote that last triple. That derived triple is the payoff of the whole exercise, and it is why an ontology is worth more than the taxonomy hiding inside it.

The three jobs a reasoner does

Feed an ontology and its individuals to a description-logic reasoner (HermiT, ELK, Pellet) and it does three things, all of them consequences of the axioms rather than lookups:

1. Classification (subsumption) — work out the full subClassOf hierarchy implied by the definitions, including subclass relationships nobody stated. If Grandparent is defined as a person with a child who is a parent, the reasoner places it under Parent on its own.
2. Consistency checking — detect that the axioms contradict: an individual asserted to be both a Cat and a Dog when those classes are declared disjoint is a modelling error the reasoner surfaces as an error, not a silently-wrong row.
3. Instance checking — decide which classes a given individual belongs to. An individual with two known children is inferred to be a Parent without that ever being asserted directly.

None of this is free, and the cost is not a matter of hardware. The more expressive the axioms you allow, the more expensive reasoning becomes — a relationship set out in full on Knowledge Representation as the expressiveness–tractability trade-off. It is exactly why OWL ships as profiles (OWL 2 EL, QL, RL): each is a deliberately weakened subset chosen so that classification stays fast on ontologies with hundreds of thousands of classes, at the price of constructs you agree not to use.

The other job: making data mergeable

Reasoning is one half of what ontologies buy; data integration is the other, and for many organisations it is the bigger half. Because RDF names every class and property with a global identifier (a URI), two datasets built against the same ontology mean the same thing by the same name, so their triples can be combined by anyone without a mapping step. That is the entire premise of the Semantic Web and of public knowledge bases like Wikidata and DBpedia. Without a shared ontology, integrating two sources is a bespoke translation project every time; with one, it is a set union.

Types

Ontologies are classified less by their subject than by their level of generality — a genuine, long-standing typology from ontology engineering (Nicola Guarino's Formal Ontology and Information Systems, 1998), and the axis that explains why the Gene Ontology and schema.org are both "ontologies" while doing very different jobs. It is orthogonal to the RDF-versus-property-graph data-model split, which belongs to knowledge graphs.

Upper (foundational) ontologies sit at the top and describe domain-independent categories — object, process, quality, role, time, part-hood — that any field can specialise. BFO (Basic Formal Ontology), DOLCE and SUMO are the well-known ones. Their value is consistency: if two domain ontologies both anchor their notion of "process" to BFO, they align at the roots for free.

Domain ontologies model the concepts of one field in depth. The Gene Ontology, SNOMED CT for clinical medicine, and FIBO for finance are canonical examples. This is where most real work happens, and where the hard, expert-heavy modelling lives.

Application (task) ontologies are narrow and tied to a specific system or task — the classes and properties a single application needs, often assembled by importing pieces of domain and upper ontologies rather than built from scratch.

schema.org sits slightly outside this ladder: it is a broad shared vocabulary spanning many domains, deliberately kept light on axioms so that millions of website authors will actually use it. That trade — reach over logical depth — is a legitimate ontology design choice, not a failure to be a "real" ontology.

Real-World Applications

The Gene Ontology is the textbook working ontology. Built and curated by the GO Consortium, its 2026 release defines 39,906 terms describing what gene products do, split into 25,699 biological processes, 10,155 molecular functions and 4,052 cellular components (Nucleic Acids Research, The Gene Ontology knowledgebase in 2026, vol. 54, D1779–D1792). Biologists use it for enrichment analysis: given a list of genes that changed in an experiment, the ontology's is-a and part-of axioms let software ask whether those genes cluster under any GO term more than chance would predict — a question that is only answerable because the terms are formally related, not merely listed. That the biological-process branch alone holds more than 25,000 terms, roughly two-thirds of the whole, is itself informative: it is the aspect where the relationships between concepts matter most.

SNOMED CT is an ontology whose logic was deliberately kept weak. The clinical terminology used in health systems across dozens of countries contains hundreds of thousands of concepts, and every one must be classified — placed correctly in the subsumption hierarchy its definition implies — and reclassified whenever definitions change. That is only tractable because it is written in OWL 2 EL, the polynomial-time profile; the exact concept count and the complexity argument behind that choice are on Knowledge Representation. It is the clearest real-world case of expressiveness being traded away on purpose to keep reasoning affordable.

schema.org structures the web for machines. The vocabulary co-founded by the major search engines is what lets a page mark itself up as a Recipe, Product or Event so that a search engine reads its meaning rather than guessing from text. It is one of the feeders of the Google Knowledge Graph and a large part of why semantic search can answer questions about entities rather than just matching strings.

Grounding language models. The newest application is using an ontology to constrain what a large language model retrieves and asserts. Because the ontology states which relationships are valid, a retrieval or generation step can be held to relationships it sanctions instead of inventing plausible-sounding ones — the ontology-grounded end of the knowledge-graph and RAG work aimed at reducing hallucination. The honest framing matters here: an ontology reduces hallucination only for the slice of a domain it actually covers, and grounding an answer in a schema the model can consult is a different thing from the schema making the model correct.

Key Concepts

Schema versus data is the distinction to hold onto. Almost every confusion around this term dissolves into one sentence: the ontology is the schema, the knowledge graph is the data, and the taxonomy is the is-a skeleton both share. An ontology with no individuals is an empty schema; a knowledge graph with no ontology is a pile of edges nobody can validate; a taxonomy is what you get if you keep the hierarchy and throw the axioms away. When a vendor says "ontology" and shows you a tree of categories, they have shown you a taxonomy and named it for the more impressive thing.

Ontologies assume an open world, and databases do not. Under the open-world assumption that OWL uses, a fact not stated is unknown, not false. Query an ontology for "people born in Honolulu" and the individuals with no recorded birthplace are not thereby non-Hawaiian — they are simply unrecorded. A relational database defaults to the opposite (closed-world: absent means false), and code written by someone who has not noticed the switch will quietly report missing data as negation. This is the single most common bug when a database engineer first meets an ontology, and it produces answers that are confidently wrong rather than erroring out.

An axiom is a standing claim, not a data point. When you declare two classes disjoint or a property functional, you commit the whole system to that rule forever, across all present and future data. That is the source of an ontology's power and of its maintenance burden in equal measure: the reasoner will enforce the axiom everywhere, including on data added years later by people who never read it.

Challenges

Two ontologies for the same domain rarely line up. The moment there is more than one ontology for a field, someone has to align them — decide that your Customer is their Client, that your part-of matches their component-of — and this mapping is hard, partial and never finished. It is the ontology-level version of the entity-resolution problem that dominates knowledge graphs, and it is why the promise of universally mergeable data has always been softer in practice than the shared-URI story suggests.

The axioms are a governance problem, not a file. Because every axiom is a standing claim the reasoner enforces globally, an ontology is a set of assertions somebody must own and defend as the domain changes. Who is allowed to declare two classes disjoint? What happens to five years of data when that axiom turns out to be too strong? These are organisational questions, and an ontology with no governance rots the way any unmaintained shared schema rots — silently, until a reasoner reports an inconsistency nobody can explain.

Over-engineering is the common failure. Reaching for expressive OWL DL when a taxonomy or a lightweight vocabulary would have carried the actual queries is not rigour; it is a decision to pay for reasoning you do not need and, at the extreme, to choose a logic whose classification may not finish. The discipline the field learned the hard way — again, the expressiveness–tractability trade-off on Knowledge Representation — is to model in the weakest language your real questions can be stated in, which is exactly why the OWL 2 profiles exist.

Acquisition is slow and expert-bound. Formalising a domain accurately is painstaking work done by people who understand both the field and the logic, and there are never enough of them. This is the bottleneck that the current wave of tooling is aimed at, and the reason the next section is cautious rather than triumphant.

Future Trends

LLM-assisted construction moves the bottleneck rather than removing it. Language models are strikingly good at proposing classes, properties and candidate axioms from documents, which attacks the acquisition problem head-on. But a proposed axiom is a claim the reasoner will enforce on all data forever, so a wrong one is far more damaging than a wrong sentence in prose — the work shifts from authoring to verifying, and verification is precisely what has not gotten cheaper. An LLM-drafted ontology is an unreviewed ontology with good formatting, and it needs the same expert review the hand-built one did.

Ontologies as guardrails for generative systems. The neurosymbolic direction treats the ontology not as a data store but as a constraint the model's outputs are checked against: valid relationships, disjointness, cardinality limits become filters on what a generative system is allowed to assert. This is the more durable reading of "grounding" than retrieval alone — the ontology supplies the rules a fluent-but-unreliable model cannot supply for itself.

Learned and symbolic representations converging, not replacing. The lesson of the last few years is not that embeddings made ontologies obsolete; it is that the two carry opposite strengths. A vector represents similarity and tolerates messy input but cannot be inspected or corrected one assertion at a time; an ontology is inspectable and editable but blind to nuance it was never told about. The interesting systems increasingly hold both, using the ontology for the facts that must be auditable and the learned representation for everything too fuzzy to axiomatise — the trade-off laid out in full on Knowledge Representation.

Code Example

The mechanism worth seeing is inference: an axiom producing a triple nobody wrote. Here is a minimal ontology in Turtle (the standard text syntax for RDF/OWL) declaring a transitive property and three facts.

@prefix :    <http://example.org/anatomy#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

# The axiom: part-of is transitive. This is a RULE, not a fact.
:partOf rdf:type owl:TransitiveProperty .

# Three asserted facts (the data).
:Heart            :partOf :CirculatorySystem .
:CirculatorySystem :partOf :Body .
:LeftVentricle    :partOf :Heart .

Nobody has stated that the left ventricle is part of the body. But once a reasoner is given the transitivity axiom, it must derive every triple the rule implies:

Inferred by the reasoner (no one typed these):
  :Heart          :partOf :Body
  :LeftVentricle  :partOf :CirculatorySystem
  :LeftVentricle  :partOf :Body

Three asserted facts, three inferred ones, from a single one-line axiom. Delete that owl:TransitiveProperty line and the ontology collapses to a taxonomy: the same three facts sit there inert, and a query for "everything part of the body" returns only :Heart, missing the ventricle and the circulatory system entirely. That gap — between what you asserted and what logically follows from it — is the entire reason an ontology is worth building instead of a list.