What Is an Ontology? From Aristotle to Enterprise AI
Every data integration failure you have ever suffered is, at bottom, a disagreement about what exists. Two systems both have a “customer” table, and the merger project discovers eighteen months in that one means “legal entity that has signed a contract” and the other means “email address that once downloaded a whitepaper”. No amount of ETL heroics fixes that, because the problem is not technical. It is ontological. This course begins here, with the 2,300-year-old discipline that gives the problem its name, because the teams that skip the philosophy keep paying for it in production.
The oldest data modelling discipline in the world
Ontology, in philosophy, is the study of what exists and how existing things relate: the science of being. Aristotle’s Categories, written in the fourth century BCE, is arguably the first data model in Western thought. He proposed that anything you can say about the world falls into one of ten categories: substance, quantity, quality, relation, place, time, position, state, action and affection. Strip away the Greek and you have a remarkably modern schema: entities, attributes, relationships, spatiotemporal context and events. Aristotle also gave us the definitional pattern that still underpins good class hierarchies: define a thing by its genus (the broader kind it belongs to) and its differentia (what distinguishes it from other members of that kind). A human is an animal (genus) that is rational (differentia). Every well-written subclass axiom you will produce in this course follows that shape.
Two further philosophical distinctions matter for practitioners. The first is universals versus particulars: the difference between the kind Pump and the individual pump P-101 on your plant floor. Confusing class and instance remains one of the most common modelling errors in industry, and it is Aristotle’s distinction wearing modern clothes. The second is identity: what makes a thing the same thing over time? When a company renames, relocates and replaces its entire board, is it the same company? Your master data management system has an opinion on this whether you articulated one or not. Lesson 3 devotes itself entirely to identity and change, because it is where naive modelling breaks first.
From philosophy to information science: Gruber and his critics
In 1993, Tom Gruber gave the word its second life. An ontology, he wrote, is “an explicit specification of a conceptualization”. Unpacked: a conceptualization is the set of concepts, relations and constraints you use to think about a domain; an ontology makes that mental model explicit, formal and shareable, so that software agents and human teams can commit to the same one. The point was never metaphysical truth. It was interoperability: if your agent and my agent commit to the same ontology, they can exchange assertions without misunderstanding.
Gruber’s definition has attracted three decades of criticism, and the criticisms are instructive. Philosophers objected that a “specification of a conceptualization” describes our ideas about the world, not the world itself, and that engineering ontologies therefore risk formalising a team’s misconceptions with great precision. The realist school associated with Barry Smith and Basic Formal Ontology (BFO, standardised as ISO/IEC 21838-2) argues that ontologies should represent reality, not concepts, and that this discipline is what makes independent ontologies interoperable at scale. Others counter that pragmatic, minimal ontologies such as gist deliver business value faster precisely because they refuse to legislate metaphysics. You will meet this argument properly in lesson 23, and you should treat it as a live engineering trade-off, not a settled question. What nobody disputes is Gruber’s core move: shared, explicit, formal semantics is the precondition for machines agreeing about meaning.
Keep the two senses of the word distinct. Ontology (singular, uncountable) is the philosophical discipline. An ontology (countable) is an engineered artifact: a set of classes, properties, definitions and axioms, usually published in OWL, that a community commits to. This course teaches you to build the second while stealing shamelessly from the first.
Why enterprises hit the wall without shared semantics
The commercial case does not rest on philosophy. It rests on what happens at scale without shared semantics. Every large organisation runs hundreds of applications, each with its own implicit conceptualization baked into table names, enum values and undocumented conventions. Integration is then pairwise translation between implicit models, and pairwise translation grows quadratically. The symptoms are familiar: reconciliation spreadsheets that exist to argue about whose “active customer” number is right; regulatory reports assembled by hand because no two systems agree on what a trade is; machine learning features engineered three times by three teams with three subtly different definitions of churn.
The LLM era sharpened the problem instead of dissolving it. A language model will happily generate fluent answers over your inconsistent data, laundering the inconsistency into confident prose. The past two years produced hard numbers showing that explicit ontologies are the working antidote. Microsoft’s OG-RAG (arXiv 2412.15235, EMNLP 2025) grounded retrieval-augmented generation in a curated domain ontology and measured 55% higher factual recall and 40% higher answer correctness across four different LLMs than standard RAG. Apple’s ODKE+ pipeline (arXiv 2509.04696) used ontology snippets to ground open-domain knowledge extraction and cut hallucinated extractions by 35%, lifting precision from 91% to 98.8%. In clinical informatics, a 2026 Journal of Biomedical Informatics study reported that an ontology-grounded RDF knowledge graph with SPARQL-mediated question answering reduced hallucinations by 61% against conventional LLM answering. These are production-shaped results with controls, not vendor decks.
| System and source | What the ontology does | Measured effect |
|---|---|---|
| OG-RAG, Microsoft (arXiv 2412.15235) | Curated domain ontology organises facts into a hypergraph that grounds retrieval | +55% factual recall, +40% correctness over standard RAG, across 4 LLMs |
| ODKE+, Apple (arXiv 2509.04696) | Ontology snippets ground large-scale knowledge extraction, with an LLM judge | Hallucinated extractions down 35%; precision 91% to 98.8% |
| Clinical KG QA (J. Biomedical Informatics, 2026) | Ontology-grounded RDF graph answers via SPARQL instead of free generation | 61% reduction in hallucinated answers vs conventional LLM use |
Institutional buyers have noticed. In 2024 the chief data officers of the US Department of Defense and the Intelligence Community formally adopted BFO and the Common Core Ontologies as baseline standards for all ontology work across their agencies: the largest institutional endorsement in the field’s history. In the UK, the National Digital Twin Programme has made the Information Exchange Standard (IES) the common ontology of its integration architecture. Demand for people who can do this work has followed; US knowledge graph engineer roles typically advertise in the 110,000 to 180,000 dollar range. This is no longer an academic niche.
What an ontology is not
Three boundary clarifications will save you months. An ontology is not a taxonomy: a taxonomy arranges terms in a hierarchy, while an ontology adds formally defined relationships, constraints and logical axioms that machines can reason over. It is not a data model for one application: a database schema serves a single system’s storage and performance needs, while an ontology specifies shared meaning across systems and outlives any one of them. And it is not a knowledge graph: the knowledge graph is the data (millions of assertions about actual customers, pumps and transactions), while the ontology is the semantic layer that says what those assertions mean and what would make them inconsistent. Lesson 2 takes these distinctions apart carefully, because they anchor the most-searched questions in this field, and because choosing the wrong artifact for your problem is the single most expensive early mistake teams make.
Worked example · the Aberdeen-2 asset register
This case runs through the whole course: one North Sea platform, three systems, and a question that should be easy.
The operator of the Aberdeen-2 platform asks a question any executive considers trivial: how many pumps do we have? Three systems answer:
- The maintenance system says 41: every maintainable unit with a work-order history, including two spares sitting in the warehouse.
- The engineering register says 44: every pump tag position on the P&ID drawings, including standby trains and one position abandoned in place in 2021.
- The contractor spreadsheet says 39: the physical units the last inspection crew could walk up to and touch.
All three numbers are correct answers to different questions, because each system embodies a different implicit conceptualisation of “pump”: a unit of maintenance responsibility, a design position, a physical object. Nothing in any of the three records which conceptualisation it uses, so no ETL job can reconcile them. That missing, explicit, shared answer to “what do we mean by pump?” is exactly the artefact this course teaches you to build.
State of the register: a question worth answering, three sources that disagree for principled reasons, and nothing explicit yet. The next lesson decides which kind of artefact fixes this.
What breaks · “one master spreadsheet will fix it”
The tempting move, and the one most Aberdeen-2 style projects actually make first, is to merge the three sources into a master list with agreed column headings. Here are two rows from that master list:
ID | Category | Rated power
HX-300 | centrifugal | 18.5 kW
P-101 | centrifugal | 18.5 kWThe rows are structurally identical, and they denote different kinds of thing. HX-300 is a pump model, a universal with hundreds of instances across the fleet; P-101 is one physical unit bolted to the deck. Column headings name attributes; they cannot state identity criteria, so the spreadsheet has no way to record the difference. Every count, join and rollup now silently mixes kinds with particulars, and “how many pumps do we have” acquires a fourth wrong answer. This is Aristotle’s universals versus particulars distinction, ignored at merge time, and it is the single most common failure in enterprise master data work.
The arc of this course
This course runs deliberately from philosophy to production. Module 1 builds the conceptual foundations: the artifact landscape, identity and time, and the logic that makes machine reasoning possible. Module 2 covers the semantic stack itself: RDF, RDFS and OWL 2, SPARQL, SHACL validation, reasoners, and the property-graph world of Neo4j and ISO GQL, treated as complementary tooling rather than a rival religion. Module 3 teaches ontology engineering method: competency questions, design patterns, OntoClean, upper ontologies including the 4D tradition used in UK government and defence, and testing with continuous integration. Modules 4 and 5 give you a standards atlas and a domain-by-domain tour from industry to life sciences to finance. Modules 6 and 7 confront the LLM era directly: GraphRAG, safe LLM-built knowledge graphs, neurosymbolic verification loops and agent memory, closing with career and capstone.
Throughout, we teach from artifacts you can inspect, not slideware. The instructor team ships its ontology work publicly, including the IES-HQDM crosswalk between the UK’s two major 4D government ontologies and the open-ontologies validation tooling on GitHub, and both will appear as worked examples in later modules. If you want to preview the standards-focused sibling course while working through this one, see the ontology foundations and semantic standards course, or browse the full ontology training collection.
One closing reframe before you move on. Aristotle asked what exists and how we should carve reality at its joints. Your data estate is an answer to that question, given accidentally, by hundreds of developers under deadline over decades. Ontology engineering is simply the decision to give the answer on purpose. The next lesson starts by sorting out the four artifacts everyone conflates: taxonomies, thesauri, ontologies and knowledge graphs.
Check yourself
The Aberdeen-2 team starts writing things down. Which ONE of these statements belongs in the ontology, as opposed to the data, a system manual, or an audit log?
- P-101’s rated power is 18.5 kW.
- Every pump has exactly one rated power, fixed by its design.
- The maintenance system stores rated power in column PWR_KW.
- P-101’s rated power value was last updated on 12 May 2026.
Show the answer, and why each wrong option is wrong
B is correct. “Every pump has exactly one rated power” is a claim about the kind Pump, true of all its instances, constraining what counts as valid data. That is an ontological commitment: it belongs in the shared semantic layer, where later in the course it becomes an axiom a machine can enforce.
A is the tempting one because it is about the domain, but it is an assertion about one particular. It is knowledge graph content, the data the ontology gives meaning to, not the ontology itself. C feels schema-like, but it describes one system’s private storage decision; shared meaning must survive the retirement of that system, so implementation detail stays out. D is provenance: a fact about a record rather than about any pump. Valuable, and modelled explicitly later in the course, but it describes the data estate, not what pumps are.
Further watching
- Your Moat Is Your Data Model, Mike Phipps, Gates Foundation, at the AI Engineer conference. The commercial version of this lesson: why the model, not the application, is the durable asset.
Recommended by Cristian Monterroza, who works on ontology-driven systems and crosswalks in production.