Most enterprise technology decisions start with data. Where is it stored? What format is it in? How do we move it from system A to system B? These are the wrong first questions. The right first question is: what does this data mean? An ontology answers that question.
What is an ontology?
An ontology is a formal, machine-readable model of a domain. It defines the types of things that exist in that domain, the properties those things can have, the relationships between them, and the rules and constraints that govern them.
In enterprise terms: an ontology is a precise definition of your business, not your data, but the meaning behind your data. It captures what a “patient” is, what a “transaction” is, how a “transaction” relates to an “account”, and what rules govern those relationships.
The word comes from philosophy, where ontology is the study of what exists. In computer science and enterprise technology, it has a specific technical meaning: a formal specification of a shared conceptualisation. That formality is what distinguishes an ontology from a glossary, a taxonomy, or an informal data dictionary.
How is an ontology different from a data model?
This is the question that matters most for enterprise architects and technology leaders.
A data model describes how data is stored. It defines tables, columns, data types, and foreign keys. It is tied to a specific database implementation and optimised for a specific query pattern.
An ontology describes what data means. It defines concepts, relationships, and rules at a level of abstraction above any single database. It is implementation-independent — the same ontology can drive a knowledge graph, a REST API, a regulatory report, and an AI agent.
This is why Palantir built their entire platform on an ontology. It is why the W3C standardised OWL (the Web Ontology Language) as the formal language for expressing ontologies on the web. And it is why organisations that invest in ontologies find that their technology becomes more adaptable, more governable, and less expensive to maintain over time.
What does an ontology contain?
An ontology is built from four types of components:
Classes represent the types of things in your domain. In a healthcare ontology, classes might include Patient, Clinician, Condition, Medication, and ClinicalEncounter. In a banking ontology: Account, Transaction, Customer, Product, and RegulatoryObligation. Classes can be organised into hierarchies: a Cardiologist is a subclass of Clinician, which is a subclass of Person.
Properties define the characteristics of classes and the relationships between them. There are two kinds: data properties (a Patient has a dateOfBirth, which is a date) and object properties (a Patient hasCondition a Condition, which links two entities). Properties can have constraints: a Patient must have exactly one dateOfBirth, but may have zero or many Conditions.
Individuals are specific instances of classes. Patient 4217, Dr Okafor, Metformin 500mg - these are individuals. In practice, individuals typically live in the knowledge graph rather than in the ontology itself; the ontology defines the template, the knowledge graph fills it with data.
Axioms are the formal rules and constraints that govern the domain. “Every ClinicalEncounter must involve exactly one Patient and at least one Clinician.” “A Medication cannot be prescribed unless it has a valid approval status.” Axioms are what make an ontology more than a diagram — they are machine-enforceable business rules.
OWL: the language of ontologies
The standard language for expressing ontologies is OWL 2 (Web Ontology Language), maintained by the W3C. OWL provides the formal vocabulary for defining classes, properties, individuals, and axioms in a way that machines can reason over.
“Reasoning” means that a machine can infer new facts from existing ones. If the ontology states that every Beneficial Owner of a Sanctioned Entity is a High-Risk Party, and that Person X is a Beneficial Owner of a Sanctioned Entity, then a reasoner can infer that Person X is a High-Risk Party, triggering compliance workflows automatically, without anyone writing that rule explicitly. This inference capability is what makes ontologies powerful at scale: as the knowledge graph grows, the reasoner discovers connections that no human explicitly encoded.
OWL ontologies are typically written in a syntax called Turtle (TTL), which is human-readable, or serialised as RDF/XML or JSON-LD for machine interchange. The choice of syntax is a serialisation detail; the semantics are identical.
Why do enterprises need ontologies?
The short answer is that enterprise data is fragmented, ambiguous, and constantly changing, and ontologies are the only technology that addresses all three problems simultaneously.
Fragmentation. Enterprise data lives across dozens of systems that were never designed to work together. An ontology provides a shared vocabulary that bridges these systems. When the CRM calls it a “client” and the ERP calls it a “customer” and the compliance system calls it an “account holder”, the ontology defines the single concept they all refer to.
Ambiguity. Natural language is imprecise. “Account” means something different in banking, in accounting, and in IT. An ontology removes this ambiguity by formally defining each concept, its properties, and its relationships, in a way that is both human-readable and machine-enforceable.
Change. Businesses change. Regulations change. Markets change. Traditional technology responds to change with expensive, time-consuming redevelopment. An ontology-driven architecture responds to change by updating or extending the shared definition, and having every downstream system adapt automatically.
Ontologies and AI
Ontologies have become critical infrastructure for enterprise AI. Large language models are trained on general-purpose text and have no understanding of your specific business domain, your data governance rules, or your regulatory obligations.
An ontology provides exactly this context. When an AI agent is governed by an ontology, it can only access the data the ontology permits, it reasons within the domain the ontology defines, and its outputs can be validated against the ontology’s rules. This is the difference between an AI that hallucinates confidently and an AI that is grounded, governed, and auditable.
Graph Research Labs builds governed AI agents using the Semantic Agent Harness: agents that reason over enterprise knowledge graphs, controlled by the ontology, with full provenance and audit trails.
How do you build an ontology?
Ontology engineering is a specialist discipline that combines domain expertise with formal knowledge representation. The process typically involves:
- Domain scoping: defining what the ontology needs to cover and what questions it needs to answer (called competency questions). Often this can lead to selecting existing publicly available ontologies such as FIBO in banking or FHIR in healthcare, which are then customised in the next steps
- Entity and relationship modelling: identifying the classes, properties, and relationships in the domain
- Formalisation: expressing the model in OWL with appropriate axioms and constraints
- Validation: testing the ontology against competency questions, running a reasoner to check consistency, and validating instance data against SHACL shapes
- Iteration: refining the ontology based on testing and stakeholder feedback
LLMs can accelerate parts of this process, particularly entity extraction and initial modelling, but they introduce well-documented anti-patterns when used without guardrails. Graph Research Labs has developed a practical methodology for AI-assisted ontology engineering that combines LLM acceleration with formal validation.
From ontology to production
The ontology is the starting point, not the end point. The real value comes when the ontology drives production systems: APIs, applications, knowledge graphs, governance layers, and AI agents.
Traditionally, this required months of integration work across multiple vendors and tools. GRL’s declarative generation engine eliminates this gap by reading the ontology and generating the entire enterprise stack automatically. Define your business once; the technology builds itself around it.