---
title: Object-Centric Event Log (OCEL)
url: https://www.emergentmind.com/topics/object-centric-event-log-ocel
type: topic
---

# Object-Centric Event Log (OCEL)

Object-Centric Event Log (OCEL) is an event-data model for representing processes in which events relate to multiple interacting objects rather than to a single case notion. In contrast to case-centric logs such as XES, OCEL records many-to-many event–object relations, object types, and—under OCEL 2.0—qualified event-to-object and object-to-object relationships together with evolving object attributes. This makes OCEL the canonical data structure for Object-Centric Process Mining (OCPM), where analysis is organized around overlapping object lifecycles, cross-object dependencies, and multi-perspective behavior rather than a single trace partition [2403.01975].

## 1. Conceptual basis and motivation

The defining motivation for OCEL is the inadequacy of single-case event logs for real processes in which events simultaneously concern multiple entities. Traditional event logs force one case identifier per event, which creates convergence and divergence problems: one event may belong to several meaningful process instances, while one projected case may mix multiple repeated activity occurrences that actually belong to different objects. OCEL removes this restriction by recording event–object relations explicitly, so that one event can reference multiple objects of different types and each object can participate in multiple events across its lifecycle [2209.09725].

This object-centric view is particularly natural in ERP, CRM, MES, logistics, order-to-cash, purchase-to-pay, and other domains where activities touch orders, items, deliveries, invoices, payments, customers, batches, or shipments simultaneously. The same rationale also extends to domains outside enterprise systems. In football analytics, for example, one event may concern the match, a team, a possession, one or more players, the ball, and a spatial field zone at the same time, which is precisely the type of relational structure that a single-case log obscures [2507.12504].

A recurring misconception is that OCEL is only a storage format. The literature treats it both as a conceptual model for object-centric event data and as an exchange format supporting downstream mining tasks. Another common misconception is that OCEL merely adds more attributes to conventional logs. The crucial difference is structural: OCEL makes event–object multiplicity first-class, and later extensions make relationships and temporal object state first-class as well [2403.01982].

## 2. Formal model and standardization

A common formalization of OCEL is
$$
L = (E, AN, AV, AT, OT, O, \pi_{typ}, \pi_{act}, \pi_{time}, \pi_{vmap}, \pi_{omap}, \pi_{otyp}, \pi_{ovmap}, \le),
$$
where events, objects, object types, timestamps, event attributes, object attributes, and the event–object mapping $\pi_{omap}: E \to P(O)$ are explicit, and $\le$ provides a total order compatible with timestamps [2207.12764].

OCEL 2.0 adopts a more expressive formal tuple:
$$
L = (E, O, EA, OA, \operatorname{evtype}, \operatorname{time}, \operatorname{objtype}, \operatorname{eatype}, \operatorname{oatype}, \operatorname{eaval}, \operatorname{oaval}, E2O, O2O).
$$
Here, $E2O \subseteq E \times qual \times O$ are qualified event-to-object links, $O2O \subseteq O \times qual \times O$ are qualified object-to-object links, and $\operatorname{oaval}: (O \times OA \times time) \not\rightarrow val$ captures time-indexed object attributes. OCEL 2.0 therefore adds dynamic object attributes, object-to-object relationships, and qualifiers to the earlier object-centric model. The specification offers three exchange formats: a relational database (SQLite), XML, and JSON [2403.01975].

The temporal semantics of object attributes are central to OCEL 2.0. If an attribute value is recorded at time $t'$, it remains valid until the next recorded change. Formally, $\operatorname{oaval}_{oa}^{t}(o)$ returns the latest value of attribute $oa$ of object $o$ at time $t$; if no prior value exists, it is undefined. This makes OCEL 2.0 suitable for analyses that depend on the state of objects at the time an event occurred, rather than on a single static attribute snapshot [2406.07596].

Compared to XES, OCEL 2.0 is described as “more expressive, less complicated, and better readable.” That comparison is grounded in three features that XES lacks natively: many-to-many event–object linkage across multiple object types, qualified relations, and dynamic object attributes. Flattening OCEL to XES remains possible, but it loses object-to-object relations, qualifiers, and temporal object-state changes [2403.01975].

## 3. Lifecycles, flattening, and object-centric process representations

A standard analysis primitive in OCEL is flattening by object type. Given an object type $ot \in OT$, the flattened log
$$
FL(L, ot) = (E_{ot}, \pi_{act}^{ot}, \pi_{time}^{ot}, \pi_{case}^{ot}, \le_{ot})
$$
collects events related to at least one object of type $ot$, assigns those objects as cases, and orders events consistently. This produces per-type traces without discarding the original object-centric structure. For an object $o$, its lifecycle is the ordered sequence of events in which it participates, and its trace is the corresponding sequence of activities [2209.09725].

Flattening is the bridge between native object-centric data and conventional mining operators. It supports object-centric directly-follows analysis, discovery of Object-Centric Directly-Follows Graphs (OC-DFGs), and construction of Object-Centric Petri Nets (OCPNs). In OC-PM, an OC-DFG is formalized as
$$
(A, OT, N, F, I^{freqn}, I^{freqe}),
$$
where edges are typed by object type. Discovery proceeds by flattening the log per object type, discovering per-type DFGs, and collating them into a single object-centric graph. This yields models that explicitly show which directly-follows relations are mediated by which object types [2209.09725].

OCEL also supports richer exploration and filtering than case-centric logs. OC-PM defines event-based filters over activities and timeframes, and object-based filters over start activities, end activities, paths, and object types. These filters preserve object-centric consistency by restricting the event, object, and relation domains together rather than projecting events independently. In practice, this is essential because removing events without maintaining relation closure can distort object lifecycles [2209.09725].

Constraint monitoring can also be formulated natively on OCEL. Object-Centric Constraint Graphs (OCCGs) combine activity nodes, object-type nodes, performance formulas, control-flow edges, and object-involvement edges. Their semantics are defined using ordering-relation metrics such as $\mi{causal}_{L}(ot,a,b)$, $\mi{concur}_{L}(ot,a,b)$, and $\mi{choice}_{L}(ot,a,b)$, as well as involvement metrics such as $\mi{absent}_{L}(ot,a)$ and $\mi{multiple}_{L}(ot,a)$. This allows monitoring statements such as whether an activity should involve exactly one object of a type, whether two activities should be concurrent with respect to a type, or whether an average waiting time threshold is exceeded [2210.12080].

## 4. Extraction, storage, and enrichment

Because OCEL records more structure than case-centric logs, extraction requires explicit domain modeling. OCPM$^2$ extends the PM$^2$ methodology with object type identification, conceptual modeling, activity identification, extraction-matrix definition, extraction prioritization, implementation, extraction, and verification. It uses artifacts such as a Question-to-Object Type matrix and an Extraction Matrix documenting which activities relate to which object types and with which cardinalities. In the reported educational case study, this methodology was used to extract an OCEL from a learning management system and an administrative grading system [2503.10735].

Dirigo addresses the same problem from an Object-Role Modeling perspective and evaluates extracted OCEL representations against explicit quality criteria. It emphasizes 3NF-compliant schemas, complete static and dynamic attributes, complete event-to-object and object-to-object relations, and labeled qualifiers. Dirigo also extends OCEL 2.0 by capturing timestamps for object-to-object relations and deriving intervals for dynamic relationships such as assign/drop semantics [2411.07490].

For data-aware scenarios, DOCEL was introduced to make dynamic attributes explicit and unambiguous by linking each dynamic attribute change to both the responsible event and the affected object. This addresses ambiguity in standard OCEL practice when event attributes actually describe evolving object state. Later work provided both synthetic DOCEL generators and an algorithm that converts OCEL logs into DOCEL by detecting event attributes that capture evolving object information and turning them into dynamic object attributes [2212.02858, 2309.14092].

On the systems side, OCEL storage has moved beyond file-based JSON/XML parsing. A MongoDB-backed design maps events and objects to document collections and uses multikey indexes on event–object links to support lifecycle extraction and directly-follows computation without loading entire files into memory. The reported experiments show insertion, indexing, and multi-object directly-follows computations at scales up to 100 million events, whereas an in-memory JSON import failed around 6.8 million events on the test machine [2202.05639].

OCEL has also become a substrate for enrichment. IOTEL uses OCEL 2.0 to integrate process-relevant IoT data into existing logs by attaching information either as event attributes or object attributes, while keeping the result OCEL-compatible. The transformation of OCEL 2.0 into Temporal Event Knowledge Graphs (tEKG) provides another enrichment route: it converts objects into entities and time-indexed snapshots, links events to the last valid object snapshot at event time, and thereby makes OCEL’s temporal attribute semantics explicit in a graph representation [2603.07906, 2406.07596].

## 5. Football as a spatially enriched OCEL case

In football analytics, OCEL has been used to overcome the limitations of classical single-case logs by modeling events against multiple simultaneous objects. The reported framework uses six object types: Match, Team, Possession, Player, Grid position, and Ball. Event classes are divided into game-based events, ball events, and position-based events. Ball events such as passes, shots, and free kicks inherit all object types from game-based events, while position-based events include “Player changes position” [2507.12504].

The football case also introduces an explicit spatial dimension. The field is discretized into a 6×4 grid with 24 cells labeled A1–F4, and positions come from the Metrica Sports coordinate system: “$(x, y)$ in a vertically flipped Cartesian coordinate system, with $(0, 0)$ indicating the origin in the top-left corner, whereas $(1, 1)$ is located in the bottom-right corner.” Grid positions are modeled as objects, which allows object-centric queries such as which player spends the most time in a given zone. Derived features include travel distance, durations, and current score [2507.12504].

The transformation pipeline begins with public Metrica Sports sample data, combining event data and 25 Hz tracking data. It reprojects movement traces onto the 6×4 grid, detects grid-crossing movements as “Player changes position,” decomposes aggregated events, merges movement and game-based logs based on temporal order, propagates contextual information such as possession and score, enriches events with derived attributes, constructs object instances, and links each event to all applicable objects. The final processed DataFrame is converted to an OCEL using PM4Py; the reported toolchain uses Pandas for preprocessing and PM4Py for OCEL conversion and process discovery, with source code released publicly [2507.12504].

The resulting football OCEL contains 37,358 events, 813 objects, and 747 possessions. This case is explicitly described as the first example of object-centric event logs in football analytics. The analysis shows that directly-follows graphs change materially when moving from a single-object ball view to a multi-object view that includes ball, possession, and player. In the ball-only perspective, the graph shows on-ball action sequences such as set pieces followed by passes and passes followed by shots. In the multi-object perspective, “Player changes position” becomes visible and exhibits frequent self-loops due to continuous movement between activities [2507.12504].

The instance-level spatial view illustrates this added value. For possession AA156, the paper reports the sequence “ball recovery in B3 → pass to B4 → back to B3 → progression along the right side into the opponent's half → pass to E1 → movement into F2 → shot.” It further notes that Player15 moved from C3 to D3 and stayed central, while Player18 moved from C4 to F2, indicating higher offensive involvement. An overall forward movement of the team toward the ball is visible. This suggests that OCEL can serve not only as a process-discovery substrate but also as a bridge between event logs and spatial tactical analysis [2507.12504].

## 6. Extensions, complexity management, and research directions

A central challenge of OCEL is that richer semantics often produce more complex models. Clustering has therefore been proposed as a way to simplify OCEL-based discovery by grouping similar objects per selected object type and discovering per-cluster OC-DFGs. The framework distinguishes two event-assignment strategies for convergence situations: existence, which maximizes coverage but duplicates events across clusters, and all, which prevents duplication but may drop events whose same-type objects split across clusters. On a real B2B process, this approach reduced model complexity while maintaining or improving fitness [2207.12764].

Filtering and sampling address the same issue at the log level. Techniques include filtering subsets of object types, filtering essential or frequent events, pruning object type–activity relations that induce divergence, and sampling connected components of the event graph induced by shared objects. These methods are designed specifically for OCEL’s richer factor space of events, objects, and object types, and are intended to make object-centric mining feasible on large logs without breaking referential structure [2205.01428].

Granularity control has emerged as another active direction. Multi-dimensional operations such as drill-down, roll-up, unfold, and fold operate directly on OCEL’s type universes and typing functions, allowing analysts to refine object types by attribute values or unfold event types by related object types. In the reported learning-management-system case, these operations improved fitness and precision for most evaluated groups, while also revealing that low fitness could stem from dynamic object-to-object relations, such as changing group membership, that current discovery methods ignore [2412.00393].

Dynamic relationships remain a major semantic frontier. Recent work argues that OCEL leaves object relationships underspecified when links change over time and formalizes assumptions that make dynamic relationships reconstructible: snapshot semantics, multiplicity knowledge, a single reference type per activity, snapshot interpretation relative to multiplicities, and locality of link modifications. The reported evaluation over public logs indicates that these assumptions are often satisfied, suggesting that clearer dynamic-relationship semantics could become part of future OCEL practice [2604.13053].

Another line of work introduces explicit process scopes. Instead of treating process boundaries as implicit filters, scope objects of type “process” are embedded directly into OCEL, and events and objects are linked to them via qualified relations. This allows analysts to define multiple coexisting processes, project scope-specific sublogs, and aggregate across hierarchies of scopes without changing the underlying event data model. A plausible implication is that scope-aware OCEL can complement existing granularity operations by making process architecture explicit at the data level [2508.18830].

Predictive monitoring increasingly uses OCEL natively rather than flattening it away. Sequence models based on GANs, LSTMs, and Seq2seq architectures can exploit object attributes when a single object-type view is selected, and recent graph-based methods such as HOEG and EHHN keep events and objects in heterogeneous graph or hypergraph structures to predict remaining time or next activity. These results indicate that predictive performance improves when object attributes and event–object interactions are informative, but they also underline that OCEL-native prediction depends on careful handling of view selection, relation structure, and object-state evolution [2207.10017, 2404.05316, 2607.01785].

Taken together, these developments position OCEL not merely as a serialization standard but as a research program around multi-object event data: extraction methodologies, storage architectures, discovery operators, monitoring formalisms, predictive encodings, spatial and IoT enrichment, and increasingly precise semantics for dynamic state, relationships, and scope.

Source: https://www.emergentmind.com/topics/object-centric-event-log-ocel