What is an Ontology for Manufacturing Operations and Why Does it Matter?

If you really think about what actually drives operational decisions and actions in a manufacturing company, from the moment a customer places an order to the moment the finished product is delivered. You’ll realise that much of that process depends on people understanding context that has never been formally defined or documented.

What do I mean by that? Consider a simple example.

A customer places an order for, say, 5,000 cases of tomato ketchup.

That single order sets off a chain of co-ordinated activity across multiple departments. Sales confirms the order. Production planning determines where and when it can be manufactured. Procurement checks whether the required ingredients and packaging materials are available. Operations schedules the production run. Quality verifies the finished product. Logistics prepares the shipment.

‍

‍

And yet, at no point does anyone stop to define every term being used.

No one asks:

What exactly is a batch?

What is the difference between a product and a recipe?

How many bottles are contained in a case?

Or, does the delivery date mean the day the shipment leaves the factory, or the day it arrives at the customer’s location?

And that is because people across the organization share what seems like a common-sense understanding of what concepts such as a customer, a product, or a work order actually mean within the business. More importantly, they also understand how these concepts relate to one another.

A case contains bottles; a product is manufactured according to a recipe; a recipe is executed through a batch; a batch consumes materials and produces finished goods. This shared understanding is so deeply embedded in the way the organization operates that it becomes almost invisible. When someone joins the company, they gradually absorb this knowledge through onboarding, observation and conversations with experienced colleagues. 

This shared understanding is so deeply embedded in the way the organization operates that it becomes almost invisible.

‍

‍

Now, that doesn’t mean that there are absolutely no ambiguities in a manufacturing operation. However, when ambiguity arises, people can usually resolve it with a brief discussion and then continue working. And when someone joins the company, they gradually absorb this knowledge through onboarding, documentation, observation and conversations with experienced colleagues.

The point is that every manufacturing business operates through a shared understanding of the things that exist in the business, what they mean and how they relate to one another.

The problem: machines don't share our context

So, what’s the problem here?

The problem is that this kind of informal, experience-based understanding, is not something software can easily understand.And that is especially true for AI agents, which many manufacturers are now looking to use to support decisions and take on more operational tasks.

For agentic AI to work effectively at scale in manufacturing, AI agents need access to the same understanding of the business that experienced employees already have.

Take, for example, a root cause investigation in batch process manufacturing. 

This is the kind of work experienced engineers do today. But it can take a lot of time and effort because they have to pull data from different systems such as the historian, MES, LIMS, and CMMS, then bring it all together in a spreadsheet or data platform and spend hours, days or even weeks trying to make sense of it.

‍

‍

So, essentially, there is a gap between what people know about an operation and what software can actually understand. And closing that gap requires you to take what humans understand about the operation, and put it into a form an AI agent can read and reason over.

That machine-readable representation of your operational world is called an ontology.

In simple terms: an ontology is a machine-readable description of what things, in a given domain, are, how they relate, and what rules apply to them.

That definition is useful, but it is still quite abstract. So, to understand what an ontology really is, and why it matters, it helps to look at the idea more closely.

The term Ontology is also often used alongside terms such as semantic model, semantic layer, and knowledge graph. And the boundaries between these terms are not always applied consistently, and so, vendors, standards bodies, and practitioners may define them differently. That is not necessarily a problem. What matters more, in my view, is developing the right intuition for the role an ontology plays.

‍

A helpful way to do that is to place it alongside these two closely related concepts: a semantic model and a knowledge graph. You can think of these as three connected layers that together form what we can broadly describe as a semantic data layer; the part of an industrial data architecture that enables people, applications, and AI agents to interpret operational information consistently.

‍

‍

The semantic model makes the ontology possible, and the ontology makes a knowledge graph possible. Let’s break down these three layers and their roles in detail.

Ontology-Based Semantic Layer for Manufacturing Operations

‍

1. The Semantic Model

If you want people, systems, and AI agents to share a consistent understanding of what things are, how they relate, and what rules apply to them within a domain such as manufacturing operations, you first need to establish a common vocabulary.

Consider an analogy from house construction. A shared vocabulary might include terms such as door, window, wall, and roof. Every house may be different, but we can still describe each one using the same set of commonly understood terms and symbols. That shared vocabulary is the foundation of a semantic model.

It is easy to overlook how important this is. But much of the value of standards such as ISA-95 comes from giving manufacturers a common language for describing manufacturing operations. Without that common language, different manufacturers, equipment vendors, software providers, and system integrators may use different words for the same thing, or the same word to mean different things. 

That, obviously, creates confusion and makes integration harder than it needs to be. And this is why, when building a manufacturing ontology, it often makes sense to reuse some of the established terminology from standards such as ISA-95 rather than inventing everything from scratch.

In practical terms, the semantic model is where you define shared concepts such as:

• Equipment
• Work Order
• Production Schedule
• Site
• Area

It is also where you clarify the meaning of important terms. For example, you may define “completion date” as the date on which work was actually completed, rather than the date on which it was scheduled to be completed. That definition can then be applied consistently across every system.

The semantic model also defines the relationships between concepts. For example, using the ISA-95 equipment hierarchy, a work unit may be part of a work centre, and a work centre may be part of an area.

These definitions and relationships provide the shared language on which the rest of the semantic layer is built.

2. The ontology

‍

At this stage, however, the semantic model is still primarily a conceptual specification. It defines the vocabulary, meanings, and relationships within the domain, but those definitions are not necessarily expressed in a form that software can directly interpret.

To make the model operational, you need to represent it in a machine-readable format. This might take the form of a JSON or YAML schema, RDF/OWL, a database schema, or even a set of classes in a programming language.

This formal representation is the ontology.

In other words, if the semantic model provides the shared vocabulary, the ontology turns that vocabulary into a machine-readable model of the entities in your business, their properties, the relationships between them, and the rules or constraints that apply. This distinction also helps clarify the role of ISA-95.

ISA-95 is not, by itself, a machine-readable ontology. It is a standard that defines common terminology, concepts, and models for manufacturing operations management. 

However, a formal implementation of ISA-95, such as B2MML, translates parts of that conceptual model into a structured, machine-readable representation. B2MML can therefore serve as part of an ontology or as the foundation for one.

Returning to the house-construction analogy, you can think of an ontology as a formal architectural blueprint that a builder can interpret. Using the shared vocabulary of walls, doors, windows, and rooms, it defines what a four-bedroom house could look like and what constraints a builder should adhere to.

Likewise, in manufacturing, an ontology similarly uses the shared vocabulary to define classes of entities, their properties, their relationships, and the constraints that govern them. Expressed as a JSON , YAML or more commonly as an RDF file, and even as a graph database schema.

What you end up with is an abstract model of what could exist within your manufacturing operations.

The word could is important.

The ontology may define that a site can contain areas, that an area can contain work centres, and that a work centre can contain work units. It may define that reactor units can have quality inspection events or that one process unit can feed material into another. But it does not yet state that these entities actually exist in a specific factory.

It defines the possible structure of your operational world: the types of things that may exist, the properties they may have, and how they may relate to one another.  It is, in effect, a formal blueprint of your manufacturing operations.

‍

3. The knowledge graph

While the ontology defines the types of things that could exist in your operation. A knowledge graph is created when you use those definitions to represent the things that actually exist. For example, the ontology may define a general class called Work Unit and a relationship called feedsTo. You can then use those abstract definitions to represent two real physical assets on the shop floor: PremixUnit105 and Reactor001.

You can also state that PremixUnit105 feedsTo Reactor001. At that point, you are no longer describing only what could exist. You are representing what actually exists in your operation and how those real entities relate to one another.

That is a knowledge graph: a connected, machine-readable representation of your operational reality.

Returning to the house-construction analogy, the knowledge graph is the actual house at 42 King Street. It has four specific bedrooms, a particular front door, and a window above the kitchen sink. It follows the structure defined in the architectural blueprint, but that structure is now populated with real objects in real locations.

So how does this help an AI agent reason?

Imagine that an agent receives a high-temperature reading from Reactor001.

The knowledge graph tells the agent that Reactor001 is a specific physical asset. The ontology tells it that this asset is a type of reactor, what a reactor is, which properties it can have, and how reactors can relate to other entities.

By following those relationships, the agent may discover that PremixUnit105 feeds material into Reactor001. It may also find the material batch currently moving between them, the production order being executed, the temperature sensors associated with the reactor, and the maintenance events linked to the premix unit.

This gives the agent a structured path for investigation. Instead of treating the temperature reading as an isolated value, it can examine related assets, materials, processes, events, and historical conditions that may help explain the deviation.

In conclusion, the ontology provides the meaning and rules. The knowledge graph provides the real entities and relationships. Together, they give the AI agent the operational context it needs to reason more effectively.

The next In the next article discusses how to actually design an ontology for manufacturing operations.

‍