What is an ontology in AI?

What is an ontology in AI?

An ontology in AI is a formal, machine-readable definition of the kinds of things that exist in a domain, the properties they have and the relationships allowed between them. It is written in a language software can process, such as the W3C’s OWL, so programs and AI agents share one meaning for each term and can derive facts that were never stated.

The classic definition comes from Tom Gruber’s 1993 paper at Stanford’s Knowledge Systems Laboratory: “An ontology is an explicit specification of a conceptualization”. Gruber notes that the term “is borrowed from philosophy, where an ontology is a systematic account of Existence” tomgruber.org.

His later encyclopedia entry gives a more concrete version. An ontology “defines a set of representational primitives with which to model a domain of knowledge or discourse,” and those primitives “are typically classes (or sets), attributes (or properties), and relationships (or relations among class members)”. Ontologies are used for “integrating heterogeneous databases, enabling interoperability among disparate systems, and specifying interfaces to independent, knowledge-based services” tomgruber.org.

The W3C standard for ontologies is OWL 2, a Recommendation since 27 October 2009, with a second edition on 11 December 2012. Its overview calls it “an ontology language for the Semantic Web with formally defined meaning”, says “OWL 2 ontologies provide classes, properties, individuals, and data values” and notes that they “are primarily exchanged as RDF documents” w3.org. An RDF graph is a set of subject-predicate-object triples w3.org. RDF Schema (RDFS) adds the basic class and property vocabulary, such as rdfs:subClassOf w3.org.

What does an ontology look like in practice?

Here is a small accounts payable ontology in Turtle, a text syntax for RDF and OWL. We wrote it; the names are illustrative and come from no standard.

@prefix ap:   <https://example.com/ap#> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

# Ontology: the kinds of things and how they may relate
ap:Party         a owl:Class .
ap:Supplier      a owl:Class ; rdfs:subClassOf ap:Party .
ap:Invoice       a owl:Class .
ap:PurchaseOrder a owl:Class .

ap:references a owl:ObjectProperty ;
    rdfs:domain ap:Invoice ;
    rdfs:range  ap:PurchaseOrder .

ap:issuedBy a owl:ObjectProperty, owl:FunctionalProperty ;
    rdfs:domain ap:Invoice ;
    rdfs:range  ap:Supplier .

# Data: one particular invoice
ap:INV-842 ap:references ap:PO-1193 ;
           ap:issuedBy   ap:AcmeCorpLtd .

The first block is the ontology and the last two lines are data. From the two together, an OWL reasoner concludes three things nobody typed in:

• INV-842 is an invoice and PO-1193 is a purchase order, because of the domain and range of ap:references. The OWL 2 Primer shows the same pattern, where a reasoner “would be able to infer that Sasha is a man and Hillary a woman” w3.org.
• AcmeCorpLtd is a supplier, from the range of ap:issuedBy, and therefore a party, through the subclass link.
• If another source says INV-842 was issued by ap:AcmeInc, the reasoner concludes that AcmeCorpLtd and AcmeInc are the same supplier, because ap:issuedBy is functional: each invoice can be linked to at most one supplier. The Primer gives the same case with husbands. If Mary’s husband is James and also Jim, “it could be inferred that Jim and James must refer to the same individual”. OWL allows this because it “does not make the assumption that different names are names for different individuals”. That suits data where “names may be coined by different organizations at different times unknowingly referring to the same individual” w3.org. Had the two names been declared different individuals, the reasoner would report the data as inconsistent instead.

The last inference is one reason enterprises want ontologies. SAP, Salesforce and a mailbox can each name one supplier differently, and an agent that sees three companies can miss a duplicate invoice.

How is an ontology different from a knowledge graph?

An ontology defines kinds of things and the rules for relating them. A knowledge graph stores particular things and the relationships between them as a graph of data, and it often uses an ontology to say what its node and edge types mean.

Aidan Hogan and colleagues’ survey in ACM Computing Surveys admits the definition “remains contentious”. It adopts an inclusive one, “a graph of data intended to accumulate and convey knowledge of the real world, whose nodes represent entities of interest and whose edges represent relations between these entities”. A simple statement such as “Santiago is the capital of Chile” can sit in the graph as one edge. A quantified statement such as “all capitals are cities” needs a more expressive formalism, and the authors give ontologies or rules as examples arxiv.org.

The OWL 2 Primer calls class and property definitions “terminological knowledge” and says an ontology “might also contain so called assertional knowledge that deals with concrete objects of the considered domain rather than general notions” w3.org. In the AP example, ap:Invoice and ap:references are terminology; INV-842 and PO-1193 are assertions.

Either can exist without the other. Hogan et al. allow any graph data model, including property graphs, so a graph’s types need not be written down as axioms. An industry ontology such as FIBO is published as definitions for others to apply to their own records. The two also change at different speeds: the ontology needs agreement from whoever owns the terms, while the data graph changes with every new invoice.

Trail’s main site covers the next step, how a context graph that records decisions relates to a knowledge graph, in its post on what a context graph is. Our comparison of knowledge graphs and vector databases covers graphs as agent memory.

Where do taxonomies, schemas and vocabularies fit?

They sit at different points on a scale of how much they let software conclude. A taxonomy arranges terms, a schema constrains how data is stored, and an ontology states facts about a domain that a reasoner can build on.

SKOS (Simple Knowledge Organization System) is “a common data model for sharing and linking knowledge organization systems via the Web”, covering “thesauri, taxonomies, classification schemes and subject heading systems”. It then adds that “SKOS is not a formal knowledge representation language”. The reason given is that “A thesaurus or classification scheme is of a completely different nature, and does not assert any axioms or facts”. SKOS can be used on its own or alongside OWL w3.org.

Gruber separates ontologies from database schemas by level. Ontologies sit at the “semantic” level, he writes, “whereas database schema are models of data at the ‘logical’ or ‘physical’ level” tomgruber.org. The OWL 2 Primer says “OWL 2 is not a database framework” and “OWL 2 is not a schema language for syntax conformance” w3.org.

Schema.org sits in between. It is a shared vocabulary of types and properties whose data model is “derived from RDF Schema”, with types “arranged in a multiple inheritance hierarchy” schema.org.

Facts in this table were checked against the sources listed at the end of this page, between Oct 20, 2026 and Oct 21, 2026.

Why does the open-world assumption matter for AI agents?

An OWL ontology will not tell an agent that something is missing. OWL treats an absent fact as unknown, a database usually treats it as false, and an agent paying invoices needs the second behaviour.

The OWL 2 Primer states the difference. If a fact is not present in a database, it “is usually considered false (the so-called closed-world assumption)”. In an OWL 2 document “it may simply be missing (but possibly true), following the open-world assumption”. Its note on functional properties says the same in another way: declaring that a person has at most one husband “does not require every individual to have a husband” w3.org.

Likewise, ap:issuedBy being functional does not require an invoice to have a supplier. To an OWL reasoner, an invoice with no purchase order is not an error: the PO may exist and simply not be recorded. A three-way match needs the opposite.

The W3C’s answer is SHACL, a Recommendation since 20 July 2017 and “a language for validating RDF graphs against a set of conditions” w3.org. A SHACL shape can require that every invoice has exactly one referenced PO and flag the ones that do not. In a relational system, a NOT NULL column or a foreign key does the same job.

Our rule of thumb from the specs is to use an ontology to agree on meaning and to infer. Validation (SHACL, database constraints or a business rule) then decides whether a record is complete enough for an agent to act on it.

Do AI agents need a formal ontology?

Some do. An agent needs a formal, standards-based ontology when it must join data across systems or organizations that name things differently, or when the definitions themselves are regulated. Inside one system with stable names, in our view, a typed list of entities and relationships is usually enough.

Finance has a public example of the formal kind. The Financial Industry Business Ontology (FIBO) is hosted by the EDM Council and also standardized by the Object Management Group. FIBO “defines the sets of things that are of interest in financial business applications and the ways that those things can relate to one another”. It “is developed as an ontology in the Web Ontology Language (OWL)”. Its maintainers say it “can give meaning to any data (e.g., spreadsheets, relational databases, XML documents) that describe the business of finance” spec.edmcouncil.org.

Agent memory tools use the word more loosely. The Graphiti README offers a “prescribed” ontology, where you “Define entity and edge types upfront via Pydantic models”, or a “learned” one, where structure emerges from the data github.com. That is a typed graph schema without OWL’s reasoning. Palantir uses the word more broadly still: its Ontology is “an operational layer for the organization” containing “semantic elements (objects, properties, links) and kinetic elements (actions, functions, dynamic security)” palantir.com. When a vendor says “ontology”, ask which of these three it means.

Either way, someone has to own the definitions, because terms like “approved vendor” are business decisions and they drift. Our guide to capturing tribal knowledge for AI agents covers getting them out of people’s heads, and the one on governing a memory layer for LLM agents covers approval and versioning.

Can large language models build or use an ontology?

They can draft parts of one and work within one. Of the two studies below, SPIRES frames its method as help for human curators, so in that setup a person still decides what goes in.

The LLMs4OL study, accepted at ISWC 2023, evaluated “nine different LLM model families for three main OL tasks: term typing, taxonomy discovery, and extraction of non-taxonomic relations” arxiv.org.

An ontology can also constrain what a model extracts. SPIRES was published in Bioinformatics in 2024 and is part of the open source OntoGPT package. It prompts a model to fill a user-defined schema from text and “uses existing ontologies and vocabularies to provide identifiers for all matched elements”. Its authors report accuracy “comparable to the mid-range of existing Relation Extraction (RE) methods”. They frame the method as “assisting manual knowledge curation” arxiv.org.

For enterprise agents that suggests a split: a model proposes entity types, edges and name matches, and the owner of each definition approves them before agents rely on them.

How Trail’s context graph resolves entities without an OWL ontology

Trail, the memory and context layer for enterprise AI agents, does not describe its product as an ontology or mention OWL, RDF or SKOS on any page we checked. Its feature walkthrough does use the word once: in the section “What Trail solves” (“Seven problems, one context layer”), step 02 is captioned “Ontology” trailhq.com. The animation maps one company’s three names in SAP, Salesforce and email to one shared entity.

The how-it-works page for its Context Graph says: “The same customer named four ways across four systems resolves to one node.” The graph is parsed from your own documents and records, with named edge types: “child_of, governed_by, supersedes, exempt_when, approved_by, proves”. Each edge is “a stated claim with the sentence it was drawn from attached”, and of each rule stored on the graph it says “Your team approves it before any agent can reach it” trailhq.com. Agents reach it through an MCP server, LangChain and LlamaIndex retrievers, or REST and GraphQL trailhq.com.

That covers the case where the same entity has different names in different systems, and it puts a person’s approval in front of every rule an agent reads. It is not the fit if you need to publish a standards-based ontology that partners or regulators consume, reuse FIBO, or run an OWL reasoner over your data. That takes OWL tooling, usually with an RDF store, and Trail’s pages describe neither. Our comparison of context graph tools for AI agents covers the wider field.

How we researched this explainer

We read the primary source for every definition: Gruber’s 1993 paper and 2009 entry, the W3C OWL 2, RDF, RDFS, SKOS and SHACL documents, the Schema.org data model, the FIBO site and Hogan et al.’s survey. For LLMs we read the LLMs4OL and SPIRES abstracts. For Trail we fetched every page in trailhq.com’s sitemap and its walkthrough script. All sources were checked on 20 October 2026. The Turtle example, the five-artifact table and the decision checklist are our own. We ran the example through the open source owlrl reasoner (OWL 2 RL), which drew all three inferences; we did not test any product. Trail publishes this page.