Platforms including Stardog, Ontotext GraphDB, Franz AllegroGraph, Atlan, and Wikidata all operate at the intersection of ontologies and knowledge graphs — and the distinction matters enormously for enterprise AI. An ontology is the formal schema: it defines what types of entities and relationships exist in a domain. A knowledge graph is the data: it records which specific entities exist and how they connect. The two are layers, not alternatives.
Ontology vs knowledge graph: a quick breakdown
Permalink to “Ontology vs knowledge graph: a quick breakdown”An ontology is a formal specification of concepts, relationships, and constraints in a domain. It defines the vocabulary and rules: what types of things exist, what properties they have, and what relationships are permitted between them. A knowledge graph is the instantiation of those concepts with real-world entities. It stores actual instances — this specific company, that actual product, the real dataset — and the relationships between them.
| Dimension | Ontology | Knowledge graph |
|---|---|---|
| Definition | Formal schema of classes, properties, and constraints | Graph of real-world entities and their relationships |
| Standard | OWL 2 (Web Ontology Language), RDFS | RDF (Resource Description Framework) |
| Layer | TBox — terminological (class-level) | ABox — assertional (instance-level) |
| Examples | FIBO, SNOMED CT, Schema.org, GoodRelations | Google Knowledge Graph, Wikidata, DBpedia |
| Query language | DL reasoning, SPARQL (schema queries) | SPARQL |
| Enables | Semantic reasoning, type inference, consistency checking | Entity linking, relationship traversal, cross-system resolution |
| AI role | Tells agents what concepts mean in this domain | Tells agents what specific entities exist and how they connect |
| In Atlan | Active Ontology Graph, Business Glossary | Enterprise Data Graph |
What is an ontology? Definition, standards, and examples
Permalink to “What is an ontology? Definition, standards, and examples”An ontology is a formal specification of concepts, relationships, and constraints in a domain. The term comes from philosophy — ontology is the study of what exists — but in computer science and data architecture, it has a precise technical meaning: a machine-readable model that defines the vocabulary and rules for a particular subject area.
What an ontology contains
Permalink to “What an ontology contains”An OWL ontology is organized around three core constructs:
- Classes — the types of things that exist. In a pharmaceutical ontology: Drug, Disease, Treatment, Patient. In a financial ontology: Asset, Liability, LegalEntity, Transaction.
- Properties — the relationships and attributes that connect or describe those classes. A Drug may “treat” a Disease. A LegalEntity may “own” an Asset.
- Axioms — constraints and rules that restrict how classes and properties may be combined. A Drug must have at least one activeIngredient. A Transaction must have exactly one currency.
The W3C’s OWL 2 Web Ontology Language is the current standard. It is built on top of RDFS (RDF Schema), which provides a lightweight class and property hierarchy. OWL 2 adds formal Description Logic semantics, enabling automated reasoners to check consistency, infer subclass relationships, and entail facts not explicitly stated.
Noy and McGuinness, in their foundational Stanford KSL guide “Ontology Development 101,” define an ontology as “a formal, explicit specification of a shared conceptualization.” Each word is load-bearing: formal (machine-readable, not natural language), explicit (no ambiguity about what is meant), shared (agreed upon by a community), and conceptualization (a model of some domain of interest).
Examples of production ontologies
Permalink to “Examples of production ontologies”Several community ontologies have reached wide adoption:
- FIBO (Financial Industry Business Ontology) — maintained by the EDM Council, used by major financial institutions to create consistent definitions of financial instruments, legal entities, and regulatory concepts across jurisdictions
- SNOMED CT — the clinical terminology standard used in healthcare systems in 80+ countries; defines diseases, procedures, drugs, and their relationships
- Schema.org — a lightweight ontology for web content semantics, maintained by Google, Microsoft, Yahoo, and Yandex; used extensively for structured data markup
- GoodRelations — an ontology for e-commerce product descriptions, now partially absorbed into Schema.org
Without an ontology, a domain model is informal: useful for human communication but not machine-executable. An enterprise ontology without a populated knowledge graph is a schema with no data — a blueprint for a building that was never constructed.
What is a knowledge graph? Definition, standards, and examples
Permalink to “What is a knowledge graph? Definition, standards, and examples”A knowledge graph is a graph-structured dataset that stores real-world entities and the relationships between them. The term was popularized when Google announced its Knowledge Graph in 2012, but the technical foundations go back to the Semantic Web work of the early 2000s.
According to Hogan et al. (2021) in their survey “Knowledge Graphs,” published in ACM Computing Surveys, a knowledge graph is “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.” The paper surveyed over 150 academic and industry knowledge graph systems and confirmed that RDF is the dominant data model.
The RDF triple structure
Permalink to “The RDF triple structure”Knowledge graphs are built from RDF (Resource Description Framework) triples, each taking the form:
<subject> <predicate> <object>
For example:
Metforminrdf:typeDrugMetformintreatsType2DiabetesType2Diabetesrdf:typeDisease
Each node and edge is identified by a URI (Uniform Resource Identifier), making it globally unambiguous and linkable across systems. SPARQL (SPARQL Protocol and RDF Query Language) is the W3C standard for querying RDF knowledge graphs — it works similarly to SQL but over graph-structured triple stores.
The key distinction from a relational database or a graph database (see our guide on knowledge graph vs graph database) is that a knowledge graph is specifically designed for semantic interoperability: entities carry shared identifiers, properties carry semantic meaning, and the graph can be federated across systems.
A knowledge graph without an ontology is a disconnected fact store. It can retrieve explicitly stated triples, but it cannot infer new facts, check type consistency, or enforce the domain rules that make the data coherent across teams and systems. For more on how these interact in the broader data stack, see our guide on combining knowledge graphs with LLMs.
WTF Is the Context Layer? — Live Series
Ontologies and knowledge graphs are the semantic foundation AI agents reason over. Join enterprise practitioners unpacking how both fit into the context layer — live sessions, real deployments.
Register for the SeriesWhat is the relationship between an ontology and a knowledge graph?
Permalink to “What is the relationship between an ontology and a knowledge graph?”The relationship is best understood through the Description Logics distinction between TBox and ABox:
- TBox (terminological box) — the ontology. It defines classes and properties at the type level. “Drug is a class. Disease is a class. treats is a property with domain Drug and range Disease.”
- ABox (assertional box) — the knowledge graph. It asserts facts about specific individuals. “Metformin is an instance of Drug. Metformin treats Type2Diabetes. Type2Diabetes is an instance of Disease.”
Together, TBox + ABox = a knowledge base in the formal sense. The ontology governs the structure; the knowledge graph provides the data.
Deborah McGuinness, a principal author of the OWL specification at W3C and AI professor at Rensselaer Polytechnic Institute, has described this relationship consistently across her work: ontologies provide the “formal conceptualization” that makes a knowledge graph semantically coherent rather than merely syntactically connected. Without the TBox, the ABox is just labeled graph data — useful for retrieval, but not for reasoning.
When a knowledge graph conforms to an OWL ontology, it gains:
- Consistency checking — a reasoner can detect logical contradictions (an entity typed as both Drug and Patient where the ontology prohibits this)
- Type inference — if MedicalProduct is a superclass of Drug, and the ontology says all MedicalProducts must have a manufacturer, then the reasoner can infer the constraint applies to Metformin even if it is not explicitly stated
- Subsumption queries — SPARQL can ask for all instances of Drug including subclasses (GenericDrug, BiologicDrug) without explicitly listing them
For enterprise data infrastructure, this matters. For a deeper comparison of how ontologies relate to context graphs specifically, see our context graph vs ontology guide.
At production enterprise scale, every reliable knowledge graph is governed by an ontology. The pairing is not accidental — it is how semantically consistent, AI-queryable knowledge graphs are built. For how this pattern applies to context-aware AI agents, the ontology layer is what makes the difference between a capable model and a trustworthy agent.
How do ontologies and knowledge graphs work together in enterprise AI?
Permalink to “How do ontologies and knowledge graphs work together in enterprise AI?”The failure mode is predictable: an enterprise builds a RAG pipeline or an AI agent, grounds it on internal data, and the agent produces confident answers that are domain-incorrect. The diagnosis, in most cases, points to the same root cause — the agent had data (a knowledge graph or vector store of documents) but lacked structured business context (an ontology that defined what the concepts in that data mean).
For a complete treatment of this failure pattern, see our guide on why AI agents fail in production.
AI agents need both layers:
- The ontology answers: what does “customer” mean in this enterprise domain? Is a “customer” the same as a “legal entity”? Can a customer also be a supplier? What properties does a customer have? What policies apply to all customers?
- The knowledge graph answers: which specific customers exist? What data assets are associated with each customer? Which systems hold customer data? Which datasets are tagged as containing PII?
Without the ontology, the agent can retrieve explicit facts — “dataset X is owned by team Y” — but it cannot reason: “dataset X contains customer data, and all customer data in this domain requires consent tracking under our AI agent governance policy, therefore the agent should flag this dataset before exposing it in a new context.”
Without the knowledge graph, the ontology is documentation. It defines “dataset” as a class with a “sensitivity” property and a “owner” relationship — but there are no dataset instances for the agent to retrieve.
According to the W3C OWL 2 Overview (McGuinness and van Harmelen, 2004), reasoners operating over a complete TBox and ABox pair can perform entailment tasks that are computationally intractable without the formal schema layer — a direct argument for why ontologies are not optional when AI agents need to reason, not just retrieve.
Atlan’s Active Ontology Graph maintains this TBox layer as a living model: it evolves as the enterprise’s systems and business context change. The Business Glossary links ontology concepts (the class-level vocabulary) to real data assets in the Enterprise Data Graph (the instance-level population). The Semantic View Generator then exposes ontology-governed metrics to AI agents via the MCP server, delivering governed context rather than raw data.
For more on how ontologies function in AI systems specifically, see our guide on ontology 101.
The AI Context Stack
Ontologies define meaning; knowledge graphs store relationships. This brief maps how both plug into the full context stack that powers enterprise AI agents.
Read the BriefWhen should you build an ontology vs a knowledge graph first?
Permalink to “When should you build an ontology vs a knowledge graph first?”The short answer: ontology-first AI architecture, but not in isolation.
The ontology is the schema that governs the structure of your knowledge graph. Building a KG without an ontology is equivalent to building a relational database without first defining a schema — possible, but it accumulates structural debt that becomes expensive to fix at scale.
What happens when enterprises skip the ontology step?
Permalink to “What happens when enterprises skip the ontology step?”The pattern is consistent: teams start with a graph database, load entities from multiple source systems, and discover six months later that "customer" in the CRM maps to "client" in the ERP and "account" in the data warehouse — and these are not just naming differences but semantic differences with different properties and different governance requirements. Without an ontology to enforce a shared definition of each concept, the knowledge graph silently accumulates entity duplication and relationship ambiguity that corrupts downstream AI outputs. This is a foundational argument for [knowledge graph for AI agents](https://atlan.com/know/ai-agent/knowledge-graph-for-ai-agents/) being schema-governed from day one.
The metadata knowledge graph guide explores this pattern specifically in the context of enterprise data assets.
What is the minimum viable ontology for a production knowledge graph?
Permalink to “What is the minimum viable ontology for a production knowledge graph?”You do not need a complete, formally verified OWL 2 ontology before populating any KG data. The practical approach is iterative:
- Domain scoping — identify the top 10-15 entity classes and 20-30 key relationships for the domain
- Ontology draft — express them in RDFS or lightweight OWL; validate with domain experts
- KG pilot — populate with 10,000-100,000 instances from one or two source systems
- Ontology refinement — gaps and mismatches surface quickly when real data hits the schema
- KG scale-out — add source systems with the schema enforced from the start
This is the pattern used by the EDM Council when deploying FIBO at financial institutions: the ontology development and KG population are parallel tracks, with the ontology always one step ahead of the data.
For a related comparison on how the semantic layer fits into this stack, see our guide on context layer vs semantic layer.
How do standards like OWL and RDF connect ontologies to knowledge graphs?
Permalink to “How do standards like OWL and RDF connect ontologies to knowledge graphs?”The W3C Semantic Web stack provides a layered set of standards that directly bridge ontologies and knowledge graphs:
| Standard | Role | Layer |
|---|---|---|
| OWL 2 | Formal ontology language (Description Logics semantics) | Ontology (TBox) |
| RDFS | Lightweight class and property hierarchy | Ontology-lite (TBox) |
| RDF | Triple data model (subject-predicate-object) | Knowledge graph (ABox) |
| SPARQL | Query language for RDF graphs | Query (both layers) |
OWL 2 is formally grounded in Description Logics, which means it has well-defined computational properties: it is decidable (queries are guaranteed to terminate), and the expressivity/tractability tradeoff is tunable by choosing an OWL 2 profile (EL for large-scale biomedical ontologies like SNOMED; RL for rule-based reasoning; QL for lightweight database-style queries).
RDF encodes the knowledge graph as triples, where each term — subject, predicate, object — is either a URI or a literal. URIs provide global identity: fibo:LegalEntity means exactly the same thing whether it appears in a bank’s internal KG or in a regulatory filing system, because the URI is globally unique and dereferenceable.
What is the role of SPARQL in querying an ontology-governed knowledge graph?
Permalink to “What is the role of SPARQL in querying an ontology-governed knowledge graph?”SPARQL queries can operate at both the ontology and instance layers. A schema-level query might retrieve all OWL classes defined in a particular namespace. An instance-level query might retrieve all datasets tagged with a particular sensitivity class — including datasets tagged with subclasses of that sensitivity class, if the SPARQL engine uses entailment reasoning over the OWL ontology.
This is the capability that distinguishes an ontology-governed knowledge graph from a plain graph database (for the technical depth on this distinction, see knowledge graph tools compared): the query engine applies the formal semantics of the ontology to return answers that include logically implied facts, not only explicitly stored triples.
Can a knowledge graph exist without an ontology?
Permalink to “Can a knowledge graph exist without an ontology?”Technically, yes. You can build a knowledge graph using typed RDF triples without a formal OWL ontology. Many early linked data projects did exactly this: they used rdf:type assertions to classify entities and rdfs:label to name properties, without defining formal axioms or constraints.
The trade-offs are significant:
- No consistency checking — there is nothing to prevent contradictory type assertions or missing required properties
- No inference — you can only retrieve what is explicitly stored; implied facts are invisible
- No shared vocabulary enforcement — the same concept can be typed differently by different teams, leading to silent entity duplication
- Limited interoperability — without a shared ontology, joining data from two knowledge graphs requires manual mapping
At the scale of production enterprise AI, these trade-offs compound. An AI agent querying a KG without an ontology is operating on a fact store without a grammar — it can find individual facts but cannot reason across concept hierarchies or enforce the domain rules that separate governed from ungoverned data. This is a key driver of AI agent hallucination in production settings.
According to the W3C’s RDF 1.1 Concepts specification, “RDF is intended for situations in which this information needs to be processed by applications, rather than being only displayed to people” — and processing by applications, in 2026, increasingly means processing by AI agents. The formal structure that OWL ontologies provide is what makes that processing semantically reliable. See our AI agent stack overview for how the ontology and knowledge graph layers fit into the full picture.
Production knowledge graphs at Google, Wikidata, financial institutions using FIBO, and healthcare systems using SNOMED all use formal ontologies. The pairing is not optional at enterprise scale.
Real stories from real customers: Ontology-driven AI at enterprise scale
Permalink to “Real stories from real customers: Ontology-driven AI at enterprise scale”"We're excited to build the future of AI governance with Atlan. All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan's MCP server…as part of Atlan's AI Labs, we're co-building the semantic layer that AI needs with new constructs, like context products."
— Joe DosSantos, VP of Enterprise Data & Analytics, Workday
"Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
— Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
CIO's Guide to Context Graphs
Getting ontology and knowledge graph architecture right is a strategic decision. This guide helps enterprise leaders build programs that deliver governed context at scale.
Get the CIO's GuideWhy enterprises that confuse ontologies with knowledge graphs build AI that fails at domain reasoning
Permalink to “Why enterprises that confuse ontologies with knowledge graphs build AI that fails at domain reasoning”The confusion has a specific and predictable failure mode: teams treat the knowledge graph as self-sufficient and skip or defer the ontology. The result is an AI agent with access to a large volume of graph data and no formal understanding of what any of it means. This is a structural LLM hallucinations problem at the context layer — not the model layer.
An AI agent querying a knowledge graph without an ontology can answer: “Which datasets are tagged with the label ‘customer’?” It cannot answer: “Which datasets contain data about legal entities that are classified as customers under our enterprise data governance policy, including entities that are also classified as partners?” The second question requires type inference, subsumption reasoning, and constraint evaluation — all of which require an ontology. See our breakdown of knowledge graphs vs RAG for why this structural difference matters for AI accuracy.
The “AI Value Chasm” — the gap between the value AI is theorized to produce and the value it actually produces in enterprise settings — is, in a significant proportion of cases, a context gap. The models are capable. The context infrastructure is not. And the context infrastructure gap, at the semantic layer, is almost always traceable to the absence of a governing ontology over the knowledge graph. This is why enterprises are investing in AI data infrastructure readiness before expanding AI agent deployments.
Workday’s experience illustrates the positive case: years of work to establish a “shared language” at the ontology level — consistent definitions of HCM concepts across every Workday module — is exactly what makes it possible to expose that semantic layer for AI agents via Atlan’s MCP server and get reliable, domain-correct outputs. The ontology was built for humans first. The knowledge graph populated with real Workday data. The AI layer was added last — and it worked, because the semantic foundation was already in place.
For enterprises evaluating Atlan’s approach to the combined ontology and knowledge graph stack, Atlan’s Active Ontology Graph maintains the evolving TBox. Its Enterprise Data Graph populates the ABox with governed data asset instances. The Business Glossary bridges the two layers: business terms (ontology concepts) link to the data assets (knowledge graph instances) that implement them. And the MCP server delivers the resulting governed context to AI agents at query time — this is the context layer for AI agents in practice.
This is the architecture that makes enterprise AI accurate at domain reasoning, not just fluent at natural language.
FAQs about ontologies and knowledge graphs
Permalink to “FAQs about ontologies and knowledge graphs”- Is an ontology the same as a knowledge graph?
No. An ontology is a formal schema that defines the types of entities and relationships that exist in a domain — the blueprint. A knowledge graph is the data instantiation — the actual entities and their real connections, built according to the ontology. In practice, many knowledge graphs use an ontology as their schema, but they are distinct artifacts with distinct roles.
- What is the relationship between ontology and knowledge graph?
An ontology defines the vocabulary and rules for a knowledge graph. The ontology says which classes of entities exist (Drug, Disease, Company) and what relationships are allowed between them (treats, owns, employs). The knowledge graph then records specific instances: Metformin is a Drug that treats Type 2 Diabetes. The ontology is the class layer; the knowledge graph is the instance layer.
- Can you have a knowledge graph without an ontology?
Technically yes — you can build a knowledge graph using typed RDF triples without a formal OWL ontology. But without an ontology, the knowledge graph lacks consistent semantic constraints and cannot support reasoning or inference. Most production enterprise knowledge graphs use at least an informal schema, and complex domains like finance (FIBO) or healthcare (SNOMED) rely on formal OWL ontologies for consistency.
- What is an example of an ontology in data management?
Common ontologies in data management include FIBO (Financial Industry Business Ontology) for finance, SNOMED CT for healthcare, GoodRelations for e-commerce product catalogs, and Schema.org for web content semantics. In enterprise data platforms, Atlan maintains an active ontology graph that defines how data assets, business terms, lineage, and policies relate to each other.
- How does Atlan use ontologies?
Atlan maintains an active ontology graph that defines the relationships between data assets, business glossary terms, lineage connections, ownership, and policies. It supports ontology import for external standards (like FIBO) and maps them to your enterprise data estate. The ontology-governed metadata forms the knowledge graph that Atlan serves to AI agents via its MCP server.
Sources
Permalink to “Sources”- W3C OWL 2 Web Ontology Language Overview, W3C Recommendation. https://www.w3.org/TR/owl2-overview/
- W3C RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation. https://www.w3.org/TR/rdf11-concepts/
- W3C SPARQL 1.1 Query Language, W3C Recommendation. https://www.w3.org/TR/sparql11-query/
- McGuinness, D. & van Harmelen, F. (2004). OWL Web Ontology Language Overview, W3C. https://www.w3.org/TR/owl-features/
- Berners-Lee, T., Hendler, J. & Lassila, O. (2001). The Semantic Web. Scientific American. https://www.scientificamerican.com/article/the-semantic-web/
- Hogan, A. et al. (2021). Knowledge Graphs. ACM Computing Surveys. https://dl.acm.org/doi/10.1145/3447772
- Noy, N. & McGuinness, D. Ontology Development 101. Stanford KSL Technical Report. https://protege.stanford.edu/publications/ontology_development/ontology101.pdf
- EDM Council. FIBO — Financial Industry Business Ontology. https://edmcouncil.org/frameworks/fibo/
- SNOMED International. SNOMED CT Overview. https://www.snomed.org/
- Wikidata. Wikidata:Introduction. https://www.wikidata.org/wiki/Wikidata:Introduction
