XES and OCEL: Two Models for Structured Process Events

Two representations of events and their relationships

The XES and OCEL 2.0 standards emphasize different aspects of event data exchange.[1][3]

The appropriate representation depends on which relationships must survive export. Even a complex process can be investigated using a suitable XES case view. Conversely, an OCEL export does not retroactively supply missing object relationships.

XES and OCEL compared directly

The table is not a ranking. XES is not unsuitable merely because a process involves multiple objects. A sensibly chosen case perspective is often sufficient. Conversely, OCEL is not automatically the better choice when relationships exist technically but do not matter for the analysis.

The decisive question is which information must be preserved when moving to the event model. If an analysis considers only an order's lifecycle, XES can be precise and efficient. If the same events simultaneously concern material, a batch, equipment, a sample, and an order, OCEL preserves these multiple relationships more explicitly.

The same operation in two export views

In an illustrative example, task A-17 uses material batches M-01 and M-02 for intermediate-product batch Z-07. Event E-10 documents this material use. Later, E-11 connects sampling with sample P-03 and Z-07. These identifiers are examples only.

An XES view with Z-07 as the case includes E-10 and E-11 in its trace. Associated material and sample identifiers can be included as attributes. If each material lifecycle is also to appear as a trace, a decision is needed on how E-10 is assigned to the two material cases. Its original identity should be preserved when counting real operations.

An OCEL view can connect E-10 to A-17, M-01, M-02, and Z-07, and E-11 to P-03 and Z-07. Qualifiers identify the objects' roles. Whether a particular export file actually contains these associations must be checked; the format's capability alone is insufficient evidence.

XES: Transferring a defined case view

An XES log contains traces, which in turn contain events. Attributes can carry additional information at log, trace, and event level. The choice of case identity determines which events are grouped into a trace.^[2]

For the lifecycle of an intermediate-product batch, that batch can define the trace. Material and sample identifiers can also be transferred as attributes. Investigating the path of a material batch through multiple production tasks, by contrast, requires a different case view.

The case view is a useful simplification when it supports the specific question. Where objects participate jointly, the export needs explicit assignment and counting rules. Extensions and custom attributes can add information, but do not replace a shared definition of its meaning.

The object-centric model of OCEL 2.0

OCEL 2.0 does not primarily organize data as a collection of separate traces. The model distinguishes typed events and typed objects. Each event has a unique identifier, exactly one event type, a timestamp, and optional attributes. Objects also have unique identifiers, types, and attributes.^[3]

The decisive difference lies in the relationships. Event-to-object relationships connect an event to any number of participating objects. An event Prüfung freigegeben can therefore be connected simultaneously to the test, sample, batch, and approving role. Qualifiers can express an object's function in the specific relationship.

Object-to-object relationships additionally record connections that do not arise solely through a single event. A sample comes from a batch, an order contains several line items, or a sub-batch belongs to a parent batch. These relationships can also be qualified. In OCEL 2.0, however, they have neither their own timestamp nor a validity interval. Changes to such relationships over time require an additional modeling convention, for example through events describing the change.

OCEL 2.0 can also represent time-dependent object attributes. An object value therefore need not be treated as an immutable property throughout the lifecycle. This is useful when, for example, status, assignment, or domain classification changes in a traceable way.

The specification describes three exchange forms: a relational implementation based on SQLite, XML, and JSON. All three are intended to convey the same metamodel; the specific technical form can be adapted to storage and the toolchain.^[3]

The projection needs a documented selection rule

For the export case, decisions must be recorded: which identifier defines a trace, which events are selected, which original IDs are preserved, and how are multiple relationships handled? This information makes a repeated export and comparison of two files traceable.

Even with OCEL, scope remains a selection. If equipment objects are omitted, for example, the export cannot later answer an equipment-related question. Explicitly modeled multiple relationships permit additional views, but do not remove the limitations of the supplied data subset.

Conversion is not automatically lossless

An OCEL cannot be converted into exactly one case-based XES log without further decisions. At least one case notion must be chosen for the transformation. If multiple object types are exported as cases, events may appear in multiple traces. Relationships and qualifiers modeled separately in OCEL require additional mapping rules.

The reverse direction also has limits. An XES log contains events, traces, and attributes, but not necessarily the original object identities and relationships. If this information is missing, conversion cannot reliably reconstruct it. An attribute containing a material number, for example, does not establish the material's role in the event or its connections to other objects.

The exchange model should therefore be chosen before extraction wherever possible. Transformation rules, case construction, data types, and the treatment of multiple relationships belong in the documented data pipeline. Only then does it remain traceable which operational reality the log preserves and which perspective has deliberately been simplified.

How an export decision affects analysis

If E-10 appears in two material traces, a naive row count may turn it into two uses. An analysis referring to the original event identity can account for this multiple representation. The appropriate counting method depends on the question.

Object-centric process mining investigates intertwined object lifecycles. Conformance checking compares recorded behavior with a model. The exchange format provides the data representation; the method, mapping, and assessment scope must be defined separately.

Data quality arises before export

A valid file format guarantees neither complete nor correct event data. XES and OCEL can define how values are structured. They cannot check whether an activity was actually captured, whether a timestamp denotes the operationally correct moment, or whether an object relationship comes from the real execution.

Event-type semantics must also be managed beyond syntax. Prüfung abgeschlossen may mean the technical measurement in one system and the substantive assessment in another. Consistent names help only when definitions, triggers, and required context also agree.

Reliable analyses therefore need controlled generation, stable identities, traceable transformations, and quality checks. The standard is an agreement on transport and structure. The reliability of its content arises in the executing system and throughout data processing.

OCEL does not automatically make a model complete in its domain. Unsuitable object types, unclear qualifiers, or missing relationships remain modeling errors.

An export must reveal its simplifications

In the example, the batch history reads well as a trace. The material perspective makes different demands on assignment and counting. Both representations can be useful when their purpose and derivation are known.

A useful handover therefore includes more than a readable file: it describes the selected objects, preserved identities, and deliberately simplified relationships. This lets the recipient assess which analysis the supplied subset supports.

An event log is not an audit trail. Purposes, content, and regulatory requirements must be assessed separately. Neither standard demonstrates compliance. Meeting specific requirements depends on the system, procedures, use, and demonstrable control.