A Practitioner's Investigation
Originally published: September 2025 | Revised: March 14, 2026
Ontology is being positioned with increasing frequency as a solution to enterprise information and AI problems. The claims range from improved semantic interoperability to better reasoning over structured knowledge to more reliable AI outputs. Before adopting any framework on those grounds, the right question is: what does it actually do, and is there something that already does it better for your particular context?
That is the question this article works through. The focus is not on settling a terminology debate. It is on understanding what a computer science ontology gives a practitioner that rigorous conceptual modeling does not, where the two actually differ, and where a third approach, enterprise ontology as defined by Jan Dietz, changes the question entirely.
Object-Role Modeling (ORM) is a fact-based approach to conceptual modeling developed primarily by Terry Halpin. It represents knowledge through facts, the roles objects play in those facts, and formal constraints on what combinations of facts are permitted. Every fact type has a natural-language verbalization that domain experts can read and validate. Every constraint is formal and checkable. The model is independent of any particular implementation, meaning it describes what is true about a domain without prescribing how that truth should be stored or processed.
These properties matter because they are often attributed as distinctive advantages of ontologies without acknowledging that a well-built ORM model already has them. ORM models are formal. They are explicit. They capture shared conceptualizations verified with domain experts. They support reasoning in the sense that constraints can be checked and violations detected at the modeling stage rather than discovered at runtime. A good ORM tool does this interactively as the model is built. Readers looking for the broader distinction between knowledge, information, and formal semantic structure should also see What I Mean by Knowledge, Information, and Semantics.
The expressiveness of ORM is also underestimated by most practitioners who have not worked with it. ORM handles n-ary relationships, ring constraints, subset and equality constraints, derivation rules, and subtyping, all within a notation that maps directly to natural language and can be populated with concrete examples for validation. This is not a lightweight sketching tool. It is a rigorous modeling language with formal foundations in predicate logic.
Halpin and Dietz collaborated directly on a case study published in 2004, titled "Using DEMO and ORM in Concert," which demonstrated how ORM can be used to formalize the results of a DEMO analysis. That connection is not incidental. It reflects the fact that ORM is expressive enough to capture the kind of precise, constraint-rich models that genuine ontological work requires.
The practical implication is that before asking whether you need an ontology, ask whether a rigorous ORM-based conceptual schema would already solve the problem. In many enterprise contexts, it will.
The computer science ontology tradition does offer something that a closed-world conceptual schema does not, but the scope of that something is narrower than is often claimed.
The genuine distinction is the open world assumption. A conceptual schema under the closed world assumption treats any fact not explicitly recorded as false. An OWL ontology under the open world assumption treats any fact not recorded as simply unknown, potentially true but not yet asserted. For most enterprise modeling this distinction is either irrelevant or actively unhelpful, because enterprise systems need to know what they know and enforce it. C.J. Date addresses this directly in his work on logic and relational theory, making the case that the closed world assumption is not a limitation but a design choice that reflects what most information systems are actually doing.
Where the open world assumption earns its keep is in decentralized, multi-contributor knowledge environments. Biological databases where research groups around the world are contributing facts about genes, proteins, and organisms. Academic linked data where institutions are asserting relationships without central coordination. Scientific nomenclature where new species or compounds are being named and classified continuously. In those contexts, the ability to say we do not know everything, and new facts can arrive from any source, is useful. The Semantic Web stack, RDF, OWL, and related standards, was designed for exactly this problem.
That is a specific use case, and an important one. Most enterprise modeling problems do not look like this, and importing the open world assumption into a context that does not need it adds complexity without adding value.
Jan Dietz is a Dutch systems theorist and the creator of DEMO, the Design and Engineering Methodology for Organizations. His use of the word ontology is doing something different from what either the philosophical tradition or the computer science tradition typically means by it.
Dietz's Enterprise Ontology is not a model of how an organization describes itself or a formal vocabulary for talking about organizational concepts. It is a theory of what an organization actually is. The core claim is that all organizational work can be understood through a small set of fundamental transaction types in which actors make commitments to produce results. This is not presented as a useful framework or a convenient abstraction. It is presented as a claim about the essential nature of organizations that either holds or it does not. For a business-facing application of that line of thought, see Enterprise Ontology for AI Reinvention.
DEMO distinguishes between three organizations within any enterprise: the O-organization (original), which is where the actual work and coordination between actors takes place; the I-organization (informational), which records and communicates the facts that result from that work; and the D-organization (documental), which handles the documents and forms that support the informational layer. These are not modeling layers or architectural tiers. They are a claim about what is actually happening in any enterprise, regardless of how that enterprise chooses to describe itself.
This is why Dietz's definition of ontology is more satisfying than Gruber's or the extensions built on it. Gruber's definition, "a specification of a conceptualization," and the various extensions proposed since, describe what an ontology looks like rather than what it claims. They are structural definitions. A sufficiently expressive and formal ORM schema would satisfy most of them. Dietz's enterprise ontology is distinguished not by its structure but by its intent: it is making a claim about organizational reality, not making representational choices for an application.
A peer-reviewed study by Feilmayr and Wöß, published in Data and Knowledge Engineering, found that the term ontology is used with different and sometimes incompatible meanings across research communities, that misuse in research and business is common, and that most systems calling themselves ontology-based do little more than classify knowledge into convenient categories. That last finding is pointed. If most systems that claim to be ontology-based are really just classification systems, the gap between the claim and the practice is large enough to matter.
When ORM is used in conjunction with DEMO, it takes on a different character. The ORM model is no longer making representational choices for a specific application. It is formalizing a prior theoretical account of what the enterprise is and how it works. The ontological weight comes from Dietz's theory. ORM provides the language for expressing it with precision and constraint. That combination does something neither tool achieves alone, and it does so for organizations that want to understand their own essential structure before they start building systems on top of it.
I am not claiming Dietz's definition is the only valid use of the word ontology in computer science. There are researchers in the formal ontology tradition, Nicola Guarino and C. Maria Keet among them, who have done careful and serious work in a different direction. I am saying that for enterprise modeling purposes, Dietz's notion of what an ontology is and what it is for is the most rigorous and the most honest about what it is actually claiming. That is where I have chosen to anchor my own work.
The practical question, when someone proposes that an ontology is the solution to an enterprise information or AI problem, is what specific work the ontology is supposed to do that something else cannot.
If the problem is capturing the facts, rules, and constraints of a business domain with enough precision to support shared understanding, implementation-independent design, and formal verification, a rigorous ORM-based conceptual schema is likely the right tool. It is more expressive than most practitioners realize, it is grounded in natural language that domain experts can validate, and it does not require importing assumptions about open worlds or decentralized knowledge that most enterprise contexts do not need.
If the problem is understanding what an organization fundamentally does before anyone starts building systems, DEMO is the prior step. It does not compete with ORM or with the Semantic Web tradition. It addresses a different question: not how to represent organizational knowledge, but what an organization actually is. Answering that question first changes what gets built and why. The same distinction becomes operational in governance-oriented system design, where explicit commitments, authority, and accountable action matter; see Intent-Driven AI Delegates for the architectural implications.
If the problem genuinely involves decentralized knowledge integration across institutional boundaries, where contributors are distributed, facts arrive incrementally, and no single authority controls the schema, then the Semantic Web tradition offers something the others do not. RDF and OWL were designed for that problem. They are the right tools for it.
Most enterprise problems fall into the first or second category. Knowing which one you have before reaching for a technology is the work. An ontology is not a universal upgrade from a conceptual schema. In some contexts it is the right answer. In others it adds complexity without adding value, and in a few it imports assumptions that actively work against what the system needs to do.
© 2025-2026 G. Sawatzky. Licensed under CC BY-NC-ND 4.0.