11institutetext: Leuven Institute for Research on Information Systems (LIRIS),
KU Leuven 11email<EMAIL_ADDRESS>
# Object-Centric Event Logs: Specifications, Comparative Analysis and
Refinement

Alexandre Goossens 11 0000-0001-8907-330X Johannes De Smedt 11
0000-0003-0389-0275 Jan Vanthienen 11 0000-0002-3867-7055

###### Abstract

Process mining aims to comprehend and enhance business processes by analyzing
event logs. Recently, object-centric process mining has gained traction by
considering multiple objects interacting with each other in a process. This
object-centric approach offers advantages over traditional methods by avoiding
dimension reduction issues. However, in contrast to traditional process mining
where a standard event log format was quickly agreed upon with XES providing a
common platform for further research and industry, various object-centric
logging formats have been proposed, each addressing specific challenges such
as object relations or dynamic attribute changes. This makes that
interoperability of object-centric algorithms remains a challenge, hindering
reproducibility and generalizability in research. Additionally, the object-
centric process storage paradigm aligns well with a wide range of object-
oriented databases storing process data.

This paper introduces a specifications framework from three perspectives
originating from process mining (what should be analyzed), object-centric
process modeling (how it should be modeled), and database storage (how it
should be stored) perspectives in order to compare and evaluate object-centric
log formats. By identifying commonalities and discrepancies among these
formats, the study delves into unresolved issues and proposes potential
solutions. Ultimately, this research contributes to advancing object-centric
process mining by facilitating a deeper understanding of event log formats and
promoting consistency and compatibility across methodologies.

###### Keywords:

Object-centric processes Object-Centric Event log Process Mining

##  1 Introduction

The general aim of process mining is to understand, discover and enhance
business processes by analyzing event logs recording the different steps
occurring in a process. Traditionally, these processes are analyzed through
the lens of a single object such as a customer or a product. However, not all
processes necessarily fit in this single point of view paradigm as was already
indicated in 2001 with the introduction of proclets to model a process from
multiple perspectives[2]. The idea that processes can be analyzed from
multiple angles has recently gained interest and is more commonly known as
object-centric process mining [8]. Compared to traditional process mining,
object-centric process mining does not suffer from typical dimension reduction
issues such as convergence issues (incorrect multiplication of activities
which do not match their actual occurrence) and divergence issues (ambiguity
in which activities belong to which objects).

Since the introduction of object-centric process mining, various object-
centric logging formats have been proposed with each of them addressing
relevant, but different, object-centric process issues such as the eXtensible
Object-Centric (XOC) logs [3] and Object-Centric Behavioral Constraint (OCBC)
models [26] addressing the need of object relations in object-centric
processes as well as the Artefact-Centric Event Log (ACEL) proposal [28].
However, these proposals had scalability issues which were addressed with the
Object-Centric Event log (OCEL) 1.0 format [14] at the expense of storing
object relations. The Data-aware Object-Centric Event Log (DOCEL) format in
turn addressed the issue of changing attribute values in a process. This
latter issue was also addressed with the recent OCEL 2.0 format which also
includes object relations [7]. Next to that, there is a proposal to store
object-centric processes in so-called Event Knowledge Graphs which come with
their own set of challenges [13]. All these proposals are happening whilst the
IEEE-group is also proposing their own standard object-centric process event
log format called Object-Centric Event Data (OCED)111https://www.tf-
pm.org/resources/oced-standard which is used as a guideline by the different
object-centric event log proposals. Even though there have been other
proposals such as MXML [12] prior to the introduction of the eXtensible Event
Stream (XES) log format [19], the field of process mining greatly benefited
from having the XES standard as it provided a common ground to conduct further
research [6, 1]. Compared to the XES standard, however, there is currently no
consensus on how to store object-centric processes in logs. This suggest that
while there are different object-centric process mining algorithms these do
not necessarily support other object-centric event log formats limiting the
reproducability and generalizability of object-centric process mining research
such as in [16, 4]. Hence, the object-centric process mining field would
benefit from a study investigating what the different object-centric event log
formats share and do not share with one another and in doing so hopefully find
common ground to have an ’Object-Centric XES’.

This study aims to address this gap by analyzing the different object-centric
event log formats using a framework providing an overview of the different
issues that an object-centric event log format could or should address. The
object-centric specifications framework is built by investigating three
different fields crucial to support a process mining exercise: storage given
that a wide range of databases are inherently object-centric instead of
process-centric making the extraction of object-centric event logs more
natural from such databases [27], extraction to discover and analyze the
stored processes, and representation. Next, a thorough discussion explores
solutions for unresolved issues not agreed upon in various object-centric
event log formats or left unaddressed altogether.

The remainder of the paper is structured as follows: Section 2 outlines the
framework’s specifications and its derivation. Next, using the constructed
framework, Section 3 compares the different object-centric event log formats
and on how they do or do not address the different issues followed by a
lengthy discussion on the insights from this comparison in Section 4. Next,
Section 5 proposes further refinements for object-centric event logs. Finally,
Section 6 discusses the limitations and future work of this study with Section
7 concluding this paper.

##  2 Framework Dimensions and Specifications

In the next section, object-centric event log format specifications are
derived by investigating three relevant research fields for object-centric
processes namely:

  1. 1.

Process Mining: Given that object-centric process mining is a continuation of
process mining we start from its initial conception and investigate this field
for specifications for object-centric event logs.

  2. 2.

Conceptual Modeling: Given that object-centric process mining aims at mining
object-centric process models and/or object models, it is necessary to
investigate how these models are structured and how objects are intertwined
with processes in this field.

  3. 3.

Databases: Object-centric event log formats are inherently linked to the
storage of data. Therefore investigating how different types of databases such
as object-oriented databases or temporal databases deal with this is relevant.

For each research field, the most relevant issues are identified and their
implications for object-centric processes are discussed.

####  2.0.1 Framework Dimensions

Object-centric process mining merges process mining and conceptual modelling,
focusing on how multiple object instances interact during process execution.
It integrates the Event-to-Event (E2E) Dimension from traditional process
mining, which studies event sequences’ relationships, and the Object-to-Object
(O2O) Dimension from conceptual modeling, which explores object relationships.
Additionally, it considers the interplay between events and objects, known as
the E2O dimension. These dimensions are pivotal in understanding object-
centric analysis and storage. A recent study highlights these dimensions’
significance, suggesting they can manifest individually or concurrently in an
analysis or event log [8]. Apart from E2E, O2O and E2O, one other dimension
emerges from the analysis: the Data Quality Dimension, offering specifications
on data quality.

###  2.1 Process Mining Research Field Perspective

To gather specifications from the process mining perspective, two primary
sources are identified: the process mining manifesto [35] and the latest
object-centric process mining overview study [8].

####  2.1.1 Process Manifesto: Process mining types

The process mining manifesto outlines three types of process mining: process
discovery, conformance checking, and enhancement (prediction and
prescription). It is clear that any object-centric event log format must
support these three types of process mining as well.

####  2.1.2 Process Manifesto: Process Log Perspectives

Additionally, the process mining manifesto identifies the following
perspectives a traditional process log should have:

  1. 1.

Control-flow: It is important to know how all the activities are related to
one another.

  2. 2.

Organizational perspective: Who does what in an organization?

  3. 3.

Data-perspective: Associate data with events. Enhance the log with accurate
information for each event.

  4. 4.

Time-perspective: Assign timestamps to events for accurate time-based analysis
of processes.

These perspectives need to be transformed to fit into an object-centric
process mining context.

####  2.1.3 Process Manifesto: Event Data Criteria

The process mining manifesto also identifies the following criteria for event
data:

  1. 1.

Trustworthy: The information stored in the event log can be trusted i.e.
activities are not duplicated and all cases contain their respective
activities.

  2. 2.

Complete: There is no crucial information missing due to a transformation i.e.
convergence or divergence issues.

  3. 3.

Well-defined semantics: No ambiguity exists in the data format or attributes.

  4. 4.

Safe: information is anonymized.

While all preceding criteria for event data are crucial, only the first three
are impacted by the event log format itself. Ensuring data integrity is
primarily the responsibility of data engineers rather than the format alone.

####  2.1.4 Object-Centric Process Mining

The main finding of [8] is that no identified log format enables analysis on
all object-centric dimensions (E2E, O2O, and E2O); instead, some formats
support two out of three possibilities [8]. The study did not aim to deeply
compare the differences between event log formats. Since then, new formats
addressing all three dimensions (E2E, O2O, and E2O) have emerged, such as OCEL
2.0 and Event Knowledge Graphs (EKGs) [7, 13].

Additionally, the study [8] categorizes different object-centric process
mining algorithms into these three analysis dimensions. It is not unexpected
that most algorithms utilize event logs supporting E2O and O2O dimensions, as
this aligns with the primary objectives of object-centric process analysis and
the availability of these logs initially. Intriguingly, the algorithms
predominantly yield process models emphasizing E2E, while the other two
dimensions (E2O and O2O) are less frequently discovered.

####  2.1.5 Resulting Framework Specifications

From process mining research, it is essential to note that an object-centric
event log format must comply with the requirements outlined in the process
mining manifesto. The following E2E specifications are derived from this:

  * •

An event must have a unique event ID

  * •

An event must have a timestamp

  * •

An event must have an activity

  * •

An event can have other optional attributes

These specifications correspond to those in the XES format [19] and the
process mining manifesto [35]. Furthermore, the O2O specifications are derived
from the E2E specifications adhering to the same principles as events in the
XES format.

  * •

An object must have an object type

  * •

An object must have a unique object ID

  * •

An object can have optional object attributes

###  2.2 Object-centric Process Modeling Perspective

Object-centric conceptual modeling integrated with processes is predominantly
found in two domains, each approaching the issue from a distinct perspective.
On one side, the research field of data-aware process modeling treats
processes as objects interacting with one another, characterized by well-
defined behavior [24, 18, 32]. Conversely, process mining begins with a
process model where objects interact with one another. Both will be analyzed
to identify common points to derive key specifications.

  1. 1.

Object relations:  In data-aware process modeling, an explicit object model
defining object relations is defined prior to modeling the object behavior in
a process [25, 24, 32]. In object-centric process modeling, such an object
model is not necessarily explicitly defined like with proclets [2] or Colored
Petri Nets (CPN) [23, 15]. A recent Petri Net-based approach models the
process of multiple individual object instances for read-only data [36].
Conversely, OCBC models explicitly define an object model alongside a
declarative process model [3], similar to Guard-Stage Milestone (GSM) [21].
Generally, within the Unified Modeling Language (UML), object relations
precede modeling UML behavior diagrams [29]. The idea behind all these
approaches is that objects and their relations impact a business process.
Storing object relations within an event log can reveal insights into process
execution. For instance, why a customer may only have one order at a time or
why multiple orders can be packaged together for delivery.

  2. 2.

Object-Event relations:  In all mentioned approaches, objects are linked to
events either through individual object behavior models resembling state
machines [29, 25, 24, 32] or directly integrated into the process model [2,
23, 15, 36, 3]. Regardless of how objects and events are connected, it is
essential for both to be associated with each other. This information should
also be stored in event logs; otherwise, obtaining a complete view of an
object-centric process becomes impossible, as knowing when and which objects
interact in a process is crucial. Notably, some approaches require at least
two events per object (one for creation and one for deletion), such as
PhilHarmonic Flows [25], Merode [32], and UML state machine diagrams [29].
Consequently, every event in these approaches must relate to at least one
object. These assumptions have significant implications; no object is
considered relevant for a process if it is not involved in an event, and
likewise, no event is deemed part of a process without involving at least one
object. This means that system-wide events must impact all objects, rather
than none. Certain object-centric event log formats incorporate this
requirement like OCEL 1.0 [14] and DOCEL [17].

  3. 3.

Object information can be updated:  In data-aware process modeling, events can
update objects [25, 32], a concept also found in UML sequence and activity
diagrams. Although the approach in [36] primarily focuses on read-only
immutable data, it acknowledges the existence of processes involving mutable
data. Similarly, in process mining, the XES standard permits updating case
information. This principle should be extended to object-centric processes, as
a comprehensive view of object evolution can elucidate routing decisions or
final outcomes within a process.

  4. 4.

Individual behavior of an object must be recoverable:  Both data-aware process
modeling and object-centric process modeling approaches aim to understand how
individual object instances undergo a process to analyze exceptions or sub-
processes. Additionally, the XES standard explicitly supports this analysis by
linking every process execution to an individual trace. Therefore, for a
comprehensive understanding of how multiple objects undergo a process
simultaneously, an object-centric event log format must allow the discovery of
the individual sequence of events involving each object.

####  2.2.1 Resulting Framework Specifications

Based on this analysis, the following specifications for the O2O dimensions
are added:

  * •

Object attributes can change values and those changes are traceable

  * •

An object instance can be related to other object instances

  * •

Supports relation qualifiers

The first specification addresses the need to track changes in object
information over time within a process, as processes often interact with both
read-only and read-write data. The last specification emphasizes the
importance of capturing object relationships, a fundamental aspect of
conceptual modeling where objects are interconnected. This idea also comes
back in object-centric process modeling where object relations are also
important. The last specification proposes including relation qualifiers
between events and objects or between two objects, endorsed by studies in the
object-centric process field [8], OCEL 2.0 [7], and OCED.

For the E2O dimension, the following specifications are derived:

  * •

An event must be related to 1..N objects

  * •

An object must be related to 1..N events

  * •

The process of an individual object instance must be recoverable

The first two specifications indicate the minimum cardinalities there are
between events and objects, with a stricter formulation chosen for its
significant impact on what can be stored in an object-centric event log. The
last specification ensures the recoverability of the complete process of a
single object instance, aligning with concepts proposed in PhilHarmonic Flows
[25] and the process mining manifesto’s definition of a trace [35].

###  2.3 Databases Perspective

The databases research field is relevant as it addresses storage issues
directly within databases, insights from which may be applicable to object-
centric event logs. This section primarily discusses object-oriented
databases, as they share similarities with object-centric process storage [9,
5]. Additionally, it touches upon temporal [31] and moving databases [37], as
they handle changing information over time, a crucial aspect of process
mining. Knowledge graphs [20, 22] are also considered, as certain proposals
have utilized them as a foundation for storing object-centric processes [13].

Regarding object-oriented databases, the following relevant requirements are
found from the object-oriented databases manifesto [5]:

  1. 1.

Complex objects:  The manifesto emphasizes the need for databases to support
complex objects and attributes such as lists, sets, and tuples, reflecting the
complexity often found in objects. This notion also applies to object-centric
processes.

  2. 2.

Object Identity: It is a requirement for object-oriented databases that each
object instance must have a unique object ID otherwise it is difficult to
uniquely trace the object instance over time [5, 9].

  3. 3.

Object types and classes:  In conceptual modeling, objects can be categorized
by type or class, each with its own set of attributes or operations [5, 9].

  4. 4.

Inheritance: Object-oriented databases incorporate the concept of inheritance,
where an object type inherits attributes and behavior from another object
type, including multiple inheritance. However, this aspect has not yet been
explored in object-centric process mining.

  5. 5.

Updating Object Information: Object-oriented databases may create new object
versions for each update, necessitating a direct link to the previous object
version [9, 5]. Temporal databases, introduced in 1986, distinguish between
transaction time and valid time [31]. Transaction time denotes when a change
occurred in the database, while valid time reflects the time when the change
occurred in reality and is accurate [30, 31]. An object-centric event log
should only contain accurate and unambiguous information, implying it should
only include valid time information. The interplay between transaction time
and valid time should be left for the databases themselves. Lastly, moving
databases [37] address storing objects with rapidly changing values,
distinguishing between static and dynamic attributes based on how frequently
their values change over time. The variety of database types addressing this
issue highlight the importance of accurately tracking changing attributes
values over time in an object-centric process.

  6. 6.

Schema Evolution: In [34], the significance of supporting changes in a
database schema for third-generation databases was highlighted, also mentioned
as optional in the object-oriented database manifesto [5]. This observation
can extend to object-centric processes, where the object model itself may
change during a process, potentially affecting the process execution, similar
to process mining’s identification of concept drift. In object-centric process
mining, an object drift could induce concept drift later on. It might
therefore be interesting to investigate how to support this in object-centric
event log formats as well.

  7. 7.

Knowledge Graphs:  Whilst not discussed in the object-oriented databases
manifesto [5], knowledge graphs store entities as nodes, connected by
relations [20, 22]. They typically use tuples in the form (tail, relation,
head, sometimes (timestamp)), where tail and head are nodes. Knowledge graphs
are highly extensible, accommodating various node types. Consequently, they
can support updates in object information, complex objects, and object type
inheritance. In an object-centric context, this could involve distinct node
types for object types, events, and attributes. Therefore, knowledge graphs
seem to be able to accommodate for almost the above requirements.

The object-oriented database manifesto outlines additional mandatory features
such as computational completeness, which ensures any computational function
can be expressed in the database language, and database recovery. While
crucial for databases, these features are irrelevant for an object-centric
event log format.

####  2.3.1 Resulting Framework Specifications

From the databases research field, there is a strong interest in the O2O
dimension confirming the importance of the object-object specifications [5].
It mainly confirms that it is considered good practice to store object
information in that manner. Since object-oriented databases also support
object inheritance, further exploration of this concept in object-centric
process mining could be valuable. The following O2O dimensions are found from
the database research field:

  * •

Object relations can change over time

  * •

Supports object type inheritance

The first specification, highlighted in database studies [34] and data-aware
process modeling [25, 32], is exclusively featured in the ACEL object-centric
event log format proposal [28]. The last specification, allowing for object
type inheritance, was underscored in database proposals, considering its close
relation to data models [5, 9], though currently, none of the object-centric
event log formats supports this specification.

Next, we identify the following specifications in the Data Quality Dimension,
drawn from the process mining manifesto and the databases research field:

  * •

Data changes must be unambiguous

  * •

Data is uniquely identifiable

  * •

Data should be minimally duplicated

  * •

Data storage should be maximally scalable

The four data quality specifications address crucial aspects of data storage:
accuracy, uniqueness, consistency, and scalability. An object-centric event
log format should enable traceable value changes, ensure unique identification
of objects and events over time, minimize data duplication, and ensure
scalability of the event log itself.

##  3 Comparison of the different Object-Centric Event Log Formats

A framework for object-centric event log specifications is developed from the
previous analysis, consisting of four dimensions: E2E, O2O, E2O and Data
Quality. The first three dimensions align with the classification of object-
centric process techniques proposed in [8], while the Data Quality Dimension
is crucial considering the event log’s role in data storage. These
specifications represent common insights from different research fields, each
with its specific focus on object-centric processes or storage, and should be
viewed as results rather than requirements.

Table 1 compares various object-centric event log formats on the
specifications. A ✓ indicates support for the specification, while a X
indicates lack of support, with clarifications provided if necessary. The
comparison includes only object-centric event log formats and the OCED
standard, encompassing:

  * •

XOC[27]: XOC stores both object-centric data and the complete object model
alongside the event that triggered a change in the object model.

  * •

OCEL 1.0[14]: OCEL 1.0 was developed after XOC to address scalability issues.
It consists of an events table and an objects table. However, it does not
support dynamic attributes (attributes changing values over time) [17] or
object-object relations [28].

  * •

ACEL[28]: ACEL was developed after OCEL 1.0 and mainly addresses the need to
store object-object relationships within an object-centric process.

  * •

DOCEL[17]: DOCEL was developed after OCEL 1.0 and supports dynamic attributes
with the use of foreign keys.

  * •

OCEL 2.0[7]: The successor of OCEL 1.0 incorporates dynamic attributes using
timestamps and includes object relations in the objects table.

  * •

EKG[13]: Based on knowledge graphs, this storage formats creates node types
for events, attributes, timestamps and object types. These are then connected
to one another with the use of relations.

  * •

OCED: It is essential to note that OCED is currently a metamodel, not an
object-centric event log format. However, it is included in the comparison
because it is developed by the IEEE group responsible for XES, and several
event log formats, such as OCEL 2.0 and EKG drew inspiration from OCED.

The comparison therefore does not include the XES format [19] (which covers
all the E2E specifications but not the O2O or E2O dimensions) or other
interesting event log formats which solve specific issues such as IoT [10].

Table 1: Specifications of object-centric Event Log Formats

Specifications |  XOC [27] |  OCEL 1.0 [14] |  OCEL 2.0 [7] |  DOCEL [17] |  ACEL [28] | EKG[13] | OCED
---|---|---|---|---|---|---|---
E2E |  |  |  |  |  |  |
S1: An event must have a unique event ID | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
S2: An event must have a timestamp | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
S3: An event must have an activity | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
S4: An event can have other optional attributes | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
O2O |  |  |  |  |  |  |
S5: An object must have object type | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
S6: An object must have a unique objectID | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
S7: An object can have optional object attributes | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
| S8: An object can change values
---
and those are traceable
| X
---
(not traceable)
| X
---
(not traceable)
✓ | ✓ | ✓ | ✓ | ✓
| S9: An object instance can be
---
related to the other object instances
✓ | X | ✓ | X | ✓ | ✓ | ✓
S10: Supports relation qualifiers | X | X | ✓ | X | X | X | ✓
| S11: Object relations can change
---
over time (schema evolution)
X | X | X | X | ✓ | X | X
S12: Support object type inheritance | X | X | X | X | X | X | X
E2O |  |  |  |  |  |  |
S13: An event must be related to 1..N objects | X | ✓ | X | ✓ | X | X | X
S14: An object must be related to 1..N events | X | ✓ | X | ✓ | X | X | X
| S15: The process of an individual
---
object instance must be recoverable
✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
Data Quality Dimension |  |  |  |  |  |  |
S16: Data changes must be unambiguous | ✓ | X | X | ✓ | ✓ | ✓ | /
S17: Data is uniquely identifieable | ✓ | X | X | ✓ | ✓ | ✓ | /
S18: Data should be minimally duplicated | X | ✓ | ✓ | ✓ | ✓ | ✓ | /
S19: Data storage should be maximally scalable | X | ✓ | ✓ | ✓ | ✓ | ✓ | /

Regarding the E2E dimension, all the object-centric event logs formats agree
on the 4 specifications. For the O2O dimension, the different formats all
incorporate specifications S5 to S7. For specification S8, the idea is that an
object attribute can be changed and that it can be traced back. A key-point
here is that tracking attribute changes can be done with timestamps (OCEL
2.0), foreign keys (DOCEL or ACEL), or even object versions (XOC and OCEL 1.0)
but in case object versions are used it is important to know which object was
the previous version which neither XOC or OCEL 1.0 support. The next O2O
specification (S9) deals with storing the object relations an object instance
has. This specification is not supported by OCEL 1.0 and DOCEL. Regarding
specification S10, only the OCEL 2.0 supports relation qualifiers as
prescribed by OCED. For S11, ACEL is the only standard supporting schema
evolution whilst no event log format supports object type inheritance (S12).

Regarding the E2O dimension, the first two specifications (S13 and S14) deal
with a more constraint view of what can be stored in an object-centric event
log namely only events with an object or only objects with an event. This idea
is only required by two formats namely OCEL 1.0 and DOCEL. The other formats
allow also events and objects to be stored which are not related to objects
and events respectively to be stored. For S15, all event log formats allow to
recover the control-flow of a specific object instance.

Moving to the Data Quality dimension, S16 states that data changes must be
unambiguous however for OCEL 1.0 and OCEL 2.0 this is not guaranteed. Given
that in OCEL 1.0 attribute changes have to be stored with the events, it is
unclear to which object instance these changes apply [17]. For OCEL 2.0,
attribute value changes are given a timestamp but in case two events happen
simultaneously using the same object instance it is unclear which event is
responsible for this value change. This is also why OCEL 1.0 and OCEL 2.0 do
not follow specification S17. For S18, only XOC does not minimally duplicate
information given that for each event that updates an object relation, the
whole object model is returned which in turn makes the event log format not
very scalable and hence does not support specification S19 neither [14].
Regarding S19, two additional event log formats need to be discussed. OCEL 2.0
allows to store object relations but given that object models can be very
large this might get very quickly very large. The same observation goes for
ACEL where changing attribute values and relationship changes are stored
together with the events themselves which might also not scale very well. From
the previous observations, it is clear that storing object-object
relationships is a challenge when it comes to scalability but it comes with
the advantage of providing a more holistic overview of an object-centric
process.

##  4 Insights from the Comparison

####  4.0.1 Attribute value Changes

A first interesting insight is the fact that different object-centric event
log formats allow for attribute value changes but that they differ in their
implementation:

  * •

OCEL 2.0:  As explained in the previous section, OCEL 2.0 allows to link a
timestamp to an attribute value. This makes it possible to know when an
attribute value was changed. However, it does not guarantee that the event
responsible for this change can be known. In case an object instance is
involved in two events at the same time, it is not possible to know which
event is responsible for the attribute value change.

  * •

DOCEL:  In order to store changing object attribute values, DOCEL stores these
in a different table where it makes use of two foreign keys namely the object
ID to indicate to which object instance the changed value belongs to and the
event ID to indicate which event is responsible for the change.

  * •

ACEL:  In order to store changing attribute values, ACEL stores a subtable
containing the objectID, attribute and the new value, together in the event
row responsible for the change. Even though this solves the issue, ACEL also
stores in a similar manner the changing object-relationships making the
overall event table not adhering to the normalization principles limiting a
scalable and easy analysis [11].

  * •

EKG:  For EKGs it is possible to link an attribute value to an event or a
timestamp. Both are possible.

Regarding attribute value changes it seems that all the possible ways to store
these have been covered (including using object versions by XOC and OCEL 1.0).
Whether a certain way of storing these dynamic attributes is better mainly
depends on what exactly is the purpose of the final analysis. In case an
analysis focuses on both control-flow and the dynamic attributes, it is
important to know that certain event log formats do not allow to analyze
dynamic attribute changes.

####  4.0.2 Object Relations

Moving on to object-object relationships, it is clear from XOC that storing
complete object models with each event quickly causes scalability issues [17,
14]. However even with OCEL 2.0 and ACEL which also support the object-object
relations, scalability can not necessarily be guaranteed. The main reason for
this is that there is no clear policy on which object-object relationships
should be stored. First of all, it is unclear if and how the XOC and OCEL 2.0
proposals store transitive object-object relationships as this can cause
duplication. This makes it complicated to correctly derive an object model
from the stored relationships given that it is unclear which object relations
are directly or indirectly connected. Related to that is the storage of N:M
relationships because storing the object-object relationships on both sides
causes duplication of information. One possible way is to reify a N:M
relationship to a 1:N relationship [33]. Practically, this would mean that all
the object instances on N-side of the relationship store the object-instance
which is on the 1-side of the relationship. This would ensure scalability as
all the object-object relationships can be traced back correctly whilst
transitive relationships do not need to be stored anymore given that these can
be traced back anyhow. This proposal however does not support schema
evolution, but this could also be done with the use of dynamic attributes. In
turn, it would allow to analyze the impact a schema evolution has on the
object-centric process. A final aspect worth mentioning is that none of the
event log formats allow to indicate whether an object type is a subclass of
another object type. Adding this might however provide new insights as it
might be possible to discover what the typical process execution is for a
superclass whilst a subclass might have a specific process execution linked to
them. Of course, it is possible to analyze this by object type but is
currently not possible to know whether an object type A is a superclass of
object type B.

In short, it seems that with the current object-centric event log formats, the
O2O dimension still has the most to gain given, currently, that if an event
log format supports it, scalability is not always guaranteed. Next to that,
certain intricacies of object modeling such as schema evolution, relation
qualifiers and (especially) object type inheritance are not fully supported
yet even though these might provide interesting insights for an object-centric
process analysis.

####  4.0.3 Event-Object Relations

A third insight is that both OCEL 1.0 and DOCEL require that each event has at
least 1 object connected to it and each object is at least involved in one
event. Regarding the requirement that 1 event must have at least 1 object,
this stems from the fact in XES every event must be assigned a case. Therefore
a similar assumption is taken in OCEL 1.0 and DOCEL. But there is also the
possibility that an event is relevant for a process but not for a specific set
of objects. Secondly, regarding the requirement that an object must be
involved in at least 1 event, it might be that redundant process information
should not be stored in an object-centric event log. But of course, it is
possible that even though certain object instances are not directly involved
in an event these might be important through their relations with objects
which are directly involved in the process.

####  4.0.4 Final Remarks

Even though ACEL cover the most specifications, it unfortunately is not
practical for analysis as it is not sufficiently normalized [11]. Next, EKG
also cover a lot of specifications, but unfortunately do not have a wide
support on the analysis side as is concluded in [8] given that EKG can not
directly use algorithms based on tabular data given that EKG are knowledge
graphs in essence. In third place, there is OCEL 2.0 which sees more
applications from the research community but still lacks support for specific
specifications such as in the O2O dimension.

##  5 Proposed Object-Centric Event Log Refinements

According to the recent object-centric overview paper [8], OCEL 1.0 is
currently the object-centric event log format with the widest support for
database extraction and object-centric process analysis. Given that the latest
OCEL 2.0 iteration included object relations and dynamic relations on top of
what OCEL 1.0 supports, it is more than probable that OCEL 2.0 will be the
first object-centric event log format researchers will go to for an object-
centric analysis. Therefore, we propose a set of important but feasible
solutions to further improve OCEL 2.0:

  * •

Traceable Dynamic Attributes: Instead of using timestamps to trace attribute
changes, it might be better to use foreign keys linking to both the object
instance and event responsible for the change. This way, it is unambiguous
which event is responsible for a change where with the timestamp it might be
that two events happened simultaneously.

  * •

Scalable Object Relations: In order to ensure scalable object relations
storage, it would be beneficial, if possible, to reify all N:M object
relations to 1:N relations. Hence only a limited set of object relations need
to be stored whilst still being able to discover the complete object model
without storing the transitive object relations which might cause duplication.

  * •

Dynamic Object Relations: Finally, in order to support specification S18 for
changing object relations, a quick solution would be to consider object
relations as dynamic attributes which can also change over time. This way OCEL
2.0 would also support schema evolution.

By incorporating the previous suggestions, OCEL 2.0 would support all
dimensions namely E2E,O2O and E20 whilst keeping everything scalable and
traceable. On top of that, it would also support two additional relevant
specifications namely supporting schema evolution and relation qualifiers.

##  6 Limitations and Future Work

Even though the framework was constructed based on insights from multiple
research fields and validated by all the authors of this study, the framework
would of course benefit from a wider validation from the object-centric
process mining community. Another limitation is that the conclusions of this
study are based on the current insights from the investigated research fields.
Given that, especially, the object-centric process mining field is evolving
rapidly, future studies might make that certain specifications of the
framework should be updated or adapted. In the future, investigating how an
object-centric event log format can store more information whilst still
remaining scalable is certainly worth investigating. Especially, incorporating
more O2O specifications such as schema evolution and object type inheritance
whilst ensuring scalability is relevant.

##  7 Conclusion

This study began by noting the various object-centric event log formats
available for analyzing object-centric processes. It introduces a framework
for object-centric event log specifications, derived from analyzing three
pertinent research areas: process mining, object-centric process modeling, and
databases. Through a comparison with existing event log formats, several key
findings emerge. Firstly, it is clear that an object-centric event log format
should support the tracking of attribute value changes but this is currently
done in different ways each with their advantages and disadvantages. Secondly,
storing object-object relations is not an easy feat as it quickly generates
scalability issues. Related to that is that schema evolution is a well-
researched topic in databases and conceptual modeling but is not always
supported in object-centric event log formats (except one). Lastly, object
type inheritance is also highlighted as important in the databases and
conceptual modeling fields but is also not supported by any object-centric
event log format. With these insights, a set of feasible solutions to further
improve OCEL 2.0 is proposed.

## References

  * [1] van der Aalst, W.M.: Process mining: a 360 degree overview. In: Process Mining Handbook, pp. 3–34. Springer (2022)
  * [2] van der Aalst, W.M., Barthelmess, P., Ellis, C.A., Wainer, J.: Proclets: A framework for lightweight interacting workflow processes. International Journal of Cooperative Information Systems 10(04), 443–481 (2001)
  * [3] van der Aalst, W.M., Li, G., Montali, M.: Object-centric behavioral constraints. arXiv preprint arXiv:1703.05740 (2017)
  * [4] Adams, J.N., van der Aalst, W.M.: Oc $\pi$: Object-centric process insights. In: International Conference on Applications and Theory of Petri Nets and Concurrency. pp. 139–150. Springer (2022)
  * [5] Atkinson, M., Dewitt, D., Maier, D., Bancilhon, F., Dittrich, K., Zdonik, S.: The object-oriented database system manifesto. In: Deductive and object-oriented databases, pp. 223–240. Elsevier (1990)
  * [6] Augusto, A., Conforti, R., Dumas, M., La Rosa, M., Maggi, F.M., Marrella, A., Mecella, M., Soo, A.: Automated discovery of process models from event logs: Review and benchmark. IEEE transactions on knowledge and data engineering 31(4), 686–705 (2018)
  * [7] Berti, A., Koren, I., Adams, J.N., Park, G., Knopp, B., Graves, N., Rafiei, M., Liß, L., Unterberg, L.T.G., Zhang, Y., et al.: Ocel (object-centric event log) 2.0 specification (2023)
  * [8] Berti, A., Montali, M., van der Aalst, W.M.: Advancements and challenges in object-centric process mining: A systematic literature review. arXiv e-prints pp. arXiv–2311 (2023)
  * [9] Bertino, E., Martino, L.: Object-oriented database management systems: concepts and issues. Computer 24(4), 33–47 (1991)
  * [10] Bertrand, Y., Veneruso, S., Leotta, F., Mecella, M., Serral Asensio, E.: Nice: The native iot-centric event log model for process mining. In: Lecture Notes in Business Information Processing. Springer Verlag (Germany) (2023)
  * [11] Codd, E.F.: A Relational Model of Large Shared Data Banks (1970). In: Ideas That Created the Future: Classic Papers of Computer Science. The MIT Press (02 2021)
  * [12] van Dongen, B.F., Van der Aalst, W.M.: A meta model for process mining data. EMOI-INTEROP 160, 30 (2005)
  * [13] Fahland, D.: Process mining over multiple behavioral dimensions with event knowledge graphs. In: Process Mining Handbook, pp. 274–319. Springer (2022)
  * [14] Ghahfarokhi, A.F., Park, G., Berti, A., van der Aalst, W.: Ocel standard. Process and Data Science Group, RWTH Aachen University, techreport 1 (2020)
  * [15] Ghilardi, S., Gianola, A., Montali, M., Rivkin, A.: Petri net-based object-centric processes with read-only data. Information Systems 107, 102011 (2022)
  * [16] Goossens, A., De Smedt, J., Vanthienen, J.: Extracting process-aware decision models from object-centric process data. arXiv preprint arXiv:2401.14847 (2024)
  * [17] Goossens, A., De Smedt, J., Vanthienen, J., van der Aalst, W.M.: Enhancing data-awareness of object-centric event logs. In: Process Mining Workshops: ICPM 2022 International Workshops, Bozen-Bolzano, Italy, October 23–28, 2022, Revised Selected Papers. pp. 18–30. Springer (2023)
  * [18] Goossens, A., Verbruggen, C., Snoeck, M., De Smedt, J., Vanthienen, J.: Aligning object-centric event logs with data-centric conceptual models. In: van der Aa, H., Bork, D., Proper, H.A., Schmidt, R. (eds.) Enterprise, Business-Process and Information Systems Modeling. pp. 44–59. Springer Nature Switzerland, Cham (2023)
  * [19] Günther, C.W., Verbeek, H.M.W.: Xes standard definition. IEEE Std (2014)
  * [20] Hogan, A., Blomqvist, E., Cochez, M., d’Amato, C., Melo, G.D., Gutierrez, C., Kirrane, S., Gayo, J.E.L., Navigli, R., Neumaier, S., et al.: Knowledge graphs. ACM Computing Surveys (Csur) 54(4), 1–37 (2021)
  * [21] Hull, R., Damaggio, E., De Masellis, R., Fournier, F., Gupta, M., Heath III, F.T., Hobson, S., Linehan, M., Maradugu, S., Nigam, A., et al.: Business artifacts with guard-stage-milestone lifecycles: managing artifact interactions with conditions and events. In: Proceedings of the 5th ACM DEBS. pp. 51–62 (2011)
  * [22] Ji, S., Pan, S., Cambria, E., Marttinen, P., Yu, P.S.: A survey on knowledge graphs: Representation, acquisition, and applications. IEEE Transactions on Neural Networks and Learning Systems 33(2), 494–514 (2022)
  * [23] Kleijn, J., Koutny, M., Pietkiewicz-Koutny, M.: Regions of petri nets with a/sync connections. Theoretical Computer Science 454, 189–198 (2012)
  * [24] Künzle, V.: Object-aware process management. Ph.D. thesis, University of Ulm (2013)
  * [25] Künzle, V., Reichert, M.: Philharmonicflows: towards a framework for object-aware process management. Journal of Software Maintenance and Evolution: Research and Practice 23(4), 205–244 (2011)
  * [26] Li, G., de Carvalho, R.M., van der Aalst, W.M.: Automatic discovery of object-centric behavioral constraint models. In: Business Information Systems: 20th International Conference, BIS 2017, Poznan, Poland, June 28–30, 2017, Proceedings 20. pp. 43–58. Springer (2017)
  * [27] Li, G., Murillas, E.G.L.d., Carvalho, R.M.d., van der Aalst, W.: Extracting object-centric event logs to support process mining on databases. In: CAISE. pp. 182–199. Springer (2018)
  * [28] M’baba, L.M., Assy, N., Sellami, M., Gaaloul, W., Nanne, M.F.: Process mining for artifact-centric blockchain applications. Simulation Modelling Practice and Theory 127, 102779 (2023)
  * [29] OMG: Uml: Unified Modeling Language 2.5.1 (2017) (2017), https://www.omg.org/spec/UML/2.5.1/About-UML/, accessed: 2022-06-23
  * [30] Pelekis, N., Theodoulidis, B., Kopanakis, I., Theodoridis, Y.: Literature review of spatio-temporal database models. The Knowledge Engineering Review 19(3), 235–274 (2004)
  * [31] Snodgrass, R., et al.: Temporal databases. Computer 19(09), 35–42 (1986)
  * [32] Snoeck, M.: Enterprise information systems engineering. The MERODE Approach (2014)
  * [33] Snoeck, M., Dedene, G.: Existence dependency: The key to semantic integrity between structural and behavioral aspects of object types. IEEE Transactions on software engineering 24(4), 233–251 (1998)
  * [34] Stonebraker, M., Rowe, L.A., Lindsay, B.G., Gray, J., Carey, M.J., Brodie, M.L., Bernstein, P.A., Beech, D.: Third-generation database system manifesto. ACM sIGMOD record 19(3), 31–44 (1990)
  * [35] Van Der Aalst, W., Adriansyah, A., De Medeiros, A.K.A., Arcieri, F., Baier, T., Blickle, T., Bose, J.C., Van Den Brand, P., Brandtjen, R., Buijs, J., et al.: Process mining manifesto. In: Business Process Management Workshops: BPM 2011 International Workshops, Clermont-Ferrand, France, August 29, 2011, Revised Selected Papers, Part I 9. pp. 169–194. Springer (2012)
  * [36] van der Werf, J.M.E., Rivkin, A., Polyvyanyy, A., Montali, M.: Data and process resonance: Identifier soundness for models of information systems. In: International Conference on Applications and Theory of Petri Nets and Concurrency. pp. 369–392. Springer (2022)
  * [37] Wolfson, O., Xu, B., Chamberlain, S., Jiang, L.: Moving objects databases: Issues and solutions. In: Proceedings. Tenth International Conference on Scientific and Statistical Database Management (Cat. No. 98TB100243). pp. 111–122. IEEE (1998)