Beyond Semantic Layers: Why Ontology Engineering Is Becoming Critical Infrastructure

Dr John Beverley’s STIDS presentation shows why AI needs more than connected data: it needs engineered meaning, systematic disambiguation, and semantic infrastructure that can survive real enterprise

Dr John Beverley, Assistant Professor at the University at Buffalo, Co Director of the National Center for Ontological Research, and co lead developer of Basic Formal Ontology, gave a second day presentation at the 2026 Semantics Technologies for Intelligence, Defense, and Security Conference at Fuse at George Mason University in Arlington entitled “Ontology Engineering as a Tradecraft.”

The presentation was built around a deceptively simple question:

What distinguishes ontology engineering from nearby disciplines?

That is the right question to ask right now. The enterprise world is full of conversations about semantic layers, knowledge graphs, interoperability, Artificial Intelligence readiness, data fabrics, and machine interpretable information. But a lot of those conversations blur together different things that should remain distinct. A taxonomy is not automatically an ontology. A graph is not automatically a semantic model. A business glossary is not automatically machine interpretable. A data integration project is not automatically ontology engineering.

Dr Beverley’s presentation was useful because it did not treat ontology engineering as a branding exercise. It treated it as tradecraft.

I do not want to overstate the talk or turn it into something it was not. My takeaway was not “use this tool” or “buy this architecture.” My takeaway was that ontology engineering has a specific discipline behind it, and that discipline matters if we expect semantic systems to do more than move labels around.

Three points stood out.

1. Ontology Engineering Is Not Distinguished by the Tooling Alone

One of the strongest moves in the presentation was the rejection of easy answers.

Ontology engineering is not distinguished merely because ontologists use the semantic web stack. It is not distinguished merely because they use the Web Ontology Language. It is not distinguished merely because they build ontologies. It is not even distinguished merely because they talk about universals.

Those things may matter, but they are not enough.

That point matters because many organizations still collapse ontology engineering into the artifact or the tool. If there is a hierarchy of terms, someone calls it an ontology. If there is a graph database, someone calls it semantics. If there is a controlled vocabulary, someone assumes meaning has been handled. If there is a mapping layer, someone calls it interoperability.

Those artifacts can be useful. They may even be necessary. But they do not, by themselves, give you ontology engineering.

The tradecraft is the disciplined work of making implicit meaning explicit, representing that meaning in a machine interpretable form, and doing so in a way that can support information quality and interoperability together.

That is the distinction I think enterprises need to understand. Ontology engineering is not just the production of a file. It is not just the use of Web Ontology Language, Resource Description Framework, Shapes Constraint Language, or a graph database. It is the practice of clarifying what kinds of things are being represented, what relations hold among them, what distinctions must not be collapsed, and what structure is needed for systems to operate over those representations.

The tool matters. The artifact matters. But the tradecraft matters more.

2. Interoperability and Information Quality Cannot Be Separated

Dr Beverley framed ontology engineering around two pillars: interoperability and information quality.

That pairing is important because each pillar can fail when pursued alone.

Interoperability without information quality gives you connected confusion. Systems exchange data, but the meaning does not survive the move. A term such as “asset,” “event,” “organization,” “status,” “case,” or “operation” may appear in multiple systems, but each system may use it differently. The pipeline works. The dashboard loads. The receiving system gets a value. But the semantic problem remains.

Information quality without interoperability creates the opposite problem. A team may build a careful local model for one workflow, office, or application. The local work may be thoughtful and internally coherent, but if it cannot travel across organizational or technical boundaries, it becomes another silo.

The presentation’s three axis distinction helped sharpen this point.

Human to human interoperability is about alignment among people. Do we mean the same thing when we use the same term? Can domain experts, analysts, engineers, and stakeholders communicate clearly enough to coordinate?

Human to machine interoperability is about translating human understandable descriptions into formal representations that computational systems can operate over. This is where the ontologist’s role becomes important. The goal is not to make the domain expert become an ontologist in a meeting. The goal is to elicit domain knowledge from the expert and then formalize it using the right representational discipline.

Machine to machine interoperability is about independent systems exchanging, interpreting, and processing data without relying on humans to repair the meaning every time information crosses a boundary.

These are different axes with different success conditions. Human agreement is not the same thing as machine interpretability. Machine readable data is not the same thing as semantic interoperability. A shared term is not automatically a shared formal structure.

That distinction is easy to miss, and it matters.

One of the best practical moments in the talk was the analogy to software development. If a product manager hires a JavaScript developer to build an interface, the developer should not spend the meeting teaching the product manager how to write JavaScript. The product manager explains the need. The developer brings the technical expertise.

Ontology engineering is similar. Domain experts are essential because they know the domain. They know the edge cases, the terms of art, the operational distinctions, and the boundary cases. But the ontologist’s job is not to make every subject matter expert become an ontology engineer. The ontologist’s job is to elicit the knowledge and formalize it responsibly.

That is not elitism. It is division of labor.

And it is one reason ontology engineering should be treated as a real discipline rather than a workshop exercise.

3. The Core Tradecraft Is Systematic Disambiguation

The most important point in the presentation was systematic disambiguation.

This is where ontology engineering separates itself from taxonomy work, concept mapping, ordinary data modeling, and vocabulary management.

Dr Beverley used simple examples, but they are exactly the kind of examples that show why the discipline matters.

A type is not the same thing as an instance of that type. Country is a type. Algeria is an instance.

Information is not the same thing as what the information is about. An occupation code is not the same thing as the person who may hold that occupation.

A material thing is not the same thing as an immaterial thing. A river is not the same thing as the site where a river used to flow.

A process is not the same thing as the product of that process. Baking a cake is not the same thing as the cake. Ontology engineering as an activity is not the same thing as the ontology produced by that activity.

These distinctions sound obvious once they are stated. That was part of the point. They are so obvious that people forget to put them into the data.

That is where the trouble starts.

If these distinctions are not represented, downstream systems inherit the collapse. A data pipeline can move the confusion. A graph database can store the confusion. A dashboard can display the confusion. An Artificial Intelligence application can produce fluent text over the confusion. None of that fixes the underlying semantic error.

This is also where Basic Formal Ontology matters in the talk. Basic Formal Ontology was not presented as decoration. It was presented as a disciplined way to ask what kind of thing is being modeled.

Is it a material entity? Is it a quality? Is it a realizable entity? Is it a process? Is it an immaterial entity? Is it a temporal region? Is it information about any of those things?

That question set is not just philosophical. It is operational. It helps prevent category mistakes from becoming data architecture.

The same is true for relations. Qualities inhere in material entities. Realizable entities are realized in processes. Material entities participate in processes. Information depends on bearers. Entities are located somewhere and exist during some time. These patterns are not random labels. They are part of the discipline that lets a semantic model preserve distinctions instead of flattening them.

That was my biggest takeaway from the talk: ontology engineering is not just about adding meaning. It is about preventing the wrong things from being treated as the same thing.

Why This Matters for Enterprise Systems

This is where I think the presentation connects directly to enterprise systems, Artificial Intelligence applications, and semantic layer discussions.

The phrase “semantic layer” is now everywhere. Sometimes it means a business glossary. Sometimes it means a metrics layer. Sometimes it means a mapping layer. Sometimes it means a knowledge graph. Sometimes it means a set of labels added over existing data.

Some of those things are useful. But if the underlying distinctions remain collapsed, the semantic layer has not solved the meaning problem. It has only made the ambiguity easier to query.

That is especially important when Artificial Intelligence applications are placed on top of enterprise data. Large Language Models can generate useful outputs. They can summarize, classify, retrieve, and produce explanations. But the model itself is not operating over a formally governed account of the entities, relations, constraints, and distinctions in the domain unless the system around it provides that structure.

A fluent output can make a bad semantic assumption look credible. If the underlying representation confuses a code with what the code denotes, a process with its product, or a role with the bearer of that role, the output may still sound confident. Confidence is not correctness. Fluency is not formal semantic grounding.

That is not a criticism of Artificial Intelligence systems. It is a reminder that applications operate over the representations they are given.

If the representation is weak, the output inherits that weakness.

A Practical Return on Investment Point

There is also a practical return on investment here, but I would not reduce the whole presentation to a business case.

The return on investment comes from reducing repeated semantic labor.

Imagine five systems all use the word “asset.” In one system it means physical equipment. In another it means a financial holding. In another it means a digital file. In another it means an information technology resource. In another it means a person or organization playing a role in an operational context.

Without ontology engineering, every new project has to rediscover the ambiguity. One team maps the term for a dashboard. Another team maps it for an integration. Another team writes a glossary definition. Another team builds retrieval logic for an Artificial Intelligence application. Six months later, a new use case appears and the same semantic problem returns.

That is semantic rework.

An ontology engineered approach does not merely argue over the word “asset.” It separates the kinds of entities being collapsed, defines their relations, and makes those distinctions reusable. The next project can map to stable semantic structure instead of repeating the same clarification exercise.

That is where the value appears. Less rework. Fewer brittle mappings. Better governance. Clearer reuse. More reliable application behavior.

But the business value depends on the tradecraft. If the ontology is just another label layer, the return does not materialize.

Ontology Engineering as a Discipline

The last part of the presentation turned toward discipline formation and training.

That mattered because tradecraft has to be taught. If ontology engineering is going to support government, commercial, scientific, and Artificial Intelligence systems, it cannot remain informal. It needs methods, examples, standards, public materials, review practices, and trained practitioners.

That part of the talk also made the earlier argument clearer. Dr Beverley was not just saying “ontologies are useful.” He was saying ontology engineering has a distinct object and method. It is concerned with interoperability, information quality, and systematic disambiguation. It has to be taught as a discipline because the mistakes it prevents are repeatable.

That is the part I think more enterprise leaders need to hear.

The question is not whether your organization has a graph, a glossary, a data catalog, or a semantic layer. The question is whether the meaning underneath those artifacts has been engineered carefully enough to survive reuse.

That is the difference between semantic labeling and ontology engineering.

And that is why “Ontology Engineering as a Tradecraft” was worth paying attention to.