Processes in EMMO#

In the EMMO ontology, processes represent happenings in time — the activities, transformations, and interactions that change the state of things. Unlike static objects, which persist through time, processes describe events in which entities participate and evolve.

EMMO provides a structured way to describe these processes — from physical phenomena (like diffusion) to laboratory procedures (like mixing or charging a cell) — ensuring that temporal relationships, participants, and causal links are captured consistently.

Overview of Processes#

A Process in EMMO is defined as:

> A structured event in which at least two distinct states or actions occur over time.

This means a process always involves change — whether of material state, configuration, or property value.

Examples:

ChargingProcess — electrons and ions move, changing the chemical state of electrodes.
MixingProcess — substances combine to form a homogeneous phase.
MeasurementProcess — an instrument records the value of a property.

Key features of processes in EMMO:

Time-based evolution – processes have a temporal extent and involve a sequence of states or events.
Causal structure – they describe transformations and interactions with explicit cause–effect relationships.
Holistic composition – complex processes can be broken into subprocesses or arranged into workflows, forming a hierarchy of events.

Representing Processes#

When representing a process in EMMO, it helps to think in terms of who or what participates, what goes in, what comes out, and how it is connected to other processes.

Identify the process type

Begin by defining the specific process class.

{
  "@context": "https://w3id.org/emmo/context",
  "@type": "Process"
}

Specify participants

Link the process to objects or entities that take part in it using hasParticipant.

{
  "@type": "MixingProcess",
  "hasParticipant": [
    { "@type": "LiquidSolvent" },
    { "@type": "Solute" }
  ]
}

Define inputs and outputs

Every process can have entities that enter or leave its boundaries.
- hasInput connects entities that exist before the process.
- hasOutput connects entities that exist after the process.
```
{
  "@type": "ChargingProcess",
  "hasInput": { "@type": "DischargedBatteryCell" },
  "hasOutput": { "@type": "ChargedBatteryCell" }
}
```

Establish order in time

Use precedes or follows to specify temporal sequence.

{
  "@type": "MixingProcess",
  "precedes": { "@type": "HeatingProcess" }
}

Include the process in a workflow

If a process is part of a broader procedure, connect it with hasTask or hasSubProcess (depending on whether it is a workflow or a nested subprocess; see below).
```
{
  "@type": "Workflow",
  "hasTask": { "@type": "ElectrochemicalTestProcess" }
}
```

Mereology of Processes#

Just as physical objects can be broken down into parts, processes can be broken down into subprocesses. This is called temporal mereology — describing wholes and parts in time.

hasSubProcess expresses that one process occurs within another as a constituent event.
isSubProcessOf is its inverse.

This structure allows reasoning such as:

::: If A hasSubProcess B and B hasSubProcess C, then A hasSubProcess C.

Example — defining subprocesses#

{
  "@type": "BatteryTestProcess",
  "hasSubProcess": [
    { "@type": "ChargingProcess" },
    { "@type": "DischargingProcess" }
  ]
}

Here, ChargingProcess and DischargingProcess are subprocesses of a broader BatteryTestProcess. Reasoning will infer that all inputs and outputs of the subprocesses contribute to the overall test.

Workflows and Tasks#

A workflow is a special kind of process that represents an organized sequence of tasks performed to achieve a goal. Workflows define how processes are executed rather than what physical change they describe.

Workflows are typically composed of tasks using the hasTask relation. Each task is itself a process — either simple or complex.

Types of workflows#

Serial Workflow

Tasks are performed in a specific order.

{
  "@type": "SerialWorkflow",
  "hasTask": [
    { "@type": "PrepareElectrodeProcess" },
    { "@type": "AssembleCellProcess" },
    { "@type": "ChargeDischargeTestProcess" }
  ]
}

Parallel Workflow

Multiple tasks occur simultaneously.

{
  "@type": "ParallelWorkflow",
  "hasTask": [
    { "@type": "ElectrolytePreparationProcess" },
    { "@type": "CathodePreparationProcess" }
  ]
}

Iterative Workflow

A task is repeated until a condition is satisfied.

{
  "@type": "IterativeWorkflow",
  "hasTask": { "@type": "CycleTestProcess" }
}

Workflows vs. SubProcesses#

It’s useful to distinguish between subprocesses and tasks:

Concept | Relation | Description |

|----------|-----------|-------------| | SubProcess | hasSubProcess | A process that happens within another process as part of its temporal or physical unfolding. Example: a Heating subprocess inside a SinteringProcess. | | Task | hasTask | A discrete unit of work within a workflow, representing a step to be performed. Example: “Mix precursor” as a task in a SynthesisWorkflow. |

In short: - hasSubProcess models temporal nesting. - hasTask models procedural organization.

Object Properties for Processes#

EMMO defines several key relations for describing processes and their interconnections:

Property	Description
`hasParticipant`	Links a process to entities that take part in it.
`hasInput`	Links a process to entities that are consumed or modified at the start.
`hasOutput`	Links a process to entities that are produced or changed as a result.
`precedes` / `follows` \| Expresses temporal ordering between processes.
`hasSubProcess`	Relates a process to subprocesses that occur within it.
`hasTask`	Relates a workflow to its tasks (process steps).

Example — a complete process description#

{
  "@type": "BatteryFormationProcess",
  "hasInput": { "@type": "AssembledBatteryCell" },
  "hasOutput": { "@type": "FormedBatteryCell" },
  "hasSubProcess": [
    { "@type": "ChargingProcess" },
    { "@type": "RestProcess" },
    { "@type": "DischargingProcess" }
  ]
}

This expresses that the BatteryFormationProcess consists of multiple subprocesses and transforms an AssembledBatteryCell into a FormedBatteryCell.

Best Practices#

Use hasSubProcess to model physical or temporal composition of processes.
Use hasTask to model workflow or procedural composition.
Always define hasInput and hasOutput when modeling transformations.
Use hasParticipant for any other entities involved (tools, environments, catalysts).
Use precedes and follows to represent experimental or computational sequence.
Combine processes hierarchically to represent real-world operations — from fundamental phenomena to full experimental workflows.

Summary#

Processes in EMMO describe how things happen. They capture time, causality, and transformation with the same logical rigor that hasPart brings to spatial composition.

Process — a temporally extended event involving change.
hasInput / hasOutput — define transformations.
hasParticipant — link to involved entities.
hasSubProcess — express nested temporal composition.
hasTask — organize processes in workflows.

By modeling processes this way, users can connect physical phenomena, laboratory steps, and computational workflows under a single, interoperable framework — linking what happens, to whom, and in what order.