Building an Inventory Operations Domain Ontology in Manufacturing

In the previous articles, we defined a small core manufacturing ontology and extended it with the concepts needed to describe production, quality, and maintenance operations.

The same approach can be applied to inventory.

The core ontology already provides the concepts shared across manufacturing operations: Process, PhysicalEntity, OperationalEntity, Agent, Location, Capability, Role, Event, and State.

What it deliberately does not define are inventory-specific concepts such as warehouses, material lots, storage bins, putaway processes, stock-count records, or inventory availability states.

Those belong in an inventory-domain ontology.

The purpose of the inventory ontology is therefore to add the vocabulary required to describe where materials are held, how they move through the plant, how inventory quantities are recorded, and whether material is available for production or dispatch.

In this example, the ontology covers material receipt, storage, movement, picking, stock counting, and dispatch within a food-production operation. The same extension pattern can be applied across other manufacturing industries.

Extending the Core Ontology

As with the other domain extensions, inventory concepts are introduced by specializing concepts that already exist in the core.

For example:

InventoryProcess SUBCLASS_OF Process
MaterialLot SUBCLASS_OF PhysicalEntity
InventoryRecord SUBCLASS_OF OperationalEntity
WarehouseOperator SUBCLASS_OF Agent
StorageCapability SUBCLASS_OF Capability
InventoryEvent SUBCLASS_OF Event
AvailableState SUBCLASS_OF MaterialState

‍‍

The core remains unchanged. It provides the general semantic structure, while the inventory ontology introduces the vocabulary required to describe storage, movement, stock accounting, and material availability.

For example:

Process
   └── InventoryProcess
         ├── MaterialReceipt
         ├── Putaway
         ├── Picking
         ├── MaterialTransfer
         ├── StockCount
         └── Dispatch


Every inventory activity therefore remains understandable as a type of manufacturing Process.

Inventory Locations and Physical Entities

Inventory operations take place across several kinds of storage and material-handling locations.

The inventory ontology can specialize the location hierarchy with concepts such as:

Warehouse SUBCLASS_OF Area
ReceivingArea SUBCLASS_OF Area
DispatchArea SUBCLASS_OF Area
StorageZone SUBCLASS_OF WorkCenter
QuarantineStore SUBCLASS_OF WorkCenter

‍

Actual locations can then become instances:

MainWarehouse INSTANCE_OF Warehouse
ReceivingDock1 INSTANCE_OF ReceivingArea
AmbientZone1 INSTANCE_OF StorageZone
QuarantineStore1 INSTANCE_OF QuarantineStore

‍

‍The inventory ontology also introduces the physical concepts needed to represent what is stored and how it is handled: MaterialLot, StorageBin, Silo, StorageTank, and UnitLoad.


For example:

SugarLot4711 INSTANCE_OF MaterialLot
BinA-01-03 INSTANCE_OF StorageBin
SugarSilo1 INSTANCE_OF Silo
PalletUL8821 INSTANCE_OF UnitLoad

‍
These concepts allow the graph to distinguish the material being tracked from the physical form and location in which it is stored.

Defining Inventory Processes

The inventory ontology introduces:

InventoryProcess SUBCLASS_OF Process


and specializes it into the main forms of inventory work.

MaterialReceipt represents receiving inbound material and entering it into stock. Putaway moves received material from the receiving area to an assigned storage location. Picking retrieves material from storage to satisfy production or dispatch demand. MaterialTransfer moves material between locations within the site. StockCount verifies recorded inventory against the physical quantity present. Dispatch removes finished goods from stock and loads them for outbound delivery.

Individual executions then become instances:

SugarReceipt4711 INSTANCE_OF MaterialReceipt
SugarPutaway4711 INSTANCE_OF Putaway
IngredientPick882 INSTANCE_OF Picking
TransferExecution92 INSTANCE_OF MaterialTransfer
CycleCountExecution32 INSTANCE_OF StockCount

‍

Together, these processes describe the basic inventory lifecycle:

MaterialReceipt → Putaway → Storage → Picking or MaterialTransfer → Production consumption or Dispatch


Stock counting can occur throughout that lifecycle to verify that the recorded inventory still reflects physical reality.

The ontology therefore defines the stable types of inventory activity, while the Knowledge Graph records the individual movements and transactions that actually happened.

Representing Inventory Instructions and Records

Inventory also needs to distinguish between instructions describing what should happen and records describing what actually happened.

The inventory ontology therefore extends OperationalEntity with concepts such as: MaterialTransferOrder, PickList, InventoryRecord, StockCountRecord, and GoodsReceipt.


A MaterialTransferOrder authorizes material movement between locations. A PickList identifies the materials and quantities required to satisfy production or dispatch demand.

For example:

TransferExecution92
   IS_GUIDED_BY TransferOrder882

IngredientPick882
   IS_GUIDED_BY ProductionPickList4711

‍
Other entities provide evidence of inventory activity. An InventoryRecord represents the recorded quantity of material held at a particular location. A StockCountRecord captures what was physically counted and any difference from the system quantity. A GoodsReceipt confirms that inbound material was received.

For example:

CycleCountExecution32
   PRODUCES CycleCountRecord32

SugarReceipt4711
   PRODUCES GoodsReceipt4711

‍
This gives the Knowledge Graph an important distinction between the inventory work that was requested and the evidence of what was actually received, moved, picked, or counted.

That distinction supports stock reconciliation, traceability, auditability, and investigation of inventory discrepancies.

Agents and Capabilities

Inventory activities are performed by people and material-handling resources. The ontology can extend Agent with:

WarehouseOperator SUBCLASS_OF Agent
MaterialHandler SUBCLASS_OF Agent

‍
A WarehouseOperator may receive deliveries, perform stock counts, or issue material. A MaterialHandler may represent a person or vehicle responsible for physically moving inventory.

For example:

WarehouseOperator17
   PARTICIPATES_IN SugarReceipt4711

Forklift3
   PARTICIPATES_IN SugarPutaway4711

‍
The core role model can separately describe how each participant is involved:

WarehouseOperator17 PLAYS_ROLE Performer


Capabilities describe what these resources are able to do.

The inventory ontology can define:

StorageCapability
MaterialHandlingCapability

‍

‍For example:

Forklift3
   HAS_CAPABILITY MaterialHandlingCapability

SugarPutaway4711
   REQUIRES_CAPABILITY MaterialHandlingCapability

‍
Similarly, a warehouse or storage zone can provide the storage capability required by a particular material. This allows applications or AI agents to ask questions such as:

Which available location can store this material under the required conditions?

or:

Which material-handling resource is capable of executing this transfer?

Again, the model separates what a resource is from what it can do.

Defining Inventory Events

The inventory ontology extends the core Event concept with significant inventory occurrences:

InventoryEvent SUBCLASS_OF Event


MaterialReceived
MaterialIssued
MaterialTransferred
StockCounted
MaterialQuarantined

‍

These events record what happened at specific points in the material lifecycle. For example:

MaterialReceivedEvent4711 INSTANCE_OF MaterialReceived
MaterialReceivedEvent4711 OCCURS_DURING SugarReceipt4711

‍

‍A later transfer can be represented as:

MaterialTransferredEvent92 INSTANCE_OF MaterialTransferred
MaterialTransferredEvent92 OCCURS_DURING TransferExecution92

‍

‍If a problem is identified, inventory may also record:

MaterialQuarantinedEvent71 INSTANCE_OF MaterialQuarantined
MaterialQuarantinedEvent71 AFFECTS SugarLot4711

‍

‍These occurrences create a chronological history:

MaterialReceived → MaterialTransferred → MaterialIssued


or, where quality intervention is required:

MaterialReceived → MaterialQuarantined → Quality disposition


This event history provides the time-based evidence needed to reconstruct where material came from, where it moved, and what happened to it.

Defining Inventory Availability States

Events tell us what happened. States describe the resulting condition of the inventory.

The inventory ontology introduces states such as:

AvailableState - means stock exists and is free for consumption or dispatch.
ReservedState - means it has been earmarked for a demand.
AllocatedState - means it has been committed to a specific requirement.
InTransitState - means it is moving between locations.
DepletedState - means the available quantity has been fully consumed.

A typical lifecycle might therefore look like:

AvailableState → ReservedState → AllocatedState → InTransitState → AvailableState at destination


or, where material is consumed:

AvailableState → AllocatedState → DepletedState


Importantly, MaterialIssued is an event rather than another state. It records that inventory was issued; the state records the resulting availability condition. Keeping events and states separate lets the graph represent both what changed and what condition exists now.

Specializing Core Relationships

The inventory ontology can also make general core relationships more precise.

The core relationship:

Process AFFECTS Entity


can be specialized with:

MOVES


For example:

SugarPutaway4711 MOVES SugarLot4711
TransferExecution92 MOVES PalletUL8821

‍

MOVES tells us specifically that the process changes the physical location of an inventory object.

Similarly, the core relationship:

Entity IS_LOCATED_AT Location


can be specialized with:

STORED_AT


For example:

SugarLot4711 STORED_AT AmbientZone1
PalletUL8821 STORED_AT BinA-01-03

‍
Together, these relationships distinguish between where material is currently stored and the process responsible for moving it.

Connecting Inventory with Production and Quality

The real benefit of the shared core becomes clear when inventory is connected to other domains.

Consider SugarLot4711.

The inventory ontology might tell us:

SugarLot4711 STORED_AT AmbientZone1
SugarLot4711 HAS_STATE AvailableState

‍

The quality ontology might tell us:

SamplingExecution71 INSPECTS SugarLot4711
SugarLot4711 HAS_STATE ApprovedState

‍And the production ontology might show:

SugarLot4711 PARTICIPATES_IN MixingExecution882
SugarLot4711 PLAYS_ROLE Input

‍‍

These are not three different representations of the same material lot. They are different facts about the same entity, expressed through different domain extensions.

That allows an application or AI agent to ask much richer questions, such as:

Which approved material lots are currently available, stored in an appropriate location, and sufficient to satisfy the next production order?

Answering that requires traversal across:

Quality status → Inventory availability → Storage location → Production demand


This is precisely why the domain ontologies extend a shared core rather than becoming separate semantic islands.

Conclusion

The inventory ontology extends the core manufacturing ontology with the vocabulary needed to describe how materials are received, stored, moved, counted, issued, and dispatched.

It introduces inventory-specific locations, physical entities, processes, instructions, records, participants, capabilities, events, and availability states. Relationships such as MOVES and STORED_AT add more precise meaning to the general relationships already defined by the core.

But the central principle remains the same.

The core ontology defines the shared structure of manufacturing operations. The inventory ontology adds the concepts needed to understand where materials are, how they got there, and whether they are available for use.

Because those concepts remain grounded in the same core, inventory can connect directly to quality status and production demand within the same manufacturing Knowledge Graph.

‍