Building a Production Operations Domain Ontology in Manufacturing

In the previous article, we implemented a core manufacturing ontology in Neo4j. That core defined the concepts shared across manufacturing operations, including Process, PhysicalEntity, OperationalEntity, Agent, Location, Capability, Role, Event, and State.

The core is deliberately abstract. It does not define production-specific concepts such as fillers, recipes, raw materials, production orders, or batch-completion events. Those belong in a production-domain ontology.

The purpose of the production ontology is therefore simple: extend the shared core with the vocabulary required to describe production operations, while preserving a direct semantic connection to the core model.

For this example, we use a ketchup production operation containing:

• A batch-oriented make side, where ingredients are mixed, cooked, deaerated, homogenized, and buffered.
• A discrete-flow pack side, where the product is filled, capped, labelled, inspected, case-packed, and palletized.

The specific concepts will vary between industries, but the extension pattern is the same.

Extending the Core Ontology

The production ontology specializes concepts already defined in the core manufacturing ontology.

For example:

‍

ProductionProcess SUBCLASS_OF Process
Filler SUBCLASS_OF Equipment
RawMaterial SUBCLASS_OF Material
Operator SUBCLASS_OF Agent
MasterRecipe SUBCLASS_OF OperationalEntity
ProductionEvent SUBCLASS_OF Event

‍

‍The key principle is that where the core already provides an appropriate classification, the domain ontology extends it.

A filler is therefore a type of Equipment, not a new top-level production concept. A raw material is a type of Material. A production process is a type of Process. This keeps the core reusable while allowing the production ontology to become as detailed as the domain requires.

Production Locations, Equipment, and Materials

The core already defines the ISA-95 hierarchy concepts Enterprise, Site, Area, and WorkCenter beneath Location. The production ontology can specialize the levels whose meaning varies within production:

ProductionArea SUBCLASS_OF Area
PackagingArea SUBCLASS_OF Area

ProductionLine SUBCLASS_OF WorkCenter
PackagingLine SUBCLASS_OF WorkCenter

‍
The hierarchy level tells us what kind of location something is, while the production subclass tells us what happens there.

The same approach applies to physical assets. The core defines Equipment as a type of PhysicalEntity, and the production ontology introduces the equipment types required by the process:

CookKettle SUBCLASS_OF Equipment
Filler SUBCLASS_OF Equipment
PackagingMachine SUBCLASS_OF Equipment
Conveyor SUBCLASS_OF Equipment

‍
An actual asset then becomes an instance:

CookKettle101 INSTANCE_OF CookKettle


From the class hierarchy, the graph can infer that CookKettle101 is also Equipment and ultimately a PhysicalEntity.

Materials follow the same pattern:

RawMaterial SUBCLASS_OF Material
IntermediateProduct SUBCLASS_OF Material
FinishedProduct SUBCLASS_OF Material
PrimaryContainer SUBCLASS_OF Material
Closure SUBCLASS_OF Material

‍
Tomato paste may therefore be a RawMaterial, cooked ketchup an IntermediateProduct, a finished bottle a FinishedProduct, and its cap a Closure.

The core does not need to contain any of these distinctions. It only needs to establish the shared concepts of Equipment and Material; the production ontology adds the vocabulary required by the domain.

Defining Production Processes

The core defines Process as work that occurs over time. Production extends this with:

ProductionProcess SUBCLASS_OF Process


More specific production processes can then be organized underneath it. For batch manufacturing, an important distinction is between the different procedural levels involved in execution:

Batch SUBCLASS_OF ProductionProcess
BatchOperation SUBCLASS_OF ProductionProcess
BatchPhase SUBCLASS_OF ProductionProcess

‍
These are siblings rather than a subclass chain. A phase is not a specialized type of operation, and an operation is not a specialized type of batch. Instead, they represent different levels of composition.

The relationship between them is therefore expressed through HAS_SUBPROCESS:

Batch B-20260603-001
   HAS_SUBPROCESS Cook operation 0020
       HAS_SUBPROCESS PasteurizationHold phase 0023

‍
This illustrates an important modeling rule:

• SUBCLASS_OF describes what kind of thing something is.
• HAS_SUBPROCESS describes how a process is composed.

Recurring make-side operations can then be modeled as subclasses of BatchOperation:

PreMixing SUBCLASS_OF BatchOperation
Cooking SUBCLASS_OF BatchOperation

‍Packaging processes can be modelled in the same way:

Filling SUBCLASS_OF ProductionProcess
Capping SUBCLASS_OF ProductionProcess
Labeling SUBCLASS_OF ProductionProcess

‍
Not every name observed in operational data needs to become an ontology class. Recipe-specific phase names such as DoseWater or PasteurizationHold can remain properties of individual BatchPhase instances.

That keeps the ontology focused on stable concepts, while the Knowledge Graph carries the variability of actual production execution.

We also distinguish a process type from an execution of that process:

Cooking SUBCLASS_OF BatchOperation
CookingExecution4711 INSTANCE_OF Cooking


Cooking describes a reusable type of work. CookingExecution4711 represents one occurrence involving specific materials, equipment, operators, and timestamps.

Representing Production Intent and Evidence

Production also depends on information describing what should happen and evidence describing what actually happened. These are modeled as specializations of the core OperationalEntity.

Production intent can include: MasterRecipe, ControlRecipe, ProcessOrder, WorkOrder, PackagingOrder, and ProductionSchedule

Production evidence can include BatchRecord and ProductionResponse


A ProcessOrder, for example, may require 10,000 kg of product. The corresponding ProductionResponse may report that 9,850 kg was actually produced. Likewise, a ControlRecipe may specify a temperature target of 90°C, while the BatchRecord contains the temperatures actually observed during execution.

Separating intent from evidence allows the Knowledge Graph to compare what was planned with what occurred. That becomes useful for traceability, deviation analysis, production reporting, root-cause investigation, and AI-assisted operational analysis.

Agents, Capabilities, and Roles

The production ontology also extends the core Agent concept with participants capable of acting within production:

Operator SUBCLASS_OF Agent
ShiftSupervisor SUBCLASS_OF Agent
LineController SUBCLASS_OF Agent
BatchManagementSystem SUBCLASS_OF Agent


‍What an agent is, however, should remain separate from the role it plays in a particular execution. For example:

Operator17 PARTICIPATES_IN CookingExecution4711
Operator17 PLAYS_ROLE Performer

LineController4 PARTICIPATES_IN CookingExecution4711
LineController4 PLAYS_ROLE Controller

‍The same separation applies to equipment capabilities.

A CookKettle describes what an asset is. A CookingCapability describes what it can do:

CookKettle101 HAS_CAPABILITY CookingCapability
Cooking REQUIRES_CAPABILITY CookingCapability

‍This means a process does not have to be hard-coded to one particular asset type. Any resource providing the required capability could potentially perform the work.

This allows applications or AI agents to ask questions such as: Which available equipment has the capability required to execute this cooking operation?

Roles such as Input, Output, Performer, and Controller are similarly contextual. A material lot is not permanently an Input; it is an input to a particular process execution. Where richer context is required, participation can therefore be represented explicitly.

InputParticipation4711
   HAS_PARTICIPANT TomatoPasteLot71
   IN_PROCESS CookingExecution4711
   HAS_ROLE Input

‍
This gives the graph somewhere to attach information such as quantity consumed, timestamps, source systems, equipment assignments, or approvals.

Defining Production Events and States

The production ontology extends the core Event concept with manufacturing-specific occurrences:

ProductionEvent SUBCLASS_OF Event

BatchScheduled SUBCLASS_OF ProductionEvent
BatchStarted SUBCLASS_OF ProductionEvent
BatchCompleted SUBCLASS_OF ProductionEvent
PhaseStarted SUBCLASS_OF ProductionEvent
PhaseCompleted SUBCLASS_OF ProductionEvent
MaterialConsumed SUBCLASS_OF ProductionEvent
MaterialProduced SUBCLASS_OF ProductionEvent


‍Again, the ontology defines the event type, while the Knowledge Graph records individual occurrences:

BatchStartedEvent4711 INSTANCE_OF BatchStarted
BatchStartedEvent4711 OCCURS_DURING BatchRun4711


These occurrences provide the chronological evidence required to reconstruct how production unfolded. Events should also remain distinct from states.

An event records what happened. A state records the condition that resulted. For example:

BatchCompletedEvent4711 CHANGES_STATE BatchRun4711
BatchRun4711 HAS_STATE CompletedState


The core ontology divides State into scopes because the same state word can have very different meanings depending on what it describes:

‍
These distinctions matter because the lifecycles do not necessarily move together. A process order might already be released by ERP while its work order has only just been received by MES. A batch might be complete while the material it produced remains quarantined awaiting quality approval.

The graph can represent all of these conditions without collapsing them into one ambiguous state vocabulary.

Specializing Core Relationships

Finally, domain ontologies can specialize the broad relationships provided by the core. For example, the core may define:

Process AFFECTS Entity


Production can make this more precise with:

CONSUMES, TRANSFORMS, or YIELDS

‍For example:

CookingExecution4711 CONSUMES TomatoPasteLot71
CookingExecution4711 TRANSFORMS PreBlendLot88
CookingExecution4711 YIELDS CookedKetchupLot92

‍
Likewise, the core relationship:

Process IS_GUIDED_BY OperationalEntity


can be specialized with relationships such as EXECUTES or FULFILLS


For example:

BatchRun4711 EXECUTES ControlRecipe4711
BatchRun4711 FULFILLS ProcessOrder882


EXECUTES tells us which recipe guides the execution. FULFILLS connects that execution to the production requirement it is intended to satisfy. The domain vocabulary becomes more precise without losing its connection to the shared semantics of the core.

Conclusion

A production ontology does not need to redefine manufacturing from the ground up. The core ontology provides the shared structure: processes, physical entities, operational entities, agents, locations, capabilities, roles, events, states, and their fundamental relationships.

The production ontology simply specializes that structure with the concepts required to describe how products are actually made and packaged.

Equipment such as fillers remain types of Equipment. Raw materials remain types of Material. Cooking remains a type of Process. Operators remain Agents. Batch events remain Events.

At the same time, the production extension gives us enough precision to distinguish batches from phases, recipes from execution records, events from states, planning orders from work orders, and physical equipment from the capabilities and roles associated with it.

That is the value of the layered approach: the ontology can become more detailed as you move into a domain without becoming fragmented.

The core establishes the common language. The production ontology adds the vocabulary needed for production. And the Knowledge Graph then uses both to describe the assets, materials, processes, events, states, and executions that actually exist in the plant.

‍