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 general concepts needed to describe manufacturing operations:

• Process
• PhysicalEntity
• OperationalEntity
• Agent
• Location
• Capability
• Role
• Event
• State

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

Those concepts belong in an inventory-domain ontology.

The purpose of the inventory ontology is to introduce the vocabulary needed to describe where materials are held, how they are received and moved, how their quantities are recorded, and whether they are available for production or dispatch.

In this example, the inventory ontology covers:

• Warehouses and storage areas
• Material lots and unit loads
• Bulk storage vessels
• Material receipt, putaway, picking, transfer, counting, and dispatch
• Inventory records and movement instructions
• Warehouse personnel and material handlers
• Storage and handling capabilities
• Material-movement events
• Inventory availability states

The example is based on the inventory operations of a ketchup-production plant, but the same extension approach can be applied across food and beverage, pharmaceutical, chemical, automotive, and other manufacturing environments.

Extending the Core Ontology

The inventory ontology introduces more specific concepts by making them subclasses of the existing core concepts.

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 still describes the general semantic structure of manufacturing operations. The inventory ontology adds the vocabulary required to represent material storage, movement, availability, and stock accounting.

The resulting architecture is:

Core ontology
    ↓
Inventory-domain ontology

For example:

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

Each inventory process retains the meaning of the core Process concept: it represents work that happens over time and affects something.

1. Extending Location with inventory areas

Inventory operations take place across several types of storage and material-handling areas.

The inventory ontology introduces:

Warehouse SUBCLASS_OF Area

StorageZone SUBCLASS_OF WorkCenter

ReceivingArea SUBCLASS_OF Area

DispatchArea SUBCLASS_OF Area

QuarantineStore SUBCLASS_OF WorkCenter

Warehouse

A Warehouse is the building in which raw materials, packaging components, and finished products are held before they are consumed or dispatched.

An actual warehouse could later be represented as:

MainWarehouse
    INSTANCE_OF Warehouse

StorageZone

A StorageZone is a demarcated area within a warehouse that groups storage locations according to their conditions or purpose.

Examples include:

Ambient storage
Chilled storage
Hazardous-material storage
Finished-goods storage

At the knowledge-graph level:

AmbientZone1
    INSTANCE_OF StorageZone

ReceivingArea

A ReceivingArea is the dock or staging area where inbound materials and packaging components are unloaded and checked before they are moved into storage.

For example:

ReceivingDock1
    INSTANCE_OF ReceivingArea

A receipt process could then be connected to the location:

MaterialReceipt4711
    OCCURS_AT ReceivingDock1

DispatchArea

A DispatchArea is the area where finished-goods pallets are staged and loaded onto outbound vehicles.

For example:

DispatchDock2
    INSTANCE_OF DispatchArea

QuarantineStore

A QuarantineStore is a segregated location used to hold material that is on hold pending quality release or another disposition decision.

For example:

QuarantineStore1
    INSTANCE_OF QuarantineStore

The inventory ontology therefore gives the general core concept Location a more precise warehousing and material-handling meaning.

2. Extending PhysicalEntity with inventory objects

The inventory ontology introduces five physical concepts:

MaterialLot
StorageBin
Silo
StorageTank
UnitLoad

All five extend the core PhysicalEntity concept.

MaterialLot

A MaterialLot is a traceable quantity of a single material that was received or produced together and shares one lot code.

For example:

SugarLot4711
    INSTANCE_OF MaterialLot

The material lot is the unit through which inventory can be connected to:

• Material origin
• Quality status
• Storage location
• Production consumption
• Finished-product genealogy

A lot may be stored, transferred, issued, quarantined, or depleted over time.

StorageBin

A StorageBin is a discrete, addressable storage position on a rack or shelf.

For example:

BinA-01-03
    INSTANCE_OF StorageBin

It identifies the specific position at which a unit load or quantity of material is held.

Silo

A Silo is a bulk vessel used to hold dry ingredients ahead of production.

Examples include:

Sugar silo
Starch silo

An actual silo could be represented as:

SugarSilo1
    INSTANCE_OF Silo

StorageTank

A StorageTank is a bulk vessel used to store liquid ingredients ahead of the batch process.

Examples include vessels holding:

Vinegar
Oil
Liquid sweetener

For example:

VinegarTank12
    INSTANCE_OF StorageTank

UnitLoad

A UnitLoad is a palletized grouping of material that is handled and moved as one unit.

For example:

PalletUL-8821
    INSTANCE_OF UnitLoad

A unit load may contain raw materials, packaging components, or finished goods.

Together, these concepts allow the inventory ontology to represent both the traceable material and the physical form in which it is stored or handled.

3. Extending Process with inventory work

The inventory ontology introduces an abstract parent concept:

InventoryProcess SUBCLASS_OF Process

It then defines six types of inventory work:

MaterialReceipt
Putaway
Picking
MaterialTransfer
StockCount
Dispatch

MaterialReceipt

MaterialReceipt represents taking delivery of inbound material and booking it into stock.

For example:

SugarReceipt4711
    INSTANCE_OF MaterialReceipt

The process may involve:

• Unloading the delivery
• Confirming the material identity
• Recording the quantity received
• Assigning a lot code
• Creating a goods-receipt record
• Placing the material into an initial inventory state

Putaway

Putaway represents moving received material from the receiving area to its assigned storage location.

For example:

SugarPutaway4711
    INSTANCE_OF Putaway

The process connects material receipt with warehouse storage:

ReceivingArea
    ↓
Putaway
    ↓
StorageZone or storage position

Picking

Picking represents retrieving material from storage to satisfy a production or dispatch demand.

For example:

IngredientPick882
    INSTANCE_OF Picking

A picking execution may retrieve raw ingredients for a production order or finished-goods pallets for customer dispatch.

MaterialTransfer

MaterialTransfer represents relocating material from one storage location to another within the site.

For example:

TransferExecution92
    INSTANCE_OF MaterialTransfer

This might move material:

• From receiving to storage
• Between warehouse zones
• From quarantine to available stock
• From a warehouse to a production staging area
• Between bulk-storage vessels

StockCount

StockCount represents physically counting material to verify the recorded inventory quantity.

For example:

CycleCountExecution32
    INSTANCE_OF StockCount

The count may identify a difference between:

Recorded quantity

and:

Physically counted quantity

Dispatch

Dispatch represents loading finished-goods pallets onto an outbound vehicle and removing them from stock.

For example:

DispatchExecution204
    INSTANCE_OF Dispatch

Together, the inventory processes describe the material-handling lifecycle:

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

Stock counts may occur throughout this lifecycle to verify the accuracy of the inventory records.

4. Extending OperationalEntity with inventory instructions and records

The inventory ontology introduces five operational entities:

InventoryRecord
MaterialTransferOrder
StockCountRecord
GoodsReceipt
PickList

These can be divided broadly into instructions that direct inventory work and records that document what happened.

Inventory instructions

The following concepts direct or authorize work:

MaterialTransferOrder
PickList

A MaterialTransferOrder authorizes the movement of material between two locations.

For example:

TransferOrder882
    INSTANCE_OF MaterialTransferOrder

It can guide a material-transfer process:

TransferExecution92
    IS_GUIDED_BY TransferOrder882

A PickList identifies the materials and quantities that must be retrieved to satisfy a production or dispatch demand.

For example:

ProductionPickList4711
    INSTANCE_OF PickList

It can guide a picking execution:

IngredientPick882
    IS_GUIDED_BY ProductionPickList4711

Inventory records

The following concepts provide evidence of inventory activity:

InventoryRecord
StockCountRecord
GoodsReceipt

An InventoryRecord represents the accounting record of the quantity of a material held at a particular location.

For example:

SugarInventoryRecord12
    INSTANCE_OF InventoryRecord

A StockCountRecord captures the physical quantity counted and any variance from the recorded stock.

For example:

CycleCountRecord32
    INSTANCE_OF StockCountRecord

The stock-count process can produce it:

CycleCountExecution32
    PRODUCES CycleCountRecord32

A GoodsReceipt confirms that inbound material was received against a purchase order.

For example:

GoodsReceipt4711
    INSTANCE_OF GoodsReceipt

The material-receipt process can produce it:

SugarReceipt4711
    PRODUCES GoodsReceipt4711

This creates a distinction between:

The inventory work that should be performed

and:

The accounting evidence of what was received, moved, picked, or counted

That distinction is important for stock accuracy, traceability, reconciliation, and auditability.

5. Extending Agent with inventory participants

The inventory ontology introduces two types of agent:

WarehouseOperator SUBCLASS_OF Agent

MaterialHandler SUBCLASS_OF Agent

WarehouseOperator

A WarehouseOperator is a person responsible for receiving, storing, and issuing material while maintaining stock accuracy.

For example:

WarehouseOperator17
    INSTANCE_OF WarehouseOperator

The operator may participate in several inventory processes:

WarehouseOperator17
    PARTICIPATES_IN SugarReceipt4711

WarehouseOperator17
    PARTICIPATES_IN CycleCountExecution32

The core role model can then describe how the operator participates:

WarehouseOperator17
    PLAYS_ROLE Performer

MaterialHandler

A MaterialHandler is a person or vehicle that physically moves unit loads between locations.

For example:

Forklift3
    INSTANCE_OF MaterialHandler

It may participate in a putaway or transfer execution:

Forklift3
    PARTICIPATES_IN SugarPutaway4711

The inventory ontology therefore supports both human and mechanized participants in material movement.

The source ontology does not introduce inventory-specific roles such as Picker, Receiver, or Carrier. These can be represented through the shared core role model or added later through a more detailed inventory extension.

6. Extending Capability with inventory abilities

The inventory ontology introduces two capabilities:

StorageCapability
MaterialHandlingCapability

These extend the core Capability concept.

StorageCapability

StorageCapability is the ability to hold a material under the conditions required by its specification.

For example:

ChilledStorageZone1
    HAS_CAPABILITY ChilledStorageCapability

or, using the general class defined by the current ontology:

Warehouse1
    HAS_CAPABILITY StorageCapability

An inventory process or storage requirement can then declare that it requires a suitable storage capability.

This supports questions such as:

Which location has the capability to store this material under its required conditions?

MaterialHandlingCapability

MaterialHandlingCapability is the ability to lift, transport, and place unit loads within the warehouse.

For example:

Forklift3
    HAS_CAPABILITY MaterialHandlingCapability

A putaway or transfer process may require that capability:

SugarPutaway4711
    REQUIRES_CAPABILITY MaterialHandlingCapability

This creates the reusable core matching pattern:

InventoryProcess
    REQUIRES_CAPABILITY
Capability
    possessed by
Agent or PhysicalEntity

An application or AI agent can use this pattern to identify which operators, vehicles, or storage locations are suitable for a particular inventory task.

7. Extending Event with inventory-significant occurrences

The inventory ontology introduces:

InventoryEvent SUBCLASS_OF Event

It then defines five inventory events:

MaterialReceived
MaterialIssued
MaterialTransferred
StockCounted
MaterialQuarantined

MaterialReceived

MaterialReceived records that a quantity of material entered stock.

For example:

MaterialReceivedEvent4711
    INSTANCE_OF MaterialReceived

The event may occur during a receipt process:

MaterialReceivedEvent4711
    OCCURS_DURING SugarReceipt4711

MaterialIssued

MaterialIssued records that a quantity of material was issued from inventory to satisfy a production or dispatch demand.

For example:

MaterialIssuedEvent882
    INSTANCE_OF MaterialIssued

MaterialTransferred

MaterialTransferred records that material moved from one location to another.

For example:

MaterialTransferredEvent92
    INSTANCE_OF MaterialTransferred

The event may occur during a transfer execution:

MaterialTransferredEvent92
    OCCURS_DURING TransferExecution92

StockCounted

StockCounted records that a material was physically counted and that the resulting variance was recorded.

For example:

StockCountedEvent32
    INSTANCE_OF StockCounted

MaterialQuarantined

MaterialQuarantined records that material was placed on hold and moved to quarantine pending disposition.

For example:

MaterialQuarantinedEvent71
    INSTANCE_OF MaterialQuarantined

The event may affect the material lot and change its availability:

MaterialQuarantinedEvent71
    AFFECTS SugarLot4711

MaterialQuarantinedEvent71
    CHANGES_STATE SugarLot4711

Together, these events provide the time-based evidence needed to reconstruct inventory history:

MaterialReceived
    ↓
MaterialTransferred
    ↓
MaterialIssued

or, where a problem is identified:

MaterialReceived
    ↓
MaterialQuarantined
    ↓
Quality disposition

8. Extending State with inventory availability

The inventory ontology defines five inventory states:

AvailableState
ReservedState
AllocatedState
InTransitState
DepletedState

These extend the core State concept.

AvailableState

AvailableState means that stock is on hand and free to be consumed or shipped.

For example:

SugarLot4711
    HAS_STATE AvailableState

ReservedState

ReservedState means that stock has been earmarked for a particular demand but has not yet been fully committed to it.

For example:

SugarLot4711
    HAS_STATE ReservedState

AllocatedState

AllocatedState means that stock has been committed to a specific demand and is no longer available to other orders.

For example:

SugarLot4711
    HAS_STATE AllocatedState

InTransitState

InTransitState means that stock is currently being moved between locations and has not yet reached its destination.

For example:

SugarLot4711
    HAS_STATE InTransitState

DepletedState

DepletedState means that the stock of a material at a particular location has been fully consumed.

For example:

SugarLot4711
    HAS_STATE DepletedState

A typical inventory lifecycle might look like:

AvailableState
    ↓
ReservedState
    ↓
AllocatedState
    ↓
InTransitState
    ↓
AvailableState at destination

or:

AvailableState
    ↓
AllocatedState
    ↓
DepletedState

Issued is deliberately absent from that sequence. Issuing material to production is an event, MaterialIssued, not a state the lot rests in — it is the occurrence that moves the lot from allocated to depleted. The event records what happened; the state records the condition it left behind.

The exact sequence depends on whether the material is being moved, consumed in production, or shipped to a customer.

9. Specializing the core relationships

The inventory ontology introduces two specialized relationships:

MOVES
STORED_AT

These refine relationships already defined in the core.

MOVES

The core defines:

Process AFFECTS Entity

The inventory ontology specializes this with:

Process MOVES PhysicalEntity

For example:

SugarPutaway4711
    MOVES SugarLot4711

TransferExecution92
    MOVES PalletUL-8821

MOVES is more precise than the general statement:

TransferExecution92
    AFFECTS PalletUL-8821

It tells us that the process changes the physical location of the material or unit load.

The ontology therefore defines:

MOVES SPECIALIZES AFFECTS

STORED_AT

The core defines:

Entity IS_LOCATED_AT Location

The inventory ontology specializes this with:

PhysicalEntity STORED_AT Location

For example:

SugarLot4711
    STORED_AT AmbientZone1

PalletUL-8821
    STORED_AT BinA-01-03

STORED_AT is more precise than IS_LOCATED_AT because it expresses an inventory-storage relationship rather than only a general spatial location.

The ontology therefore defines:

STORED_AT SPECIALIZES IS_LOCATED_AT

Together, the two relationships distinguish between:

Where inventory is currently held

and:

The process that changes where it is held

A complete inventory example

The resulting inventory ontology can support a graph such as:

SugarLot4711
    INSTANCE_OF MaterialLot

SugarReceipt4711
    INSTANCE_OF MaterialReceipt

ReceivingDock1
    INSTANCE_OF ReceivingArea

SugarReceipt4711
    OCCURS_AT ReceivingDock1

WarehouseOperator17
    INSTANCE_OF WarehouseOperator

WarehouseOperator17
    PARTICIPATES_IN SugarReceipt4711

MaterialReceivedEvent4711
    INSTANCE_OF MaterialReceived

MaterialReceivedEvent4711
    OCCURS_DURING SugarReceipt4711

SugarReceipt4711
    PRODUCES GoodsReceipt4711

The material may then be put away:

SugarPutaway4711
    INSTANCE_OF Putaway

Forklift3
    INSTANCE_OF MaterialHandler

Forklift3
    PARTICIPATES_IN SugarPutaway4711

Forklift3
    HAS_CAPABILITY MaterialHandlingCapability

SugarPutaway4711
    REQUIRES_CAPABILITY MaterialHandlingCapability

SugarPutaway4711
    MOVES SugarLot4711

SugarLot4711
    STORED_AT AmbientZone1

Later, the material may be reserved and picked for production:

SugarLot4711
    HAS_STATE ReservedState

ProductionPickList882
    INSTANCE_OF PickList

IngredientPick882
    INSTANCE_OF Picking

IngredientPick882
    IS_GUIDED_BY ProductionPickList882

IngredientPick882
    MOVES SugarLot4711

MaterialIssuedEvent882
    INSTANCE_OF MaterialIssued

MaterialIssuedEvent882
    OCCURS_DURING IngredientPick882

MaterialIssuedEvent882
    CHANGES_STATE SugarLot4711

SugarLot4711
    HAS_STATE AllocatedState

The graph is specific to inventory, but every major concept remains grounded in the core ontology.

For example:

SugarPutaway4711
    INSTANCE_OF Putaway
    SUBCLASS_OF InventoryProcess
    SUBCLASS_OF Process

and:

SugarLot4711
    INSTANCE_OF MaterialLot
    SUBCLASS_OF PhysicalEntity

This allows applications and AI agents to move between detailed inventory facts and the general manufacturing semantics shared across domains.

Connecting inventory with production and quality

One of the main benefits of extending a common core ontology is that inventory does not remain isolated from production and quality.

A material lot may be represented once and then participate in several domain processes.

For example:

SugarLot4711
    STORED_AT AmbientZone1

describes its inventory context.

The production ontology may then show:

SugarLot4711
    PARTICIPATES_IN MixingExecution882

SugarLot4711
    PLAYS_ROLE Input

The quality ontology may show:

SamplingExecution71
    INSPECTS SugarLot4711

SugarLot4711
    HAS_STATE ApprovedState

The inventory ontology may then determine whether that same material is available for issue:

SugarLot4711
    HAS_STATE AvailableState

An AI agent can therefore traverse across domains to answer questions such as:

Which approved material lots are currently available, stored in the correct zone, and sufficient to satisfy the next production order?

The agent can connect:

Quality status
    ↓
Inventory availability
    ↓
Storage location
    ↓
Production demand

This cross-domain reasoning is one of the strongest benefits of extending a shared manufacturing core.

Conclusion

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

It introduces vocabulary for:

• Warehouses and storage zones
• Receiving, dispatch, and quarantine areas
• Material lots, storage bins, silos, storage tanks, and unit loads
• Material receipt, putaway, picking, transfer, counting, and dispatch
• Inventory instructions and accounting records
• Warehouse operators and material handlers
• Storage and material-handling capabilities
• Inventory-significant events
• Inventory availability states

It also introduces the specialized relationships:

MOVES
STORED_AT

These refine the general core relationships AFFECTS and IS_LOCATED_AT.

The central principle remains:

The core ontology defines the shared structure of manufacturing operations. The inventory ontology extends that structure with the concepts and relationships required to account for materials, control their movement, and determine whether they are available to production or dispatch.

This allows inventory to become more detailed without separating it from production, quality, maintenance, or the rest of the manufacturing knowledge graph.