Object-centric data (OCEL 2)

The problem with a single case notion

Conventional event logs assume every event belongs to exactly one case. That works cleanly for a process like a single support ticket’s lifecycle. It works less cleanly for something like order-to-cash: an order can contain several items, each item might ship in a separate delivery, and a delivery might later trigger a separate return process. Which one is “the case”?

Pick the order, and you either drop item- and delivery-level events or duplicate them across every order that shares a delivery. Pick the item, and you lose the fact that several items were consolidated into one delivery. There’s no correct single answer, because the process genuinely involves several related kinds of entities, not one.

What OCEL 2 changes

OCEL 2 (Object-Centric Event Log, version 2) drops the single-case assumption. An event can relate to any number of objects, each with its own object type (order, item, delivery, …) and its own attributes. Instead of one case identifier per event, an event carries a set of object references, and relationships between objects (an order contains items; a delivery fulfills items) are recorded explicitly.

Structurally, an OCEL 2 log (as JSON or SQLite) has:

• Object types and event types, each with typed attributes.
• Objects, each with an object type and attribute values (which may change over time).
• Events, each with an event type, a timestamp, and references to the objects involved.
• Object relationships, both between objects (order → item) and, in OCEL 2 specifically, qualified relationships between events and objects (this event’s role for that object was “resource” vs. “target”).

What this looks like in Promenade

Object-centric artifacts get their own set of views, distinct from the single-case ones:

• Object-centric directly-follows graphs (OC-DFGs) show control flow per object type, with edges annotated by which relationship drove them.
• Object-centric Petri nets (OCPNs) extend Petri nets with per-object-type token flows sharing transitions.
• Case/variant views can still be produced by flattening an object-centric log onto a chosen object type (for example, treating each order as a case again) when you specifically want the conventional view for one entity.

You don’t need to choose between object-centric and conventional analysis up front — a flattened, single-case view of an OCEL 2 log is a fine starting point, and you can move to the full object-centric views (in the Model and Conformance tabs) once you need to reason about how object types relate.

Getting OCEL 2 data into Promenade

Promenade reads OCEL 2’s JSON and SQLite serializations directly. If your source system exports conventional event logs per entity (one CSV per object type, say), you’ll need to construct the object relationships during import — this is covered in Tutorials.