Object-Centric Event Log (OCEL)

What is an object-centric event log?

An object-centric event log, or OCEL, records events that relate to several business objects at once instead of forcing each event onto a single case. One "invoice sent" event can be linked to an invoice and to the three orders it settles, and all of those links are kept.

A classic event log works differently. It ties every event to one case ID, so you have to decide up front whether a row belongs to an order, an invoice, or a delivery. That choice is fine for many processes, but it falls apart once objects split, merge, and affect each other.

OCEL is the data model and file format behind object-centric process mining. It comes from the process mining research group led by Wil van der Aalst at RWTH Aachen University.

Why one case ID per event falls short

Flattening a real process onto a single case ID causes two well-known problems.

Convergence is when one event belongs to several cases. One invoice covers three orders, so if you flatten by order number, "invoice created" gets copied three times and your analysis counts it three times even though it happened once.

Divergence is the mirror image. One case holds several copies of the same activity that can no longer be told apart. One order with three deliveries produces three "shipped" events under one case ID, and the discovered process looks like a loop when really there were three parallel shipments.

An OCEL avoids both by keeping the multi-object structure in the data instead of squeezing it into one column.

What an OCEL records

An OCEL is built from a few pieces rather than one row per event.

Objects are the business entities that move through the process: orders, order lines, invoices, deliveries, parcels. Each has a type and its own identifier, and its attributes can change over time.

Events are the activities, each with a timestamp, each linked to one or more objects. "Invoice sent" attaches to the invoice and to the order lines it covers.

Relationships record how things hang together: which objects an event touches, and how objects relate to each other, such as an order line belonging to an order. A qualifier can label what a relationship means, for example whether a product was ordered or returned.

Example: split shipment, one invoice

A customer places one order with three lines. Two are in stock and go out in the first shipment; the third follows a week later. A single invoice covers all three lines.

Pick the order number as the case ID and both shipments land in one confusing trace. Pick the delivery number and the order event has to be duplicated, while the shared invoice is hard to attach anywhere. Either choice distorts something.

In an OCEL you keep each real event once and link it to every object it involves. Afterwards you can look at the same process from the order, the order line, the delivery, or the invoice, without first forcing everything onto one universal case.

OCEL versus a classic event log

XES, the older IEEE standard for event logs, groups events into traces around one chosen notion of a case. It is widely supported and still practical when a process has a clear, single case.

OCEL models several connected objects instead. It is not just a different file extension. The choice decides which questions you can ask and which assumptions you bake in when you extract the data. If picking a single case ID always starts an argument, that is often a sign the process is object-centric by nature.

What OCEL 2.0 adds

OCEL 1.0 was proposed in 2020 and formally published in 2021. The OCEL 2.0 specification was published in 2024 and is the more expressive version in use today.

OCEL 2.0 adds object attributes that change over time and explicit relationships between objects, and it lets you qualify those relationships. It offers three interchange formats: a relational database (SQLite), XML, and JSON. Schemas and validation files are published at the ocel-standard.org site.

What to watch out for with OCEL

A valid file is not a good model. Start from the business objects and the questions you want answered, not from whatever tables you happen to have. A database key is not automatically a meaningful object.

Do not link everything to everything. If nearly every event touches nearly every object, analyses balloon and stop being explainable. Model the direct involvement and derive the rest through object relationships.

Tool support varies. Not every tool reads every part of OCEL 2.0. Before you exchange a log, check which attributes, qualifiers, and time-dependent relationships the other side actually reads.

Mind the extra context. One event can expose more through its object relationships than it would in an isolated trace. Keep privacy in view when you enrich a log this way.