Ontology definition
An ontology is a formal, machine-readable model of a subject area that defines the types of things in it, the properties those things can have, and the relationships between them. Unlike a simple vocabulary or list of terms, an ontology encodes rules that let software infer facts that were never written down explicitly.
An ontology is a formal description of what exists in a domain: the classes of things, their attributes, and how they relate, written so that both people and machines can reason over it. A product catalog ontology might state that every Sneaker is a Shoe, every Shoe has a Size, and every Shoe is made by a Brand. In Sanity, the same instinct shows up in the schema: document types, fields, and references define the entities and relationships once, so every application reads the same model rather than inventing its own.
An ontology is a map of the concepts in a subject area and the rules connecting them. Think of how a library describes its holdings. A taxonomy would sort books into nested categories: fiction, then mystery, then Nordic noir. An ontology goes further by saying that a Book has an Author, that an Author is a Person, that a Person has a birthplace, and that a Translation is derived from an original Work. Once those statements exist in a form software can read, a system can answer "show me mystery novels translated from Norwegian" without anyone tagging each book that way by hand.
The word comes from philosophy, where ontology is the study of what exists. Computer science borrowed it in the 1990s for a narrower, practical purpose. The definition most often cited is Tom Gruber's: an ontology is "a specification of a conceptualization," published in Knowledge Acquisition in 1993. In plain language, it is an agreement, written down precisely, about what the words in a domain mean and how the things they name fit together.
An ontology is built from four kinds of building block, and knowing them makes any ontology easier to read.
Classes are the types of thing that exist, such as Person, Product, or Article. Instances (sometimes called individuals) are the actual members of those classes: Ada Lovelace is an instance of Person. Properties describe classes, either as simple attributes (a Person has a date of birth) or as relationships to other classes (a Person authored an Article). Axioms are the rules and constraints: every Article has exactly one primary author, a Person cannot also be an Organization, and anything that is a Sneaker is automatically a Shoe.
Axioms are what separate an ontology from a glossary or a tag list. Because the rules are formal, a piece of software called a reasoner can apply them and derive new facts. If the ontology says Sneaker is a subclass of Shoe and Shoe is a subclass of Footwear, a reasoner knows that a specific pair of sneakers is footwear even though nobody ever recorded that fact.
An ontology, a taxonomy, and a knowledge graph describe three different layers of the same stack, and the terms get used interchangeably far more often than they should be.
A taxonomy is a hierarchy: terms arranged in broader and narrower relationships, like a category tree in an online store. It answers "what is this a kind of?" and little else. An ontology adds non-hierarchical relationships and formal rules, so it can also answer "who made this, what is it compatible with, and what follows logically from that?" A knowledge graph is the populated result: real entities and real relationships, stored as a graph, usually structured according to an ontology. Put simply, the taxonomy classifies, the ontology defines, and the knowledge graph holds the actual data.
A useful test: if your model has only parent and child links, it is a taxonomy. If it has typed relationships between different classes plus constraints on those relationships, it is an ontology. If it contains millions of specific facts about named things, it is a knowledge graph.
Building an ontology follows a repeatable sequence, and most published methodologies describe some version of these six steps.
First, define the scope by writing competency questions, which are the specific questions the finished ontology must be able to answer, such as "which products are compatible with this model?" Second, reuse an existing ontology where one fits, since standards like Schema.org for web content, FOAF for people and social connections, or the Gene Ontology for biology already cover common ground. Third, enumerate the important terms in the domain without worrying yet about structure. Fourth, organize those terms into classes and a class hierarchy. Fifth, define the properties: the attributes of each class and the relationships between classes. Sixth, add axioms and constraints, then test the result against the competency questions from step one.
The classic practical guide to this process is Natalya Noy and Deborah McGuinness's Ontology Development 101, published by Stanford in 2001 and still widely assigned. Ontologies are usually written in standard languages such as RDF Schema or OWL (the Web Ontology Language), both maintained as W3C standards.
Ontologies matter for AI and search because they give a machine explicit, checkable facts about a domain instead of leaving it to infer everything from patterns in text. A large language model learns statistical associations, which is powerful for language and unreliable for specifics like which SKU replaced which, or which policy applies in which country. An ontology states those relationships outright, so a system can retrieve them and cite them.
This is the idea behind grounding retrieval in a knowledge graph rather than in loose documents alone. When an assistant answers "what accessories fit this camera body?", a graph built on an ontology can traverse a compatible-with relationship and return a verifiable list, where a text search can only return pages that happen to mention both things. Search engines use the same mechanism: Schema.org markup is essentially a shared lightweight ontology that tells crawlers a page describes a Recipe with a cookTime rather than a blob of prose.
For teams whose domain knowledge lives in content rather than in a database, the practical path to this is modeling the content itself. Sanity works as a Content Operating System for the AI era: document types define the classes, fields define the properties, and references define the typed relationships between them, so the content repository already carries the structure that downstream retrieval, search, and AI systems need to reason over.
Discover More with Sanity
Now that you've learned about ontology, why not start exploring what Sanity has to offer? Dive into our platform and see how it can support your content needs.
Last updated: