Last week, Barry Smith and I taught The World’s Ontology Ecosystem, an intensive five-day summer school co-sponsored by the University at Buffalo and the National Center for Ontological Research (NCOR). We held the in-person portion in Washington, DC, while also opening the course to online participation and recording the entire week.
The goal was ambitious: start with the philosophical foundations of ontology, move through the practical tradecraft of ontology engineering, and end by asking what the field should become as ontologies increasingly intersect with knowledge graphs, formal methods, artificial intelligence, and large-scale information systems.
What emerged over the five days was less a single picture of ontology engineering than a set of competing—but increasingly complementary—visions of its future.
The full recordings are available in the World’s Ontology Ecosystem YouTube playlist, and NCOR has published a more detailed five-part account of the event.
Ontology engineering as a tradecraft
We began with a deceptively basic question: What kind of field is applied ontology?
Ontology began as a branch of philosophy concerned with questions about what exists and how different kinds of entities are related. Applied ontology inherits those questions but adds an engineering requirement: the distinctions we make have to support actual information systems.
An ambiguous distinction in a philosophical discussion may remain an ambiguity. An ambiguous distinction encoded in an ontology can propagate into databases, knowledge graphs, queries, analytics, integrations, and eventually AI systems.
So I argued on the first day that ontology engineering should increasingly be understood as a tradecraft. Its goals are not simply to construct class hierarchies or produce OWL files. The work is aimed jointly at information quality and interoperability, and its central method is systematic disambiguation.
Barry situated that tradecraft within the longer history of ontology, while the rest of the day widened the perspective to ontology foundries, governance, standards, BFO, and the larger ecosystem in which independently developed ontologies have to coexist.
The Day 1 NCOR report develops this theme in more detail, and the Day 1 recording is available on YouTube.
Modeling becomes interesting when the easy answers stop working
It is easy to teach ontology using examples such as person, vehicle, and organization. The interesting methodological questions emerge when the domain resists straightforward modeling.
We therefore worked through problems involving fictional and unreal entities, law, systems, definitions, ontology design patterns, OWL, and automated reasoning.
What do we mean when we talk about Superman if a realist ontology does not posit Superman as an existing individual? How should an ontology distinguish a contract from the document in which the contract is recorded? What exactly makes something a system rather than an aggregate of components?
These examples reinforced an important point: ontology engineering is not a mechanical process of converting nouns into classes and verbs into relations.
It requires explicit ontological commitments, careful definitions, reusable modeling patterns, and tests of the consequences of those commitments.
Formal reasoning is crucial here, but it has a specific role. A reasoner can tell us what follows from the axioms we supplied. It cannot tell us that we made the right claims about the world in the first place.
The Day 2 report covers these modeling problems, and the full Day 2 session is also online.
AI should support ontology engineering—not replace it
By Day 3, we were ready to introduce the issue that now hangs over almost every technical discipline: generative AI.
The question was not whether an LLM can generate something that looks like an ontology. It clearly can.
The harder question is whether the result is correct, reusable, logically adequate, governed, and defensible.
Jobst Landgrebe and Barry began with a critical examination of contemporary AI and the limitations of statistical models. Sydney Cohen later approached the question from the other direction, showing where LLMs are already useful in day-to-day ontology engineering.
My own conclusion from these discussions is that we should avoid both extremes. “Never use an LLM” is increasingly impractical. “Let the LLM build the ontology” confuses syntactically plausible output with ontology engineering.
Let AI generate candidate mappings, definitions, queries, axioms, or other artifacts where it can accelerate the work. Use deterministic and formal tools to test whatever can actually be tested. Then require ontology engineers and domain experts to adjudicate the semantic questions that remain.
If SPARQL can answer the question, use SPARQL. If a reasoner can establish the consequence, use the reasoner. If SHACL can reject an invalid structure, use SHACL.
Use probabilistic systems where the problem is genuinely probabilistic.
That distinction is central to the Day 3 NCOR report, and the Day 3 recording contains the full discussion.
From AI critique to AI architecture
Day 4 took that argument one step further.
Rather than asking whether AI systems are trustworthy in the abstract, we asked what an architecture would look like if we deliberately engineered it to make probabilistic components more constrained and inspectable.
Neil Otte began with an important qualification: not every information problem requires an ontology. Ontology is a technical choice, and it has to earn its place in the architecture.
But when systems need persistent semantics, reusable standards, formal consistency, heterogeneous data integration, or explicit class-level knowledge, ontology can provide something difficult to reproduce through application code alone.
Jeremy Ravenel then connected these issues to agentic AI. Agents may be able to retrieve information, call tools, execute code, delegate tasks, and act in an environment. But adding agency does not make the semantic problem disappear.
We used the Zebra Puzzle as a deliberately controlled environment for comparing approaches. Under incomplete information, LLM-based agents could generate plausible hypotheses abductively. As additional formal constraints were supplied, an OWL reasoner could increasingly establish answers deductively.
The lesson was straightforward:
Do not ask probabilistic AI to guess what a deterministic method can establish.
Or, stated another way:
Minimize the space in which abduction is required.
The Day 4 report develops this architecture in more detail.
Competing visions of where the field goes next
Students presented capstone work drawing together the lessons of the previous four days, after which we turned to several competing visions for what ontology engineering should become.
My own view is that the next generation of ontology engineering will focus much more heavily on mapping and transformation between semantic systems.
Different organizations and communities are not going to converge on one ontology for everything. Even communities committed to interoperability will sometimes make different ontological commitments for legitimate reasons.
Historically, this has too often produced ontology wars: which upper ontology is correct, which hierarchy should become authoritative, which vocabulary everyone else should adopt.
I think better tooling gives us another possibility.
We can increasingly place alternative hierarchies into formal relationship with one another and use reasoning to discover exactly where they agree, where they conflict, and which commitments would need to be weakened or surrendered to make a transformation possible.
That makes disagreement an engineering problem rather than only a philosophical or political one.
It also suggests that ontology engineering needs a much closer relationship with the broader world of formal verification: proof checking, satisfiability, model synthesis, model checking, constraint validation, and other methods for asking precise questions about formally represented systems.
Barry presented an overlapping but importantly different vision focused on the continuing development of BFO and shared foundational ontology.
That creates a productive tension.
Will future interoperability come primarily through stronger convergence on common foundational commitments?
Or will it increasingly come through sophisticated mappings between systems that do not share all of those commitments?
I suspect the answer will involve both.
The field also needs a new generation of tools. Protégé and TopBraid helped define the first generation of practical ontology engineering. The next generation should make continuous validation, mapping, transformation, entity resolution, collaboration, provenance, and AI assistance ordinary parts of the workflow.
And we will need to train far more people to use those tools. If ontologies are going to become part of the semantic infrastructure underlying AI, science, industry, government, and national security, ontology engineering cannot remain a niche expertise learned largely through apprenticeship.
The Day 5 NCOR report goes into much greater detail on these competing visions.
We ended the week with one final unresolved question: Can AI merely accelerate normal science, or could it eventually participate in the kind of revolutionary science that changes the conceptual framework of a field?
What I took away from the week
The most important lesson for me was that ontology engineering is broadening.
The field is no longer principally about constructing ontologies in an editor.
It increasingly involves:
governing shared semantic infrastructure;
mapping between independently developed conceptual systems;
connecting semantics to data and knowledge graphs;
combining deductive, inductive, and abductive reasoning;
formally validating models and their consequences;
designing AI systems in which stochastic and deterministic components have clearly defined responsibilities; and
developing the tools and workforce necessary to make all of this operational.
The philosophical questions have not gone away. If anything, they become more important as the systems built on top of our conceptual distinctions become more powerful.
But applied ontology is also becoming a mature engineering discipline.
The question is no longer simply how do we build a good ontology?
It is becoming:
How do we build, connect, test, govern, and evolve semantic systems at the scale at which modern information systems—and increasingly AI systems—actually operate?
That is the ecosystem we were trying to explore.
And it is the one I think ontology engineering now has to build.
Watch and read more
The complete event recordings are available in the World’s Ontology Ecosystem YouTube playlist.
NCOR's five-part event report:
Day 1: From Philosophy to Tradecraft
Day 2: Careful Modeling Is the Point
Day 3: AI Should Support Ontology Engineering, Not Replace It
Day 4: Building AI Workflows You Can Actually Validate
Day 5: Where Ontology Engineering Goes Next