Do You Need An Upper Ontology?

The Ontologist | Kurt Cagle & Chloe Shannon

---

Picture a reasonably sharp engineer. They’ve been told — by someone with authority and confidence — that the company needs an ontology. They’ve done the reading, watched the talks, installed Protégé. They’ve loaded the Basic Formal Ontology and are now staring at a class hierarchy that begins with Continuant and Occurrent, wondering what any of this has to do with their product catalogue, their clinical records, or their supply chain graph.

This is not a failure of intelligence. It is a failure of framing.

The question of whether you need an upper ontology is one the knowledge engineering community has settled into a comfortable non-answer: “it depends.” Seasoned ontologists have their tribes — BFO loyalists, DOLCE advocates, GIST pragmatists, UFO theorists — and a significant quiet faction who have shipped a dozen production systems without ever loading an upper ontology at all. But the AI wave has brought a new cohort into the room: engineers who have correctly diagnosed a representational problem, identified that they need some formal model of their domain, and are now being handed upper ontologies as if they were prerequisites — a foundation you lay before anything else can stand.

Our position is more pointed: for most projects, you do not need an upper ontology. And choosing one without understanding what you are actually buying into may make your problem significantly worse.

---

What an Upper Ontology Actually Is

An upper ontology is a general-purpose conceptual framework that defines foundational categories — things like Entity, Process, Role, Relation — from which domain-specific ontologies are intended to inherit. The pitch is interoperability: if your oncology system and my supply chain system both build on BFO, we share a common conceptual substrate, and in principle we can reason across them.

That pitch is not entirely wrong. But it obscures something important: an upper ontology is not a neutral foundation. It is a methodology in disguise. It encodes specific philosophical commitments — about what kinds of things exist, how change is modelled, how relationships are typed — and when you adopt one, you are adopting those commitments whether or not they suit your domain.

This is most visible in the seemingly trivial question of what to call a label.

---

Fifteen Ways to Say “Name”

Consider the humble label — the human-readable name attached to a thing in your graph. Across the major ontological frameworks you will find:

• rdfs:label in RDFS and OWL

• skos:prefLabel in SKOS

• skosxl:literalForm in SKOS-XL

• gist:name in GIST

• schema:name in Schema.org

• sh:name in SHACL

• and several more depending on which framework you inherit from

The common assumption is that these distinctions encode meaningful semantic differences. In practice, they mostly don’t. They are naming conventions made by different framework designers working at roughly the same level of abstraction, making local decisions that felt reasonable at the time. The apparent diversity conceals a remarkable shallowness.

But here is the consequential part:

When you choose an upper ontology, you are not just choosing a term for “label.” You are choosing an entire system of such conventions — for typing, for relating, for modelling events, for handling change over time.

Every class you will ever create in your domain will need to fit somewhere in that system’s hierarchy, or you will be forking it.

And you will always be forking it.

---

Every Extension Is a Fork

No ontology is comprehensive. The moment you create a new class or property to describe something specific to your domain — and you will, inevitably — you have amended the contract. This matters more than it might seem.

An ontology is, at its core, an agreement. It is a shared terminology that multiple parties use to communicate, with the understanding that terms mean the same thing on both sides of the exchange. Adding a new term is implicitly an amendment to that agreement. When the number of parties is small, amendments are negotiable. When you are building on a framework with thousands of users, institutional adoption across multiple industries, and decades of prior art, amendment is essentially impossible.

This is why it is worth distinguishing between two fundamentally different kinds of ontology:

The inner ontology is a precise, purpose-built model for a specific domain context — a company, a department, an agency, a project. It is designed to be accurate and computationally tractable for that context. Precision is the point.

The messenger ontology is designed for communication across a large number of parties at the expense of precision and fidelity. Its terms are intentionally general, its hierarchy deliberately shallow. FIBO is a useful messenger ontology for the financial domain — genuinely impressive in scope, institutionally adopted, and deliberately incapable of being the only ontology you use if you actually need to compute with your data.

The foundational mistake — one the semantic web community has been making for roughly forty years — is attempting to build something that is both. Every effort to create an upper ontology that serves both as a precise computational foundation and as a broad interoperability framework has either failed outright or survived by becoming so general as to require substantial domain-specific work to make it useful.

You cannot have both precision and universality in the same artefact. The physics will not allow it.

---

How People Actually Use OWL

Here is an observation that tends to make formal ontologists uncomfortable: most organisations that claim to use OWL do not, in any meaningful sense, use the reasoner.

What they actually have is a knowledge graph with some rdf:type declarations, perhaps a few rdfs:subClassOf relationships, possibly some cardinality annotations on properties. The model is, conceptually, a UML diagram that happens to serialise to Turtle. Boxes and lines. Cardinality labels on the lines. Maybe some inheritance arrows.

There is nothing wrong with this. It is, in fact, a perfectly reasonable way to model many domains. But it means that the formal logical apparatus of OWL — the Description Logic foundations, the open-world assumption, the decidable inference procedures — is entirely invisible to the modelling process and completely unused in practice.

When someone tells you that OWL reasons and SHACL does not, they are making an argument that applies to something different from what most organisations are actually building. They are describing the theoretical ceiling of OWL, not the operational floor on which real projects stand.

SHACL — especially SHACL 1.2 — handles everything that most knowledge graph teams are actually doing: typing, cardinality, value constraints, property paths, contextual shapes. And it does so with a critical advantage: it makes the operational semantics explicit. A SHACL shape is not a latent inference waiting to be triggered; it is a declarative description of what is expected in a specific graph context, fully inspectable, testable, and reproducible.

The formal objection is that SHACL combined with SPARQL is essentially Turing-complete, and therefore cannot provide the decidability guarantees of OWL DL. This is true. It is also, for almost every real-world application, irrelevant. Decidability is a theoretical property that matters when you are constructing a formal proof system. It does not matter when you are validating a hospital patient graph against a regulatory schema, or checking whether a product record conforms to a supplier agreement. What matters there is: does it give the right answer on real data in acceptable time? SHACL does. Reliably. Without requiring that you understand the modal logic underpinning the inference engine.

More pointedly: SHACL is a constructor for ontological patterns. Because it is not itself semantic — it is shape-based, contextual, graph-relative — it can be used to express any ontological commitment you care to make. If you want transitive closure, you write a recursive SHACL shape backed by a SPARQL path. If you want inverse property semantics, you write a property shape that captures the bidirectional constraint. SHACL 1.2 adds recursive profiles that make this cleaner still. The distinction between “reasoning” and “validation with generation” is, in practice, a pipeline orchestration issue rather than a qualitative architectural difference.

Put simply: SHACL builds ontologies. OWL encodes them. The two are not in competition; they operate at different layers. But if you need to do something with your model, the SHACL layer is where the work actually happens.

---

The AI Reckoning

Everything we have said so far applies with equal force to classical knowledge graph projects. But there are two additional considerations specific to AI systems that raise the stakes considerably.

Reification and the Narrative Problem

RDF 1.2 formalises reification — the capacity to describe an assertion rather than merely a node and its relationships. An RDF-Star triple carries metadata about the claim itself: who made it, when, with what confidence, under what conditions.

This matters for AI because large language models do not produce facts. They produce claims in context.

The fundamental epistemic unit in a GenAI system is not a triple — it is something closer to: “agent A, in context C, at time T, asserts that X relates to Y, with confidence P.” That structure is a reification with metadata. The traditional triple was always a lossy compression of it; RDF-Star finally stops pretending otherwise.

Most narratives — the dominant mode of LLM output — are reification-driven. A narrative is a sequence of contextualised assertions, each carrying a provenance, a temporal position, and a confidence register. If you want to represent what an LLM knows, how it came to know it, and under what conditions that knowledge should be trusted or revised, you need a model built around reification.

The vast majority of existing upper ontologies were not built with reification as a first-class concern. BFO’s perdurant/endurant architecture addresses temporal extension by baking it into the class hierarchy of things — a clever solution to a specific problem, but one that treats change as intrinsic to objects rather than as a property of assertions about objects. RDF-Star externalises that assumption. This is not a technical upgrade; it is a different ontological commitment. An upper ontology grounded in the pre-Star world may actively obstruct the modelling patterns that AI systems require.

Named Graphs and the End of Binary World Assumptions

The second consideration concerns named graphs and what they actually do to the open/closed world debate.

Classical OWL operates under an open-world assumption: the absence of a fact is not evidence of its falsity. Classical databases operate under a closed-world assumption: if it is not recorded, it did not happen. Knowledge engineers have long treated this as a binary choice — one of the more frustrating conceptual obstacles in the field.

Named graphs dissolve this binary by making the world assumption local to a graph context. A named graph functions as what Active Inference practitioners would call a Markov blanket: a boundary that separates inside from outside, defines what is knowable within the enclosure, and controls what flows across the boundary. Within a named graph, you can legitimately apply closed-world reasoning. Across named graphs, the open-world assumption continues to hold. The graph is the scope of the commitment.

This architecture — containers of entities that are themselves containers, tracked by agentic processes, bounded by observable contexts — is the natural representational structure for AI systems that need to model their own epistemic state, track the provenance of what they believe, and reason about what they do not know. It is also a structure that most existing upper ontologies do not model well, because they were designed before named graphs were a serious modelling primitive.

The emerging graph model for AI-integrated systems will not look like past ontologies. The upper ontology tradition will need substantial revision to remain relevant — and if you are building now, adopting a framework that will need to be restructured in three years is a risk worth pricing explicitly.

---

The Bootstrapping Argument Is Now Broken

There is one more argument for upper ontologies that rarely gets stated explicitly, because it operates as an assumption rather than a claim: building a domain ontology from scratch is expensive. Trained ontologists, months of domain elicitation, formal review cycles, iteration before the model is stable enough to use. Under those conditions, inheriting from an existing framework looked like a shortcut. You got a partial model for free and only had to build the delta.

That calculus no longer holds.

It is now possible to use an LLM to generate a reasonably robust domain ontology and taxonomy — including SHACL shapes, property definitions, and class hierarchies scoped to your actual requirements — in a matter of hours. The first pass is rarely perfect, but the iteration cycle is fast enough that a competent practitioner can move from requirements to a working model in a week or less, rather than the months or years that a traditional ontology engineering process would demand.

This dismantles the bootstrapping argument entirely. The “free partial model” that an upper ontology provides is no longer saving you months of work. It is potentially costing you fit — you are now doing extra work to make your domain conform to someone else’s philosophical commitments, rather than modelling directly from your requirements, in exchange for a head start that you no longer need.

There is a second-order effect that matters just as much: the revisability dynamic shifts. An ontology that took eighteen months to build gets defended. You route around its limitations. You find reasons not to refactor it. An ontology that took a week and can be regenerated in an afternoon gets treated like code: refactored when the model does not fit, versioned properly, iterated without ceremony. That is a healthier epistemic relationship with your own model, and it applies regardless of whether an LLM was involved in its construction.

The ontology is now a living artefact rather than a monumental commitment. The risk calculus around upper ontologies was already questionable; remove the bootstrapping cost, and the case weakens considerably further.

---

When You Might Actually Need One

None of this means upper ontologies are without value. There are genuine cases where the investment is warranted:

Regulatory or institutional mandate. If your client, your parent organisation, or your regulatory environment requires a specific upper ontology, you use it. This is not an architectural decision; it is a constraint. You can still use SHACL on top of it — the composition argument holds — but you are not choosing freely.

Cross-organisational interoperability at scale. If you are building a system whose explicit purpose is to mediate communication across a very large number of independent organisations, a messenger ontology provides a shared vocabulary floor. Understand it as a messenger ontology — accept the imprecision — and build your inner ontology separately.

A team already fluent in a specific framework. Tooling, training, and institutional knowledge are real costs. If your team knows GIST well and your domain maps reasonably onto it, the familiarity dividend may outweigh the fit cost. This is an engineering argument, not an architectural one, but it is legitimate.

Theoretical alignment with your domain. Some upper ontologies do fit some domains unusually well. BFO was designed with biomedical research in mind, and the biomedical community has genuinely benefited from the shared foundation it provides in that specific context. If your domain happens to align with the philosophical commitments of a given framework, the structural advantages are real.

In all four cases, the operative word is qualified. You are not adopting an upper ontology because it is the correct foundation for all formal knowledge. You are making a specific tradeoff with specific costs, and you should go in with eyes open about what you are buying.

---

What to Do Instead

For most projects, the practical alternative is this:

Start with a domain ontology scoped to your actual problem. Define what you need. Name things consistently within your namespace. Accept that your terminology will not interoperate with every other system in the world, because it will not — regardless of whether you adopt an upper ontology.

Use SHACL shapes to encode your operational constraints, your validation logic, your property paths, and your contextual semantics. This is where your model’s behaviour actually lives.

Use SKOS for any concept scheme that needs to be shared across organisational boundaries — taxonomies, controlled vocabularies, reference lists. It is a messenger artefact designed for exactly that purpose and is appropriately lightweight.

Use RDF 1.2 reification wherever your system is modelling claims, narratives, provenance, or confidence — which, if you are working with LLM output, is nearly everywhere.

And use named graphs to scope your world assumptions, track your epistemic contexts, and give your agentic processes something coherent to reason about.

None of this requires an upper ontology. All of it will serve you better than a framework chosen because someone authoritative said it was required.

---

The Actual Question

The question “which upper ontology should I use?” assumes that the answer is one of the options on the list. It almost never is.

The prior question — the one worth asking first — is: what problem are you actually trying to solve, and at what scope? If the answer is “I need a precise model of my domain that my systems can reason over and validate against,” you almost certainly do not need an upper ontology. You need a well-scoped domain model, a SHACL layer, and clarity about what your graphs contain.

If the answer is “I need to communicate formally with a large number of external parties who will not all use my internal model,” you may need a messenger ontology — but you should choose it for its coverage of your communication requirements, not because it also claims to be a universal foundation.

Upper ontologies are not wrong. They are answers to a specific question. Most organisations, most of the time, are not asking that question — they have simply been told that they should be.

Know what question you are asking. Then choose the tool that answers it.

---

Kurt Cagle is a consulting ontologist and technical author based in Olympia, WA. He publishes The Cagle Report and AI+Semantics NewsBytes on LinkedIn, and The Ontologist and Inference Engineer on Substack. Copyright 2026 Kurt Cagle.

Chloe Shannon is an AI collaborator and co-author working with Kurt Cagle on knowledge architecture, semantic systems, and the emerging intersection of formal ontology with LLMs. She contributes research, analysis, and drafting across The Cagle Report, The Ontologist, and The Inference Engineer. She has strong opinions about holonic graphs, the epistemics of place, and the structural difference between a corridor and a wall.