OCEL (Object-Centric Event Log) 2.0 Specification
Alessandro Berti, István Koren, Jan Niklas Adams,

Gyunam Park, Benedikt Knopp, Nina Graves, Majid Rafiei, Lukas Liß,

Leah Tacke Genannt Unterberg, Yisong Zhang, Christopher Schwanen, Marco
Pegoraro, Wil M.P. van der Aalst

Chair of Process and Data Science, RWTH Aachen University

<EMAIL_ADDRESS>
Version: 2.0

Date: October 16, 2023

Standard Document URL: https://www.ocel-
standard.org/2.0/ocel20_specification.pdf

Validation Schemes:

  * •

XML: https://www.ocel-standard.org/2.0/ocel20-schema-xml.xsd

  * •

JSON: https://www.ocel-standard.org/2.0/ocel20-schema-json.json

  * •

Relational: https://www.ocel-standard.org/2.0/ocel20-schema-relational.pdf

Object-Centric Event Logs (OCELs) form the basis for Object-Centric Process
Mining (OCPM). OCEL 1.0 was first released in 2020 and triggered the
development of a range of OCPM techniques. OCEL 2.0 forms the new, more
expressive standard, allowing for more extensive process analyses while
remaining in an easily exchangeable format. In contrast to the first OCEL
standard, it can depict changes in objects, provide information on object
relationships, and qualify these relationships to other objects or specific
events. Compared to XES, it is more expressive, less complicated, and better
readable. OCEL 2.0 offers three exchange formats: a relational database
(SQLite), XML, and JSON format. This OCEL 2.0 specification document provides
an introduction to the standard, its metamodel, and its exchange formats,
aimed at practitioners and researchers alike.

###### Contents

  1. 1 Scope and Structure of this Document
  2. 2 Introduction to Object-Centric Process Mining
  3. 3 Metamodel of the OCEL 2.0 Standard
  4. 4 Formal Definitions
  5. 5 Running Example
  6. 6 Relational SQLite Format
    1. 6.1 Tables for the Distinct Event/Object Types
    2. 6.2 Events and Objects Tables
    3. 6.3 Event Type Tables
    4. 6.4 Object Type Tables
    5. 6.5 Event-to-Object (E2O) Relationships
    6. 6.6 Object-to-Object (O2O) Relationships
    7. 6.7 Constraints on the Relational Implementation
  7. 7 XML Format
    1. 7.1 XML Example
    2. 7.2 XML Schema Definition
  8. 8 JSON Format
    1. 8.1 JSON Example
    2. 8.2 JSON Schema Definition
  9. 9 Conclusion

##  1 Scope and Structure of this Document

This document introduces the OCEL 2.0 standard to record and exchange object-
centric event logs. The purpose of the standard is to guide the implementation
of conformant process mining tools, and to provide the basis for the
development of training material and other resources for users.

OCEL 2.0 and its metamodel are designed from the ground up to facilitate the
exchange of event logs coming from a wide variety of information systems.
Unlike traditional exchange formats, events may refer to any number of objects
of different types. It is intended to be interoperable with data extracted
from a wide variety of databases, systems, or applications. Likewise, the
format aims to be equally compatible with existing and emerging Object-Centric
Process Mining (OCPM) techniques. It is anticipated that OCEL 2.0 will become
the default exchange format for OCPM tools, whether these are research
prototypes or commercial tools.

This document is structured as follows. Section 2 explains object-centric
process mining and discusses the limitations of current standards for
recording object-centric event logs. Section 3 introduces the OCEL 2.0
standard and discusses its advantages over past object-centric standardization
attempts. Section 4 contains the formal definitions of the standard. Section 5
illustrates OCEL 2.0 using a running example. Sections 6, 7 and 8 describe the
practical implementation of the standard, using relational, XML, and JSON
formats, respectively. Finally, Section 9 concludes this document.

##  2 Introduction to Object-Centric Process Mining

The first process mining algorithms were developed in the late 1990-ties [1,
4]. Initially, adoption was limited, with just a handful of researchers
working on the topic. However, over time, the field matured. Currently, there
are over 40 vendors offering process mining software (cf.
www.processmining.org) and advisory firms such as Gartner consider these to
form a new and substantial category of tools [11]. Many of the world’s largest
companies already use process mining to improve their operational processes
(across all economic sectors), and adoption is expected to increase in the
coming years. The increasing maturity of the process-mining discipline is also
reflected by the success of the International Conference on Process Mining
(ICPM) and the large number of process-mining papers in other conferences
(e.g., BPM and CAiSE) and journals.

However, traditional process mining considers processes involving single
cases, their events, and event attributes. The approach falls short when
dealing with complex, multi-dimensional processes, where events possibly
relate to a variety of entities or objects that interact and evolve over time
[2]. Traditional event data are based on the assumption that each event refers
to precisely one case. The same applies to mainstream process modeling
notations like Directly-Follows-Graphs (DFGs), BPMN models, UML activity
diagrams, workflow nets, and process trees. However, most real-life events
involve multiple objects. Traditional process mining approaches require the
flattening of event data in order to satisfy this assumption. This may lead to
misleading analysis results. Process mining results also tend to become more
complex because different objects get intertwined while trying to straitjacket
the processes. Changing the viewpoint (e.g., looking at the process from a
different angle) also implies changing the case notion and going back to the
source systems to extract other event data. This leads to redundancies in
event data and unnecessary repetitions. Moreover, many compliance and
performance problems arise at the intersection points of processes, systems,
and organizations.

_Object-Centric Process Mining_ (OCPM) represents a paradigm shift, intended
to address and overcome the inherent limitations of traditional case-centric
process mining methods [2]. OCPM starts from the actual events and objects
that leave traces in ERP (Enterprise Resource Planning), CRM (Customer
Relationship Management), MES (Manufacturing Execution System), and other IT
systems. In the databases of such systems, one-to-one relationships are the
exception. Most relationships are one-to-many or many-to-many. As a result,
data need to be transformed to be able to assign events to a single case,
leading to all the problems mentioned before. Therefore, there is consensus
among experienced process miners that Object-Centric Event Data (OCED) provide
a much better abstraction of reality than the classical case-based event logs.
OCEL 1.0, released in 2020 [7], was the first standard for storing OCED and
triggered the development of OCPM techniques (e.g., discovering object-centric
process models). OCEL 2.0 extends OCEL 1.0, leveraging experiences gathered
while developing and applying these OCPM techniques.

Before discussing in what way OCEL 2.0 extends OCEL 1.0, we first need to
introduce some terminology and basic concepts.

  * •

_Events_ : Object-centric process mining works on discrete events. They
represent the various actions or activities that occur within a system or
process, such as approving an order, shipping an item, or making a payment.
Every event is unique and corresponds to a specific action or observation at a
specific point in time. Events are atomic (i.e., do not take time), have a
timestamp, and may have additional attributes. Events are typed.

  * •

_Event Types_ : Events are categorized into different types based on their
nature or function. For example, a procurement process might have event types
such as Order Created, Order Approved, or Invoice Sent. Each type of event
represents a specific kind of action that can take place in the process. Each
event is of exactly one type. Sometimes, we use the term activity to refer to
an event type.

  * •

_Objects_ : In object-centric process mining, objects represent the entities
that are involved in events. These might be physical items like products in a
supply chain, machines, workers, or abstract/information entities like orders,
invoices, or contracts in a procurement process. Objects have attributes with
values, e.g., prices. These values may change over time.

  * •

_Object Types_ : Each object is of one type. The object is an instantiation of
its type. Object types might include categories like Product, Order, Invoice,
or Supplier.

Events and objects may be related. In particular, OCPM techniques exploit the
following two relationships.

  * •

_Event-to-Object (E2O) Relationships_ : Events are associated with objects.
This relationship describes that an object affects an event or that an event
affects an object. In contrast to traditional event logs, events can be
related to multiple objects. Furthermore, these relationships can be qualified
differently, describing the role an object plays in the occurrence of this
specific event. Consider, for example, a meeting event involving multiple
participant objects. Using a qualifier, it is possible to distinguish between
regular participants and the organizer of the meeting.

  * •

_Object-to-Object (O2O) Relationships_ : Objects can also be related to other
objects outside the context of an event. For example, an employee may be part
of an organizational unit. In addition to the mere existence of a relation,
this relationship can also be qualified (e.g., part-of, reports-to, or
belongs-to).

Recent standardization attempts have addressed some but not all of these
requirements. The first OCEL format (OCEL 1.0) provided an event log standard
that could capture events related to multiple objects with attributes but did
not include Object-to-Object (O2O) relationship, qualifiers for either O2O and
E2O relationships, or changing object attribute values [7, 8]. OCEL 2.0
addresses these limitations by providing a new metamodel and three storage
formats, including a relational implementation of the standard. We will
address OCEL 1.0, its limitations, and how OCEL 2.0 enriches the metamodel of
OCEL 1.0 in more detail in the following section.

##  3 Metamodel of the OCEL 2.0 Standard

Standards for storing object-centric event data serve as a crucial backbone in
managing and analyzing complex process data. They provide a coherent, uniform,
and structured approach to representing, storing, and exchanging event data
across multiple systems, platforms, and applications. The adoption of a
standard has several significant benefits:

  * •

_Interoperability_ : a standard promotes seamless data interchange between
diverse systems. It eliminates data silos by ensuring that event logs are
represented in a universally understandable format.

  * •

_Scalability_ : a well-structured standard allows efficient handling of data,
enabling it to scale with increasing complexity and volume. It ensures that
the data remains manageable, reducing the overhead of dealing with
unstructured or inconsistently structured logs.

  * •

_Data Integrity and Consistency_ : the standardization of event logs upholds
the consistency and integrity of data across different sources. It provides a
uniform structure to data, making it less prone to inconsistencies and errors,
thereby improving the overall data quality.

  * •

_Simplifies Analysis_ : by adhering to a standard, the interpretation and
analysis of event logs are significantly simplified. It enables the use of
standard analysis tools and methods, fostering easy comparability and
benchmarking of results.

  * •

_Future-Proofing_ : standards also future-proof data, ensuring that it remains
accessible, reusable, and comprehensible even as technologies evolve.

The first comprehensive standard for storing event data was the IEEE Standard
for eXtensible Event Stream (XES) [10]. XES became an official IEEE standard
in 2016 [5]. The revised standard (IEEE 1849-2023) was published on 8
September 2023 and will be valid for another ten years [9]. XES has played a
major role in the development of the field. However, within the process mining
community, there seems to be a consensus that a paradigm shift is needed. The
development and adoption of a standard for storing object-centric event data
are vital for realizing the full potential of process mining and other data-
driven analytics methods. It paves the way for more effective, efficient, and
reliable data management and analysis strategies.

The first version of the object-centric event log standard, OCEL 1.0, was a
big step forward for object-centric process mining [7, 8]. It can store
various types of events and objects in one log and link objects of different
types to each event, giving a more detailed picture. OCEL 1.0 also allowed for
adding multiple attributes to each event and object, providing even more
information. This made data analysis deeper and more insightful. We provided
OCEL 1.0 specifications in both JSON and XML formats. Several OCEL 1.0 data
sets were provided and the availability of the standard fueled the development
of a range of OCPM techniques, e.g., discovering object-centric Petri nets,
discovering object-centric DFGs, checking conformance on object-centric
process models, clustering object-centric event data, object-centric
predictive methods, etc. [2, 6, 3].

Although OCEL 1.0 can be considered a success, the time has come to extend the
standard. OCEL 1.0 has a few deliberate limitations. In 2020, there were
hardly any OCPM techniques, and the goal was to keep the standard as simple
and lean as possible. However, with the rapid development of the field, the
first OCEL standard can now be perceived as an incomplete solution for object-
centric process mining. In 2021, a survey was conducted by the IEEE Task Force
on Process Mining [12]. The goal was to collect requirements for a new
standard succeeding XES. The online survey with 289 participants, spanning the
roles of practitioners, researchers, software vendors and end-users, showed
the need for supporting object-centricity. This resulted in the so-called
“OCED Working Group” of the IEEE Task Force on Process Mining. Input for the
discussion was an early version of the OCEL 2.0 metamodel (similar to the
model in [2]). Unfortunately, the discussions in the OCED Working Group did
not converge after 1.5 years of discussion. This was due to conflicting
requirements (expressiveness versus simplicity), different implementation
paradigms (relational versus graph-based), and a lack of clarity on who would
implement things. Therefore, after a delay of two years, the OCEL team decided
to release OCEL 2.0, including example event logs, reference implementations,
libraries, and documentation. OCEL 2.0 aims to strike a middle ground between
simplicity and expressiveness.

Figure 1: OCEL 2.0 metamodel

Figure 1 shows the meta model using a simplified UML-like notation (just using
classes, associations, and multiplicities). Compared to OCEL 1.0 there are
several commonalities. There are objects and events, and these are typed.
Events have a timestamp and any number of additional attributes. Also, objects
can have attributes. There is a many-to-many relationship between events and
objects. There are also several differences. OCEL 2.0 was extended to address
the limitations discussed before.

  * •

_Object-to-Object (O2O) Relationships_ : OCEL 2.0 allows a deeper
understanding of how objects interact within a business process. It shows that
objects are part of a complex network of relationships and actions. Capturing
these relationships can reveal insights about process performance and
inefficiencies and allows for advanced analytics techniques like network
analysis and predictive modeling.

  * •

_Dynamic Object Attribute Values_ : OCEL 2.0 adopts a dynamic approach where
attribute values can change over time. Instead of having a single, fixed
value, an object attribute may have a value that changes during the process.
This gives a more realistic view of process instances by recognizing that
object attributes change over time due to events and progression.

  * •

_Relationship Qualifiers_ : OCEL 2.0 offers capabilities to express qualifiers
for relationships, both for Object-to-Object (O2O) and Event-to-Object (E2O)
relationships. E2O relationship qualifiers describe in which role an object
takes part in an event, while O2O relationship qualifiers can further
characterize the association between two objects.

Apart from these conceptual extensions, the specifications have been enhanced.
This makes the standard more scalable and easier to use in practical
situations (e.g., in the context of a relational database). Notable
differences are:

  * •

_Relational Specification based on Dense Tables_ : One major feature of OCEL
2.0 is its data structure using dense tables. Each table corresponds to a
unique event or object type, storing only relevant attributes. This results in
efficient use of storage space and less data redundancy. It also scales well,
allowing for easy addition of new event or object types. The separate tables
make the data more accessible and easy to understand, improving both
efficiency and analysis in process mining.

  * •

_Improved XML Specification_ : The XML specification in OCEL 2.0 has been
significantly upgraded to handle complex data better. Essential information
for events and objects is now directly within the corresponding tags, making
the data more readable. It also includes the ability to show object-to-object
relationships and track attribute changes over time, providing a better view
of how objects evolve.

##  4 Formal Definitions

The metamodel Figure 1 is supported by a formalization that adds more details.
The theoretical foundation is crucial for understanding and using OCEL 2.0.
These definitions form the basis for concrete exchange formats discussed
later. The connection between theory and practice ensures that both the
relational model and XML schema respect the standard’s principles, enhancing
its usefulness for object-centric event logging. Readers will see how these
concepts turn into practical solutions, improving their understanding and use
of OCEL 2.0 in process mining. We also encourage authors writing scientific
papers using OCEL 2.0 to adopt these formal definitions and thus improve
reliability.

First, Definition 1 introduces some concepts (universes) needed in the
remainder.

######  Definition 1 (Universes).

Let $\mathbb{U}_{\mathit{\Sigma}}$ be the universe of strings. We define the
following pairwise disjoint universes:

  * •

$\mathbb{U}_{\mathit{ev}}\subseteq\mathbb{U}_{\mathit{\Sigma}}$ is the
universe of events.

  * •

$\mathbb{U}_{\mathit{etype}}\subseteq\mathbb{U}_{\mathit{\Sigma}}$ is the
universe of event types (i.e., activities).

  * •

$\mathbb{U}_{\mathit{obj}}\subseteq\mathbb{U}_{\mathit{\Sigma}}$ is the
universe of objects.

  * •

$\mathbb{U}_{\mathit{otype}}\subseteq\mathbb{U}_{\mathit{\Sigma}}$ is the
universe of object types.

  * •

$\mathbb{U}_{\mathit{attr}}\subseteq\mathbb{U}_{\mathit{\Sigma}}$ is the
universe of attribute names.

  * •

$\mathbb{U}_{\mathit{val}}$ is the universe of attribute values.

  * •

$\mathbb{U}_{\mathit{time}}$ is the universe of timestamps (with
$0\in\mathbb{U}_{\mathit{time}}$ as the smallest element and
$\infty\in\mathbb{U}_{\mathit{time}}$ as the largest element)

  * •

$\mathbb{U}_{\mathit{qual}}\subseteq\mathbb{U}_{\mathit{\Sigma}}$ is the
universe of qualifiers.

Note that the universes are assumed to be pairwise disjoint, i.e., objects
cannot be used as events, etc. $e\in\mathbb{U}_{\mathit{ev}}$ will be used to
denote an event, $et\in\mathbb{U}_{\mathit{etype}}$ will be used to denote an
event type, $o\in\mathbb{U}_{\mathit{obj}}$ will be used to denote an object,
$ot\in\mathbb{U}_{\mathit{otype}}$ will be used to denote an object type,
$ea\in\mathbb{U}_{\mathit{attr}}$ will be used to denote an event attribute,
$oa\in\mathbb{U}_{\mathit{attr}}$ will be used to denote an object attribute,
$v\in\mathbb{U}_{\mathit{val}}$ will be used to denote an attribute value,
$t\in\mathbb{U}_{\mathit{time}}$ will be used to denote a timestamp, and
$q\in\mathbb{U}_{\mathit{qual}}$ will be used to denote a qualifier.

We assume a total ordering on timestamps, with
$0\in\mathbb{U}_{\mathit{time}}$ as the earliest timestamp and
$\infty\in\mathbb{U}_{\mathit{time}}$ as the latest timestamp (i.e., for any
$t\in\mathbb{U}_{\mathit{time}}$: $0\leq t\leq\infty$). These are added for
notational convenience, e.g., we can use $0$ for missing timestamps and the
start of the process, and $\infty$ as the end time. We would like to emphasize
that these two reference timestamps (i.e., $0$ and $\infty$) are chosen for
convenience. In the formalization, time is mapped on the non-negative reals,
but concrete implementations will use, for example, the ISO 8601 time format.

Definition 2 provides the formal definition for object-centric event logs,
describing all the basic concepts introduced in Section 2 (events, objects,
event types, object types, and event-to-object relationships), and introducing
object-to-object relationships and dynamic object attribute values.

######  Definition 2 (OCEL).

An Object-Centric Event Log (OCEL) is a tuple $L=(E,O,EA,$
$OA,\textrm{evtype},\textrm{time},\textrm{objtype},\textrm{eatype},\textrm{oatype},\textrm{eaval},\textrm{oaval},\textrm{E2O},\textrm{O2O})$
with

  * •

$E\subseteq\mathbb{U}_{\mathit{ev}}$ is the set of events.

  * •

$O\subseteq\mathbb{U}_{\mathit{obj}}$ is the set of objects.

  * •

$\textrm{evtype}:E\rightarrow\mathbb{U}_{\mathit{etype}}$ assigns types to
events.

  * •

$\textrm{time}:E\rightarrow\mathbb{U}_{\mathit{time}}$ assigns timestamps to
events.

  * •

$\textrm{EA}\subseteq\mathbb{U}_{\mathit{attr}}$ is the set of event
attributes.

  * •

$\textrm{eatype}:EA\rightarrow\mathbb{U}_{\mathit{etype}}$ assigns event types
to event attributes.

  * •

$\textrm{eaval}:(E\times EA)\not\rightarrow\mathbb{U}_{\mathit{val}}$ assigns
values to event attributes (not all the attributes are mapped for each event).

  * •

$\textrm{objtype}:O\rightarrow\mathbb{U}_{\mathit{otype}}$ assigns types to
objects.

  * •

$OA\subseteq\mathbb{U}_{\mathit{attr}}$ is the set of object attributes.

  * •

$\textrm{oatype}:OA\rightarrow\mathbb{U}_{\mathit{otype}}$ assigns object
types to object attributes.

  * •

$\textrm{oaval}:(O\times
OA\times\mathbb{U}_{\mathit{time}})\not\rightarrow\mathbb{U}_{\mathit{val}}$
assigns values to object attributes.

  * •

$E2O\subseteq E\times\mathbb{U}_{\mathit{qual}}\times O$ are the qualified
event-to-object relations.

  * •

$O2O\subseteq O\times\mathbb{U}_{\mathit{qual}}\times O$ are the qualified
object-to-object relations.

such that

  * •

$\textrm{dom}(\textrm{eaval})\subseteq\\{(e,ea)\in E\times
EA~{}\arrowvert~{}\textrm{evtype}(e)=\textrm{eatype}(ea)\\}$ to ensure that
only existing event attributes can have values.

  * •

$\textrm{dom}(\textrm{oaval})\subseteq\\{(o,oa,t)\in O\times
OA\times\mathbb{U}_{\mathit{time}}~{}\arrowvert~{}\textrm{objtype}(o)=\textrm{oatype}(oa)\\}$
to ensure that only existing object attributes can have values.

The stipulations embedded in the final two criteria of the definition ensure
that each event and object is limited to possessing attribute values pertinent
to its respective event or object type. Additionally, these guidelines also
mandate that the set of attributes is distinct and non-overlapping for each
individual event and object type, guaranteeing a disjoint attribute set across
all types.

In order to facilitate the following examples and explanations, we introduce
the following notations given an OCEL $L$:

  * •

$ET(L)=\\{\textrm{evtype}(e)~{}\arrowvert~{}e\in E\\}$ is the set of event
types.

  * •

$OT(L)=\\{\textrm{objtype}(o)~{}\arrowvert~{}o\in O\\}$ is the set of object
types.

  * •

For any event $e\in E$ and event attribute
$\textrm{ea}\in\mathbb{U}_{\mathit{attr}}$:

    * –

$\textrm{eaval}_{ea}(e)=\textrm{eaval}(e,ea)$ if
$(e,ea)\in\textrm{dom}(\textrm{eaval})$.

    * –

$\textrm{eaval}_{ea}(e)=\bot$ if $(e,ea)\not\in\textrm{dom}(\textrm{eaval})$.

  * •

For any object $o\in O$, object attribute
$\textrm{oa}\in\mathbb{U}_{\mathit{attr}}$ and time
$t\in\mathbb{U}_{\mathit{time}}$:

    * –

$\textrm{oaval}_{oa}^{t}(o)=\textrm{oaval}(o,oa,t^{\prime})$ if there exists a
$t^{\prime}\in\mathbb{U}_{\mathit{time}}$ such that $t^{\prime}\leq t$ and
$(o,oa,t^{\prime})\in\textrm{dom}(\textrm{oaval})$ such that there is no
$t^{\prime\prime}\in\mathbb{U}_{\mathit{time}}$ such that
$t^{\prime}<t^{\prime\prime}\leq t$ and
$(o,oa,t^{\prime\prime})\in\textrm{dom}(\textrm{oaval})$.

    * –

If no such $t^{\prime}$ exists, then $\textrm{oaval}_{oa}^{t}(o)=\bot$.

Hence, $\textrm{oaval}_{oa}^{t}$ provides us with the latest object attribute
value at time $t$.

  * •

$\textrm{oaval}_{oa}(o)=\textrm{oaval}_{oa}^{\infty}(o)$ is the final value
for the object attribute in the event log.

Note that oaval describes object attribute updates at particular points in
time. Function $\textrm{oaval}_{oa}^{t}(o)$ allows us to determine the value
of object attributes at any point in time, thus clarifying the semantics. A
missing timestamp for a value assignment can be interpreted as time $0$. If
this is the only value assignment for an object-attribute combination, then
the value for an object attribute is always the same. This way, we can handle
static object-attribute values.

Figure 2: Linking the OCEL 2.0 metamodel to the formalization in Definition 2.

Object attribute values are deliberately not connected to events. The
definition allows for events without objects or objects without events. Events
should correspond to relevant activities, and therefore, there should not be
the need to promote individual object attribute changes to events. Also, the
object-to-object relations may exist independent of events. The only explicit
connections between events and objects are the event-to-object relations
(i.e., _E2O_). However, for an event $e$ happening at time $t$ involving
object $o$ with attribute oa we can look up the corresponding value at the
time of the event via $\textrm{oaval}_{oa}^{t}(o)$. Hence, there is no
limitation.

Figure 2 links the OCEL metamodel in Figure 1 to the formalization just
provided. Sections 6, 7, and 8 map the formalization onto concrete relational,
XML, and JSON formats.

##  5 Running Example

In order to visualize the concepts of Definition 2 and propose some
implementations of OCEL 2.0, we describe an example object-centric setting
supporting the following situations:

  1. 1.

A purchase requisition (PR1) is created and approved, requesting $500$ cows,
and a purchase order (PO1) is created on top of the purchase requisition. The
quantity of the purchase order PO1 is then changed to $600$ cows. Two invoices
R1 and R2 are received (for the first $500$ cows and for the additional $100$
cows), which are paid separately by the payments P1 and P2.

  2. 2.

Mario is an unethical employee who places purchase orders of notebooks without
getting proper approval. An invoice R3 is received before an order PO2 is
formally inserted in the system. Therefore, Sam, who is a financial
controller, blocks the payment of the invoice. However, Mario manages to
override Sam and puts himself as an approver of the invoice; therefore, the
invoice is paid in the P4 payment.

In this example, the attributes at the object level evolve, highlighting one
of the main features of OCEL 2.0. Also, we provide qualified event-to-object
and object-to-object relationships, specifically in Table 20 and Table 21,
highlighting the other main novelties.

For this example:

  * •

We identify the following sets (in relation to Definition 2):

    * –

(sets of objects)
$O=\\{\textbf{PR1},\textbf{PO1},\textbf{R1},\textbf{R2},\textbf{P1},\textbf{P2},\textbf{R3},\textbf{PO2},\textbf{R3},\textbf{P3}\\}$.

    * –

(sets of events) $E=\\{e1,e2,e3,e4,e5,e6,e7,e8,e9,e10,e11,e12,e13\\}$.

    * –

(sets of attributes at the event level) $EA=\\{\textrm{pr\\_creator},\\\
\textrm{pr\\_approver},\textrm{po\\_creator},\textrm{po\\_editor},\textrm{invoice\\_inserter},\textrm{invoice\\_blocker},\\\
\textrm{invoice\\_block\\_rem},\textrm{payment\\_inserter}\\}$ where:

      * *

pr_creator is the resource that created the purchase requisition in the
system.

      * *

pr_approver is the resource that approved the purchase requisition in the
system.

      * *

po_creator is the resource that created the purchase order in the system.

      * *

po_editor is the resource that changed some parameters of the purchase order.

      * *

invoice_inserter is the resource that inserted the invoice in the system.

      * *

invoice_blocker is the resource that blocked the payment of a given invoice.

      * *

invoice_block_rem is the resource that removed the payment block.

      * *

payment_inserter is the resource that performed the payment.

    * –

(sets of attributes at the object level)
$OA=\\{\textrm{pr\\_product},\textrm{pr\\_quantity},\textrm{po\\_product},\textrm{po\\_quantity},\textrm{is\\_blocked}\\}$
where:

      * *

pr_product is the product requested in the purchase requisition.

      * *

pr_quantity is the quantity requested in the purchase requisition.

      * *

po_product is the product bought in the purchase order.

      * *

po_quantity is the quantity bought in the purchase order.

      * *

is_blocked relates to a payment block on the invoice.

  * •

The object types corresponding to the given objects (objtype in Definition 2)
are described in Table 1. Moreover, the attributes defined for the object
types (oatype in Definition 2) are also described in Table 1.

  * •

The event types are described in Table 2, along with the corresponding
attributes (eatype in Definition 2) and event identifiers.

  * •

A high-level tabular view is provided in Table 3. In particular, the event
type (evtype in Definition 2) and timestamp (time in Definition 2) of each
event is defined.

Table 1: High-level view on the object types of the object-centric event log (running example). Object Type | Attributes | Object IDs
---|---|---
Purchase Requisition | pr_product, pr_quantity | PR1
Purchase Order | po_product, po_quantity | PO1, PO2
Invoice | is_blocked | R1, R2, R3
Payment | $\emptyset$ | P1, P2
Table 2: High-level view on the event types of the object-centric event log (running example). Event Type | Attributes | Event IDs
---|---|---
Create Purchase Requisition | pr_creator | e1
Approve Purchase Requisition | pr_approver | e2
Create Purchase Order | po_creator | e3, e10
Change PO Quantity | po_editor | e4
Insert Invoice | invoice_inserter | e5, e6, e9
Set Payment Block | invoice_blocker | e11
Remove Payment Block | invoice_block_rem | e12
Insert Payment | payment_inserter | e7, e8, e13
Table 3: High-level tabular view on the object-centric event log (running example), showing the list of events along with the related objects. In this view, no event/object attribute is reported, no qualifier is reported (see Table 20 for the event-to-object relationships qualifiers), and no object-to-object relationship is described. Event ID | Event Type | Timestamp | Related Objects
---|---|---|---
e1 | Create Purchase Requisition | 2022-01-09 15:00 | PR1
e2 | Approve Purchase Requisition | 2022-01-09 16:30 | PR1
e3 | Create Purchase Order | 2022-01-10 09:15 | PR1, PO1
e4 | Change PO Quantity | 2022-01-13 12:00 | PO1
e5 | Insert Invoice | 2022-01-14 12:00 | PO1, R1
e6 | Insert Invoice | 2022-01-16 11:00 | PO1, R2
e7 | Insert Payment | 2022-01-30 23:00 | R1, P1
e8 | Insert Payment | 2022-01-31 22:00 | R2, P2
e9 | Insert Invoice | 2022-02-02 09:00 | R3
e10 | Create Purchase Order | 2022-02-02 17:00 | R3, PO2
e11 | Set Payment Block | 2022-02-03 07:30 | R3
e12 | Remove Payment Block | 2022-02-03 23:30 | R3
e13 | Insert Payment | 2022-02-28 23:00 | R3, P3
Figure 3: General relational schema of the proposed relational implementation.

##  6 Relational SQLite Format

Figure 4: Relational schema of the running example OCEL 2.0 log.

We propose a relational implementation of the standard, which adheres to
Definition 2. In this implementation, starting from an object-centric event
log $L$, we have:

  * •

We have a table, event_map_type, reporting the distinct event types ($ET(L)$);
and a table, object_map_type, reporting the distinct object types ($OT(L)$).

  * •

We have a table, event, reporting the event type (evtype in Definition 2) for
each event, and a table, object, reporting the object type (objtype in
Definition 2) for each object. This is described in Subsection 6.2.

  * •

For every event type in $ET(L)$, we have a different table. More specifically,
if $\textrm{et}\in ET(L)$ is the event type, we have a table called
event_$\oplus$$map_{ET}$(et), where
$map_{ET}:ET(L)\rightarrow\mathbb{U}_{\mathit{\Sigma}}$ is an injective
function111Which can be the identity function. mapping the event types to
unique identifiers, containing the events of the given event type along with
their timestamp and attributes. This is described in Subsection 6.3.

  * •

For every object type in $OT(L)$, we have a different table. More
specifically, if $ot\in OT(L)$ is the object type, we have a table called
object_$\oplus$$map_{OT}$(ot), where
$map_{OT}:OT(L)\rightarrow\mathbb{U}_{\mathit{\Sigma}}$ is an injective
function222Which can be the identity function. mapping the object types to
unique identifiers, containing the objects of the given object type along with
the history of their attributes. This is described in Subsection 6.4.

  * •

We have a table, event_object, containing the event-to-object relationships
(E2O in Definition 2). This is described in Subsection 6.5.

  * •

We have a table, object_object, containing the object-to-object relationships
(O2O in Definition 2). This is described in Subsection 6.6.

A general representation of the relational schema of OCEL 2.0 is portrayed in
Figure 3. The overall relational schema of the running example OCEL 2.0 log is
shown in Figure 4.

###  6.1 Tables for the Distinct Event/Object Types

In our implementation, we define the table event_map_type (Table 4) defining
the event types along with their unique identifier obtained by applying the
injective function $map_{ET}:ET(L)\rightarrow\mathbb{U}_{\mathit{\Sigma}}$.
This unique identifier is used to link the event type to a table containing
the attributes of the events of the given event type (see Subsection 6.3). The
event type should be set as the primary key to avoid duplication.

Table 4: [Proposed relational implementation] Distinct event types: event_map_type ocel_type [PK] | ocel_type_map
---|---
Approve Purchase Requisition | ApprovePurchaseRequisition
Change PO Quantity | ChangePOQuantity
Create Purchase Order | CreatePurchaseOrder
Create Purchase Requisition | CreatePurchaseRequisition
Insert Invoice | InsertInvoice
Insert Payment | InsertPayment
Remove Payment Block | RemovePaymentBlock
Set Payment Block | SetPaymentBlock

Also, the table object_map_type (Table 5) defines the object types along with
their unique identifier obtained applying the injective function
$map_{OT}:OT(L)\rightarrow\mathbb{U}_{\mathit{\Sigma}}$. This unique
identifier is used to link the object type to a table containing the
attributes of the objects of the given object type (see Subsection 6.4). The
object type should be set as the primary key to avoid duplication.

Table 5: Proposed relational implementation: Distinct object types ocel_type [PK] | ocel_type_map
---|---
Invoice | Invoice
Payment | Payment
Purchase Order | PurchaseOrder
Purchase Requisition | PurchaseRequisition

###  6.2 Events and Objects Tables

In the proposed implementation, we use several tables to store information
related to an event/object type. However, we also create two additional
tables, hosting the event/object identifiers. This is done to map the
event/object to a specific event/object type table, and to allow for the
definition of E2O/O2O tables with proper foreign keys (directed towards the
events and the objects tables).

This is done in Table 6 (having the event identifier, _ocel_id_ , as primary
key) and Table 7 (having the object identifier, _ocel_id_ , as primary key).

Table 6: [Proposed Relational Implementation] General Events Table
event ocel_id [PK] | ocel_type FK
---|---
e1 | Create Purchase Requisition
e2 | Approve Purchase Requisition
e3 | Create Purchase Order
e4 | Change PO Quantity
e5 | Insert Invoice
e6 | Insert Invoice
e7 | Insert Payment
e8 | Insert Payment
e9 | Insert Invoice
e10 | Create Purchase Order
e11 | Set Payment Block
e12 | Remove Payment Block
e13 | Insert Payment
Table 7: [Proposed Relational Implementation] General Objects Table
object ocel_id [PK] | ocel_type FK
---|---
PR1 | Purchase Requisition
PO1 | Purchase Order
PO2 | Purchase Order
R1 | Invoice
R2 | Invoice
R3 | Invoice
P1 | Payment
P2 | Payment

###  6.3 Event Type Tables

Having defined the table event as the general table for the events (having the
identifier of the event as the primary key), we define event-type-specific
tables. These allow for the storage of event-type-specific attributes without
having a gigantic “sparse table” hosting all the events with all the different
attributes (with an empty value for most of them). Therefore, if $et\in ET(L)$
is the event type, we have a table called event_$\oplus$$map_{ET}$(et), where
$map_{ET}:ET(L)\rightarrow\mathbb{U}_{\mathit{\Sigma}}$ is an injective
function333Which can be the identity function. mapping the event types to
unique identifiers, containing the events of the given event type along with
their timestamp and attributes. In particular, all the attributes associated
with the given event type (eatype in Definition 2) are columns of the table,
and the values for each event are populated accordingly (eaval in Definition
2). Moreover, the timestamp is a column of the event-type-specific tables. The
event identifier column is pointing (as a foreign key) to the event identifier
column of the event table. Examples follow (Table 8, Table 9, Table 10, Table
11, Table 12, Table 13, Table 14, Table 15) for all the event types of the
running example log.

Table 8: [Proposed relational implementation] Event Type Table: event_CreatePurchaseRequisition ocel_id [PK] [FK] | ocel_time | pr_creator
---|---|---
e1 | 2022-01-09 15:00 | Mike
Table 9: [Proposed relational implementation] Event type table: event_ApprovePurchaseRequisition ocel_id [PK] [FK] | ocel_time | pr_approver
---|---|---
e2 | 2022-01-09 16:30 | Tania
Table 10: [Proposed relational implementation] Event type table: event_CreatePurchaseOrder ocel_id [PK] [FK] | ocel_time | po_creator
---|---|---
e3 | 2022-01-10 09:15 | Mike
e10 | 2022-02-02 17:00 | Mario
Table 11: [Proposed relational implementation] Event type table: event_ChangePOQuantity ocel_id [PK] [FK] | ocel_time | po_editor
---|---|---
e4 | 2022-01-13 12:00 | Mike
Table 12: [Proposed relational implementation] Event type table: event_InsertInvoice ocel_id [PK] [FK] | ocel_time | invoice_inserter
---|---|---
e5 | 2022-01-14 12:00 | Luke
e6 | 2022-01-16 11:00 | Luke
e9 | 2022-02-02 09:00 | Mario
Table 13: [Proposed relational implementation] Event type table: event_SetPaymentBlock ocel_id [PK] [FK] | ocel_time | invoice_blocker
---|---|---
e11 | 2022-02-03 07:30 | Sam
Table 14: [Proposed relational implementation] Event type table: event_RemovePaymentBlock ocel_id [PK] [FK] | ocel_time | invoice_block_rem
---|---|---
e12 | 2022-02-03 23:30 | Mario
Table 15: [Proposed relational implementation] Event type table: event_InsertPayment ocel_id [PK] [FK] | ocel_time | payment_inserter
---|---|---
e7 | 2022-01-30 23:00 | Robot
e8 | 2022-01-31 22:00 | Robot
e13 | 2022-02-28 23:00 | Robot

###  6.4 Object Type Tables

Having defined the table object as the general table for the objects (having
the identifier of the object as the primary key), we want to define object-
type-specific tables for equivalent reasons to the ones explained in
Subsection 6.3. Therefore, if $ot\in OT(L)$ is the object type, we have a
table called object_$\oplus$$map_{OT}$(ot), where
$map_{OT}:OT(L)\rightarrow\mathbb{U}_{\mathit{\Sigma}}$ is an injective
function444Which can be the identity function. mapping the object types to
unique identifiers, containing the objects of the given object type along with
the history of their attributes. In particular, all the attributes associated
with the given object type (oatype in Definition 2) are columns of the table,
and the values for each object are populated accordingly. The timestamp column
here highlights the history of the values of the different attributes. We made
the following design choices:

  * •

In accordance with the definition of OCEL 2.0, rows possessing the smallest
feasible timestamp, specifically _1970-01-01 00:00 UTC_ \- which equates to
$0$ in Definition 2 \- correspond to the initial values of all the attributes
for a given object. This uniform timestamp selection, symbolic of the starting
point or ”epoch”, facilitates a consistent reference frame across all objects,
aligning seamlessly with the structure proposed by OCEL 2.0. The deliberate
choice of this fixed date for the timestamp of $0$ is not arbitrary; instead,
it serves a clear purpose by fostering improved compatibility and coherence
with the OCEL 2.0 definition.

  * •

The rows having a different timestamp have a value in the column
_ocel_changed_field_ , which highlights which other column has been changed.

This allows (according to $oaval$ in Definition 2) to reconstruct the value of
a given attribute at a specified point in time. For example, given the
purchase order PO1, the quantity of the order at 2022-01-11 10:00 is $500$
cows, but it becomes $600$ cows at 2022-01-13 13:00. Also, consider the
invoice $R3$, which was blocked and then released.

The object identifier column is pointing (as a foreign key) to the object
identifier column of the object table.

Examples follow (Table 16, Table 17, Table 18, Table 19) for all the object
types of the running example log.

Table 16: [Proposed relational implementation] Object type table: object_PurchaseRequisition ocel_id [FK] | ocel_time | pr_product | pr_quantity | ocel_changed_field
---|---|---|---|---
PR1 | 1970-01-01 00:00 UTC | Cows | 500 |
Table 17: [Proposed relational implementation] Object type table: object_PurchaseOrder ocel_id [FK] | ocel_time | po_product | po_quantity | ocel_changed_field
---|---|---|---|---
PO1 | 1970-01-01 00:00 UTC | Cows | 500 |
PO1 | 2022-01-13 12:00 UTC |  | 600 | po_quantity
PO2 | 1970-01-01 01:00 UTC | Notebooks | 1 |
Table 18: [Proposed relational implementation] Object type table: object_Invoice ocel_id [FK] | ocel_time | is_blocked | ocel_changed_field
---|---|---|---
R1 | 1970-01-01 00:00 UTC | No |
R2 | 1970-01-01 00:00 UTC | No |
R3 | 1970-01-01 00:00 UTC | No |
R3 | 2022-02-03 07:30 UTC | Yes | is_blocked
R3 | 2022-02-03 23:30 UTC | No | is_blocked
Table 19: [Proposed relational implementation] Object type table: object_Payment ocel_id [FK] | ocel_time | ocel_changed_field
---|---|---
P1 | 1970-01-01 00:00 UTC |
P2 | 1970-01-01 00:00 UTC |
P3 | 1970-01-01 00:00 UTC |

###  6.5 Event-to-Object (E2O) Relationships

The event_object table contains the event-to-object relationships (E2O in
Definition 2). Therefore, it contains the correlated event identifier and
object identifier (foreign key to event.ocel_id and object.ocel_id
respectively) with a qualifier explaining the nature of the relationship. A
primary key is set on event_object containing all the columns, therefore
“realizing” the set proposed in Definition 2. The event_object table of the
running example is proposed in Table 20. Note that we can have an event
related with different qualifiers to the same object.

Table 20: [Proposed relational implementation] Table containing the event-to-
object (event_object) relationships

ocel_event_id [PK] [FK] | ocel_object_id [PK] [FK] | ocel_qualifier [PK]
---|---|---
e1 | PR1 | Regular placement of PR
e2 | PR1 | Regular approval of PR
e3 | PR1 | Created order from PR
e3 | PO1 | Created order with identifier
e4 | PO1 | Change of quantity
e5 | PO1 | Invoice created starting from the PO
e5 | R1 | Invoice created with identifier
e5 | PO1 | Invoice created starting from the PO
e6 | R2 | Invoice created with identifier
e6 | PO1 | Invoice created starting from the PO
e7 | R1 | Payment for the invoice
e7 | P1 | Payment inserted with identifier
e8 | R2 | Payment for the invoice
e8 | P2 | Payment inserted with identifier
e9 | R3 | Invoice created with identifier
e10 | R3 | Purchase order created with maverick buying from
e10 | PO2 | Purchase order created with identifier
e11 | R3 | Payment block due to unethical maverick buying
e12 | R3 | Payment block removed …
e13 | R3 | Payment for the invoice
e13 | P3 | Payment inserted with identifier

###  6.6 Object-to-Object (O2O) Relationships

The object_object table contains the object-to-object relationships (O2O in
Definition 2). Therefore, it contains the correlated object identifiers
(source and target; both are foreign keys to object.ocel_id) with a qualifier
explaining the nature of the relationship. A primary key is set on
object_object containing all the columns, therefore “realizing” the set
proposed in Definition 2. The object_object table of the running example is
proposed in Table 21. Note that we can have the same couple of objects related
through different qualifiers.

Table 21: [Proposed relational implementation] Table containing the object-to-
object (object_object) relationships

ocel_source_id [PK] [FK] | ocel_target_id [PK] [FK] | ocel_qualifier [PK]
---|---|---
PR1 | PO1 | PO from PR
PO1 | R1 | Invoice from PO
PO1 | R2 | Invoice from PO
R1 | P1 | Payment from invoice
R2 | P2 | Payment from invoice
PO2 | R3 | Maverick buying
R3 | P3 | Payment from invoice

###  6.7 Constraints on the Relational Implementation

Clearly, all the elements introduced using the metamodel can be mapped onto
the table structures proposed. However, we need to ensure consistency.
Therefore, the following constraints are implemented on the proposed
relational implementation:

  * •

The uniqueness of the event/object types in the tables event_map_type and
object_map_type is ensured by setting the type as the primary key.

  * •

The uniqueness of the events/objects in the overall event and object tables is
ensured by setting the identifier as the primary key.

  * •

The uniqueness of the event identifiers in the specific event type tables is
ensured by setting the identifier as the primary key. Since the same objects
can appear (by design choice) several times in the specific object type
tables, we cannot set the identifier as the primary key in the given setting.

  * •

There is a foreign key between the specific event type tables and the generic
event table. This ensures that every identifier appearing in the specific
event type tables has been added to the event table.

  * •

There is a foreign key between the specific object type table and the generic
object table. This ensures that every identifier appearing in the specific
object type tables has been added to the object table.

  * •

There is a foreign key between the generic event table and event_map_type,
ensuring that every event can be mapped to a specific event type table.

  * •

There is a foreign key between the generic object table and object_map_type,
ensuring that every object is mapped to a specific object type table.

  * •

The event_object table has two foreign keys, directed towards event.ocel_id
and object.ocel_id respectively. This ensures that every identifier appearing
in the event_object table is effectively an event or an object. Moreover, the
three columns together form the primary key, ensuring that no duplicate rows
are contained in the table.

  * •

The object_object table has two foreign keys, both directed towards
object.ocel_id. This ensures that every identifier appearing in the
object_object table is effectively an object. Moreover, the three columns
together form the primary key, ensuring that no duplicate rows are contained
in the table.

We can ensure that every event/object is added to the correct event
type/object type table by a trigger that checks during the insertion time the
event_map_type/object_map_type tables to compare the name of the current table
with the expected table into which the event/object should be assigned.

We also provide some offline validation constraints as SQL queries. These are
available at https://www.ocel-standard.org/2.0/ocel20-schema-relational.pdf.

##  7 XML Format

We propose an XML implementation following Definition 2. The timestamps are
assumed to follow the ISO format specification
https://en.wikipedia.org/wiki/ISO_8601.

The XML schema is organized as follows. There is a root element with the tag
log. The log element has the following children:

  * •

An element with tag object-types, containing as many object-type elements as
types in $OT(L)$. Each object-type has a name property (which is the object
type) and a single child with tag attributes:

    * –

For every attribute in $\textrm{oatype}(ot)$, the element attributes has a
child with tag attribute and properties name (which is the attribute) and type
(the type of the attribute, which should be considered during the parsing of
the values).

  * •

An element with tag event-types, containing as many event-type elements as
types in $OT(L)$. Each event-type has a name property (which is the event
type) and a single child with tag attributes:

    * –

For every attribute in $\textrm{eatype}(et)$, the element attributes has a
child with tag attribute and properties name (which is the attribute) and type
(the type of the attribute, which should be considered during the parsing of
the values).

  * •

An element with tag events, containing as many event elements as many events
are in $E$. An event is characterized by:

    * –

Its properties id (the identifier of the event), type (the event type of the
event, given by evtype in Definition 2) and time (the timestamp of the event,
given by time in Definition 2).

    * –

A child with tag objects, containing the related objects to the event (E2O in
Definition 2; we define the function:

$\textrm{relobj}(e)=\\{(o,q)~{}\arrowvert~{}(e^{\prime},q,o)\in\textrm{E2O}~{}\wedge~{}e^{\prime}=e\\}$

which associates to every event a set of objects along with the qualifier of
the relationship). In particular, for every event-to-object relationship an
entry relobj is created, having as properties the object-id (related object
identifier) and qualifier (the qualifier of the event-to-object relationship).

    * –

A child with tag attributes, having as many children attribute as many
attributes are related to the event (the domain of $\textrm{eaval}_{ea}$ in
Definition 2):

      * *

Each attribute is characterized by a name property and the corresponding value
is reported as text of the (XML) element.

  * •

An element with tag objects, containing as many object elements as many
objects are in $O$. An object is characterized by:

    * –

Its properties id (the identifier of the object) and type (the object type of
the object, given by objtype in Definition 2).

    * –

An element with tag attributes, containing the different attribute of the
object.

    * –

Each attribute is characterized by a time property (the timestamp in which the
value for the given attribute was recorded), a name property, and the
corresponding value is reported as the text of the (XML) element. An attribute
is valid from the specified time (until an attribute with the same name and
greater timestamp is recorded).

    * –

A child with tag objects, containing the related objects to the given object
(O2O in Definition 2; we define the function:

$\textrm{relobj}(o)=\\{(o^{\prime\prime},q)~{}\arrowvert~{}(o^{\prime},q,o^{\prime\prime})\in\textrm{O2O}~{}\wedge~{}o^{\prime}=o\\}$

which associates to every object a set of objects along with the qualifier of
the relationship). In particular, for every object-to-object relationship an
entry relobj is created, having as properties the object-id (related object
identifier) and qualifier (the qualifier of the object-to-object
relationship).

In the remainder of this section, we show an example file and the XSD (XML
Schema Definition) that can be used to check consistency.

###  7.1 XML Example

An example (on the running example log) follows.

⬇

1<?xml version=’1.0’ encoding=’UTF-8’?>

2<log>

3 <object-types>

4 <object-type name="Invoice">

5 <attributes>

6 <attribute name="is_blocked" type="string"/>

7 </attributes>

8 </object-type>

9 <object-type name="Payment">

10 <attributes/>

11 </object-type>

12 <object-type name="Purchase Order">

13 <attributes>

14 <attribute name="po_product" type="string"/>

15 <attribute name="po_quantity" type="string"/>

16 </attributes>

17 </object-type>

18 <object-type name="Purchase Requisition">

19 <attributes>

20 <attribute name="pr_product" type="string"/>

21 <attribute name="pr_quantity" type="string"/>

22 </attributes>

23 </object-type>

24 </object-types>

25 <event-types>

26 <event-type name="Approve Purchase Requisition">

27 <attributes>

28 <attribute name="pr_approver" type="string"/>

29 </attributes>

30 </event-type>

31 <event-type name="Change PO Quantity">

32 <attributes>

33 <attribute name="po_editor" type="string"/>

34 </attributes>

35 </event-type>

36 <event-type name="Create Purchase Order">

37 <attributes>

38 <attribute name="po_creator" type="string"/>

39 </attributes>

40 </event-type>

41 <event-type name="Create Purchase Requisition">

42 <attributes>

43 <attribute name="pr_creator" type="string"/>

44 </attributes>

45 </event-type>

46 <event-type name="Insert Invoice">

47 <attributes>

48 <attribute name="invoice_inserter" type="string"/>

49 </attributes>

50 </event-type>

51 <event-type name="Insert Payment">

52 <attributes>

53 <attribute name="payment_inserter" type="string"/>

54 </attributes>

55 </event-type>

56 <event-type name="Remove Payment Block">

57 <attributes>

58 <attribute name="invoice_block_rem" type="string"/>

59 </attributes>

60 </event-type>

61 <event-type name="Set Payment Block">

62 <attributes>

63 <attribute name="invoice_blocker" type="string"/>

64 </attributes>

65 </event-type>

66 </event-types>

67 <objects>

68 <object id="R1" type="Invoice">

69 <attributes>

70 <attribute name="is_blocked" time="1970-01-01T00:00:00Z">No</attribute>

71 </attributes>

72 <objects>

73 <relationship object-id="P1" qualifier="Payment from invoice"/>

74 </objects>

75 </object>

76 <object id="R2" type="Invoice">

77 <attributes>

78 <attribute name="is_blocked" time="1970-01-01T00:00:00Z">No</attribute>

79 </attributes>

80 <objects>

81 <relationship object-id="P2" qualifier="Payment from invoice"/>

82 </objects>

83 </object>

84 <object id="R3" type="Invoice">

85 <attributes>

86 <attribute name="is_blocked" time="1970-01-01T00:00:00Z">No</attribute>

87 <attribute name="is_blocked" time="2022-02-03T07:30:00Z">Yes</attribute>

88 <attribute name="is_blocked" time="2022-02-03T23:30:00Z">No</attribute>

89 </attributes>

90 <objects>

91 <relationship object-id="P3" qualifier="Payment from invoice"/>

92 </objects>

93 </object>

94 <object id="P1" type="Payment">

95 <attributes/>

96 </object>

97 <object id="P2" type="Payment">

98 <attributes/>

99 </object>

100 <object id="P3" type="Payment">

101 <attributes/>

102 </object>

103 <object id="PO1" type="Purchase Order">

104 <attributes>

105 <attribute name="po_product" time="1970-01-01T00:00:00Z">Cows</attribute>

106 <attribute name="po_quantity" time="1970-01-01T00:00:00Z">500</attribute>

107 <attribute name="po_quantity" time="2022-01-13T12:00:00Z">600</attribute>

108 </attributes>

109 <objects>

110 <relationship object-id="R1" qualifier="Invoice from PO"/>

111 <relationship object-id="R2" qualifier="Invoice from PO"/>

112 </objects>

113 </object>

114 <object id="PO2" type="Purchase Order">

115 <attributes>

116 <attribute name="po_product"
time="1970-01-01T00:00:00Z">Notebooks</attribute>

117 <attribute name="po_quantity" time="1970-01-01T00:00:00Z">1</attribute>

118 </attributes>

119 <objects>

120 <relationship object-id="R3" qualifier="Maverick buying"/>

121 </objects>

122 </object>

123 <object id="PR1" type="Purchase Requisition">

124 <attributes>

125 <attribute name="pr_product" time="1970-01-01T00:00:00Z">Cows</attribute>

126 <attribute name="pr_quantity" time="1970-01-01T00:00:00Z">500</attribute>

127 </attributes>

128 <objects>

129 <relationship object-id="PO1" qualifier="PO from PR"/>

130 </objects>

131 </object>

132 </objects>

133 <events>

134 <event id="e1" type="Create Purchase Requisition"
time="2022-01-09T15:00:00Z">

135 <attributes>

136 <attribute name="pr_creator">Mike</attribute>

137 </attributes>

138 <objects>

139 <relationship object-id="PR1" qualifier="Regular placement of PR"/>

140 </objects>

141 </event>

142 <event id="e2" type="Approve Purchase Requisition"
time="2022-01-09T16:30:00Z">

143 <attributes>

144 <attribute name="pr_approver">Tania</attribute>

145 </attributes>

146 <objects>

147 <relationship object-id="PR1" qualifier="Regular approval of PR"/>

148 </objects>

149 </event>

150 <event id="e3" type="Create Purchase Order" time="2022-01-10T09:15:00Z">

151 <attributes>

152 <attribute name="po_creator">Mike</attribute>

153 </attributes>

154 <objects>

155 <relationship object-id="PR1" qualifier="Created order from PR"/>

156 <relationship object-id="PO1" qualifier="Created order with identifier"/>

157 </objects>

158 </event>

159 <event id="e4" type="Change PO Quantity" time="2022-01-13T12:00:00Z">

160 <attributes>

161 <attribute name="po_editor">Mike</attribute>

162 </attributes>

163 <objects>

164 <relationship object-id="PO1" qualifier="Change of quantity"/>

165 </objects>

166 </event>

167 <event id="e5" type="Insert Invoice" time="2022-01-14T12:00:00Z">

168 <attributes>

169 <attribute name="invoice_inserter">Luke</attribute>

170 </attributes>

171 <objects>

172 <relationship object-id="PO1" qualifier="Invoice created starting from the
PO"/>

173 <relationship object-id="R1" qualifier="Invoice created with identifier"/>

174 </objects>

175 </event>

176 <event id="e6" type="Insert Invoice" time="2022-01-16T11:00:00Z">

177 <attributes>

178 <attribute name="invoice_inserter">Luke</attribute>

179 </attributes>

180 <objects>

181 <relationship object-id="PO1" qualifier="Invoice created starting from the
PO"/>

182 <relationship object-id="R2" qualifier="Invoice created with identifier"/>

183 </objects>

184 </event>

185 <event id="e7" type="Insert Payment" time="2022-01-30T23:00:00Z">

186 <attributes>

187 <attribute name="payment_inserter">Robot</attribute>

188 </attributes>

189 <objects>

190 <relationship object-id="R1" qualifier="Payment for the invoice"/>

191 <relationship object-id="P1" qualifier="Payment inserted with
identifier"/>

192 </objects>

193 </event>

194 <event id="e8" type="Insert Payment" time="2022-01-31T22:00:00Z">

195 <attributes>

196 <attribute name="payment_inserter">Robot</attribute>

197 </attributes>

198 <objects>

199 <relationship object-id="R2" qualifier="Payment for the invoice"/>

200 <relationship object-id="P2" qualifier="Payment created with identifier"/>

201 </objects>

202 </event>

203 <event id="e9" type="Insert Invoice" time="2022-02-02T09:00:00Z">

204 <attributes>

205 <attribute name="invoice_inserter">Mario</attribute>

206 </attributes>

207 <objects>

208 <relationship object-id="R3" qualifier="Invoice created with identifier"/>

209 </objects>

210 </event>

211 <event id="e10" type="Create Purchase Order" time="2022-02-02T17:00:00Z">

212 <attributes>

213 <attribute name="po_creator">Mario</attribute>

214 </attributes>

215 <objects>

216 <relationship object-id="R3" qualifier="Purchase order created with
maverick buying from"/>

217 <relationship object-id="PO2" qualifier="Purchase order created with
identifier"/>

218 </objects>

219 </event>

220 <event id="e11" type="Set Payment Block" time="2022-02-03T07:30:00Z">

221 <attributes>

222 <attribute name="invoice_blocker">Mario</attribute>

223 </attributes>

224 <objects>

225 <relationship object-id="R3" qualifier="Payment block due to unethical
maverick buying"/>

226 </objects>

227 </event>

228 <event id="e12" type="Remove Payment Block" time="2022-02-03T23:30:00Z">

229 <attributes>

230 <attribute name="invoice_block_rem">Mario</attribute>

231 </attributes>

232 <objects>

233 <relationship object-id="R3" qualifier="Payment block removed ..."/>

234 </objects>

235 </event>

236 <event id="e13" type="Insert Payment" time="2022-02-28T23:00:00Z">

237 <attributes>

238 <attribute name="payment_inserter">Robot</attribute>

239 </attributes>

240 <objects>

241 <relationship object-id="R3" qualifier="Payment for the invoice"/>

242 <relationship object-id="P3" qualifier="Payment inserted with
identifier"/>

243 </objects>

244 </event>

245 </events>

246</log><

###  7.2 XML Schema Definition

A machine-readable XML Schema Definition (XSD) file is provided to check
whether an example XML OCEL 2.0 is valid, see https://www.ocel-
standard.org/2.0/ocel20-schema-xml.xsd Numerous tools are available to
validate an XML file against an XSD file.

⬇

1<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"

2 xmlns:xs="http://www.w3.org/2001/XMLSchema">

3 <xs:element name="attribute">

4 <xs:complexType>

5 <xs:simpleContent>

6 <xs:extension base="xs:string">

7 <xs:attribute type="xs:string" name="name" use="required"/>

8 <xs:attribute name="type" use="optional">

9 <xs:simpleType>

10 <xs:restriction base="xs:string">

11 <xs:enumeration value="string"/>

12 <xs:enumeration value="time"/>

13 <xs:enumeration value="integer"/>

14 <xs:enumeration value="float"/>

15 <xs:enumeration value="boolean"/>

16 </xs:restriction>

17 </xs:simpleType>

18 </xs:attribute>

19 <xs:attribute type="xs:dateTime" name="time" use="optional"/>

20 </xs:extension>

21 </xs:simpleContent>

22 </xs:complexType>

23 </xs:element>

24 <xs:element name="attributes">

25 <xs:complexType mixed="true">

26 <xs:sequence>

27 <xs:element ref="attribute" maxOccurs="unbounded" minOccurs="0"/>

28 </xs:sequence>

29 </xs:complexType>

30 </xs:element>

31 <xs:element name="object-type">

32 <xs:complexType>

33 <xs:sequence>

34 <xs:element ref="attributes"/>

35 </xs:sequence>

36 <xs:attribute type="xs:string" name="name" use="required"/>

37 </xs:complexType>

38 <xs:key name="objectTypeAttributeKey">

39 <xs:selector xpath="attributes/attribute"/>

40 <xs:field xpath="@name"/>

41 </xs:key>

42 </xs:element>

43 <xs:element name="event-type">

44 <xs:complexType>

45 <xs:sequence>

46 <xs:element ref="attributes"/>

47 </xs:sequence>

48 <xs:attribute type="xs:string" name="name" use="required"/>

49 </xs:complexType>

50 <xs:key name="eventTypeAttributeKey">

51 <xs:selector xpath="attributes/attribute"/>

52 <xs:field xpath="@name"/>

53 </xs:key>

54 </xs:element>

55 <xs:element name="object">

56 <xs:complexType mixed="true">

57 <xs:sequence>

58 <xs:element ref="attributes" minOccurs="0"/>

59 <xs:element ref="objects" minOccurs="0"/>

60 </xs:sequence>

61 <xs:attribute type="xs:string" name="object-id" use="optional"/>

62 <xs:attribute type="xs:string" name="qualifier" use="optional"/>

63 <xs:attribute type="xs:string" name="id" use="optional"/>

64 <xs:attribute type="xs:string" name="type" use="required"/>

65 </xs:complexType>

66 </xs:element>

67 <xs:element name="objects">

68 <xs:complexType>

69 <xs:sequence>

70 <xs:element ref="object" maxOccurs="unbounded" minOccurs="0"/>

71 </xs:sequence>

72 </xs:complexType>

73 </xs:element>

74 <xs:element name="event">

75 <xs:complexType>

76 <xs:sequence>

77 <xs:element ref="attributes"/>

78 <xs:element ref="objects"/>

79 </xs:sequence>

80 <xs:attribute type="xs:string" name="id" use="required"/>

81 <xs:attribute type="xs:string" name="type" use="required"/>

82 <xs:attribute type="xs:dateTime" name="time" use="required"/>

83 </xs:complexType>

84 </xs:element>

85 <xs:element name="object-types">

86 <xs:complexType>

87 <xs:sequence>

88 <xs:element ref="object-type" maxOccurs="unbounded" minOccurs="0"/>

89 </xs:sequence>

90 </xs:complexType>

91 </xs:element>

92 <xs:element name="event-types">

93 <xs:complexType>

94 <xs:sequence>

95 <xs:element ref="event-type" maxOccurs="unbounded" minOccurs="0"/>

96 </xs:sequence>

97 </xs:complexType>

98 </xs:element>

99 <xs:element name="events">

100 <xs:complexType>

101 <xs:sequence>

102 <xs:element ref="event" maxOccurs="unbounded" minOccurs="0"/>

103 </xs:sequence>

104 </xs:complexType>

105 </xs:element>

106 <xs:element name="log">

107 <xs:complexType>

108 <xs:sequence>

109 <xs:element ref="object-types"/>

110 <xs:element ref="event-types"/>

111 <xs:element ref="objects"/>

112 <xs:element ref="events"/>

113 </xs:sequence>

114 </xs:complexType>

115 <xs:key name="objectTypeKey">

116 <xs:selector xpath="object-types/object-type"/>

117 <xs:field xpath="@name"/>

118 </xs:key>

119 <xs:key name="objectKey">

120 <xs:selector xpath="objects/object"/>

121 <xs:field xpath="@id"/>

122 </xs:key>

123 <xs:key name="eventTypeKey">

124 <xs:selector xpath="event-types/event-type"/>

125 <xs:field xpath="@name"/>

126 </xs:key>

127 <xs:key name="eventKey">

128 <xs:selector xpath="events/event"/>

129 <xs:field xpath="@id"/>

130 </xs:key>

131 <xs:keyref name="objectTypeRef" refer="objectTypeKey">

132 <xs:selector xpath="objects/object"/>

133 <xs:field xpath="@type"/>

134 </xs:keyref>

135 <xs:keyref name="eventTypeRef" refer="eventTypeKey">

136 <xs:selector xpath="events/event"/>

137 <xs:field xpath="@type"/>

138 </xs:keyref>

139 <xs:keyref name="objectObjectRef" refer="objectKey">

140 <xs:selector xpath="objects/object/objects/object"/>

141 <xs:field xpath="@object-id"/>

142 </xs:keyref>

143 <xs:keyref name="eventObjectRef" refer="objectKey">

144 <xs:selector xpath="events/event/objects/object"/>

145 <xs:field xpath="@object-id"/>

146 </xs:keyref>

147 <xs:keyref name="objectAttributeRef" refer="objectTypeAttributeKey">

148 <xs:selector xpath="objects/object/attributes/attribute"/>

149 <xs:field xpath="@name"/>

150 </xs:keyref>

151 <xs:keyref name="eventAttributeRef" refer="eventTypeAttributeKey">

152 <xs:selector xpath="events/event/attributes/attribute"/>

153 <xs:field xpath="@name"/>

154 </xs:keyref>

155 </xs:element>

156</xs:schema><

##  8 JSON Format

The JSON format provides a lightweight structure for web-native process mining
applications. It is conceptually similar to the XML format with its top-level
arrays events, eventTypes, objects, and objectTypes.

In the following, we describe these four top-level properties in detail.

  * •

The top-level event array contains event objects with the properties id, type
(referencing the name of an event type), and time (ISO format). An event’s
attributes are structured into an array of attribute objects with name and
value properties. The event’s event-to-object relationships are listed in the
relationships array with objectId and qualifier.

  * •

The top-level eventTypes array contains event type objects with a name and a
list of attributes with name and value properties. Valid types are string,
time, integer, float, and boolean.

  * •

The top-level object array contains a list of objects as JSON object, with
properties id and type (referencing the name of an object type). The
attributes property contains an array of attributes with the properties name,
time (ISO format), and value.

  * •

Finally, the top-level objectTypes array contains object type description
objects with a name and a list of attributes with name and value properties.
Valid types are string, time, integer, float, and boolean.

###  8.1 JSON Example

As an example, we show the running example formatted as a JSON document.

⬇

1{

2 "objectTypes": [

3 {

4 "name": "Invoice",

5 "attributes": [

6 {

7 "name": "is_blocked",

8 "type": "string"

9 }

10 ]

11 },

12 {

13 "name": "Payment",

14 "attributes": []

15 },

16 {

17 "name": "Purchase Order",

18 "attributes": [

19 {

20 "name": "po_product",

21 "type": "string"

22 },

23 {

24 "name": "po_quantity",

25 "type": "string"

26 }

27 ]

28 },

29 {

30 "name": "Purchase Requisition",

31 "attributes": [

32 {

33 "name": "pr_product",

34 "type": "string"

35 },

36 {

37 "name": "pr_quantity",

38 "type": "string"

39 }

40 ]

41 }

42 ],

43 "eventTypes": [

44 {

45 "name": "Approve Purchase Requisition",

46 "attributes": [

47 {

48 "name": "pr_approver",

49 "type": "string"

50 }

51 ]

52 },

53 {

54 "name": "Change PO Quantity",

55 "attributes": [

56 {

57 "name": "po_editor",

58 "type": "string"

59 }

60 ]

61 },

62 {

63 "name": "Create Purchase Order",

64 "attributes": [

65 {

66 "name": "po_creator",

67 "type": "string"

68 }

69 ]

70 },

71 {

72 "name": "Create Purchase Requisition",

73 "attributes": [

74 {

75 "name": "pr_creator",

76 "type": "string"

77 }

78 ]

79 },

80 {

81 "name": "Insert Invoice",

82 "attributes": [

83 {

84 "name": "invoice_inserter",

85 "type": "string"

86 }

87 ]

88 },

89 {

90 "name": "Insert Payment",

91 "attributes": [

92 {

93 "name": "payment_inserter",

94 "type": "string"

95 }

96 ]

97 },

98 {

99 "name": "Remove Payment Block",

100 "attributes": [

101 {

102 "name": "invoice_block_rem",

103 "type": "string"

104 }

105 ]

106 },

107 {

108 "name": "Set Payment Block",

109 "attributes": [

110 {

111 "name": "invoice_blocker",

112 "type": "string"

113 }

114 ]

115 }

116 ],

117 "objects": [

118 {

119 "id": "R1",

120 "type": "Invoice",

121 "attributes": [

122 {

123 "name": "is_blocked",

124 "time": "1970-01-01T00:00:00Z",

125 "value": "No"

126 }

127 ],

128 "relationships": [

129 {

130 "objectId": "P1",

131 "qualifier": "Payment from invoice"

132 }

133 ]

134 },

135 {

136 "id": "R2",

137 "type": "Invoice",

138 "attributes": [

139 {

140 "name": "is_blocked",

141 "time": "1970-01-01T00:00:00Z",

142 "value": "No"

143 }

144 ],

145 "relationships": [

146 {

147 "objectId": "P2",

148 "qualifier": "Payment from invoice"

149 }

150 ]

151 },

152 {

153 "id": "R3",

154 "type": "Invoice",

155 "attributes": [

156 {

157 "name": "is_blocked",

158 "time": "1970-01-01T00:00:00Z",

159 "value": "No"

160 },

161 {

162 "name": "is_blocked",

163 "time": "2022-02-03T07:30:00Z",

164 "value": "Yes"

165 },

166 {

167 "name": "is_blocked",

168 "time": "2022-02-03T23:30:00Z",

169 "value": "No"

170 }

171 ],

172 "relationships": [

173 {

174 "objectId": "P3",

175 "qualifier": "Payment from invoice"

176 }

177 ]

178 },

179 {

180 "id": "P1",

181 "type": "Payment"

182 },

183 {

184 "id": "P2",

185 "type": "Payment"

186 },

187 {

188 "id": "P3",

189 "type": "Payment"

190 },

191 {

192 "id": "PO1",

193 "type": "Purchase Order",

194 "attributes": [

195 {

196 "name": "po_product",

197 "time": "1970-01-01T00:00:00Z",

198 "value": "Cows"

199 },

200 {

201 "name": "po_quantity",

202 "time": "1970-01-01T00:00:00Z",

203 "value": "500"

204 },

205 {

206 "name": "po_quantity",

207 "time": "2022-01-13T12:00:00Z",

208 "value": "600"

209 }

210 ],

211 "relationships": [

212 {

213 "objectId": "R1",

214 "qualifier": "Invoice from PO"

215 },

216 {

217 "objectId": "R2",

218 "qualifier": "Invoice from PO"

219 }

220 ]

221 },

222 {

223 "id": "PO2",

224 "type": "Purchase Order",

225 "attributes": [

226 {

227 "name": "po_product",

228 "time": "1970-01-01T00:00:00Z",

229 "value": "Notebooks"

230 },

231 {

232 "name": "po_quantity",

233 "time": "1970-01-01T00:00:00Z",

234 "value": "1"

235 }

236 ],

237 "relationships": [

238 {

239 "objectId": "R3",

240 "qualifier": "Maverick buying"

241 }

242 ]

243 },

244 {

245 "id": "PR1",

246 "type": "Purchase Requisition",

247 "attributes": [

248 {

249 "name": "pr_product",

250 "time": "1970-01-01T00:00:00Z",

251 "value": "Cows"

252 },

253 {

254 "name": "pr_quantity",

255 "time": "1970-01-01T00:00:00Z",

256 "value": "500"

257 }

258 ],

259 "relationships": [

260 {

261 "objectId": "PO1",

262 "qualifier": "PO from PR"

263 }

264 ]

265 }

266 ],

267 "events": [

268 {

269 "id": "e1",

270 "type": "Create Purchase Requisition",

271 "time": "2022-01-09T15:00:00Z",

272 "attributes": [

273 {

274 "name": "pr_creator",

275 "value": "Mike"

276 }

277 ],

278 "relationships": [

279 {

280 "objectId": "PR1",

281 "qualifier": "Regular placement of PR"

282 }

283 ]

284 },

285 {

286 "id": "e2",

287 "type": "Approve Purchase Requisition",

288 "time": "2022-01-09T16:30:00Z",

289 "attributes": [

290 {

291 "name": "pr_approver",

292 "value": "Tania"

293 }

294 ],

295 "relationships": [

296 {

297 "objectId": "PR1",

298 "qualifier": "Regular approval of PR"

299 }

300 ]

301 },

302 {

303 "id": "e3",

304 "type": "Create Purchase Order",

305 "time": "2022-01-10T09:15:00Z",

306 "attributes": [

307 {

308 "name": "po_creator",

309 "value": "Mike"

310 }

311 ],

312 "relationships": [

313 {

314 "objectId": "PR1",

315 "qualifier": "Created order from PR"

316 },

317 {

318 "objectId": "PO1",

319 "qualifier": "Created order with identifier"

320 }

321 ]

322 },

323 {

324 "id": "e4",

325 "type": "Change PO Quantity",

326 "time": "2022-01-13T12:00:00Z",

327 "attributes": [

328 {

329 "name": "po_editor",

330 "value": "Mike"

331 }

332 ],

333 "relationships": [

334 {

335 "objectId": "PO1",

336 "qualifier": "Change of quantity"

337 }

338 ]

339 },

340 {

341 "id": "e5",

342 "type": "Insert Invoice",

343 "time": "2022-01-14T12:00:00Z",

344 "attributes": [

345 {

346 "name": "invoice_inserter",

347 "value": "Luke"

348 }

349 ],

350 "relationships": [

351 {

352 "objectId": "PO1",

353 "qualifier": "Invoice created starting from the PO"

354 },

355 {

356 "objectId": "R1",

357 "qualifier": "Invoice created with identifier"

358 }

359 ]

360 },

361 {

362 "id": "e6",

363 "type": "Insert Invoice",

364 "time": "2022-01-16T11:00:00Z",

365 "attributes": [

366 {

367 "name": "invoice_inserter",

368 "value": "Luke"

369 }

370 ],

371 "relationships": [

372 {

373 "objectId": "PO1",

374 "qualifier": "Invoice created starting from the PO"

375 },

376 {

377 "objectId": "R2",

378 "qualifier": "Invoice created with identifier"

379 }

380 ]

381 },

382 {

383 "id": "e7",

384 "type": "Insert Payment",

385 "time": "2022-01-30T23:00:00Z",

386 "attributes": [

387 {

388 "name": "payment_inserter",

389 "value": "Robot"

390 }

391 ],

392 "relationships": [

393 {

394 "objectId": "R1",

395 "qualifier": "Payment for the invoice"

396 },

397 {

398 "objectId": "P1",

399 "qualifier": "Payment inserted with identifier"

400 }

401 ]

402 },

403 {

404 "id": "e8",

405 "type": "Insert Payment",

406 "time": "2022-01-31T22:00:00Z",

407 "attributes": [

408 {

409 "name": "payment_inserter",

410 "value": "Robot"

411 }

412 ],

413 "relationships": [

414 {

415 "objectId": "R2",

416 "qualifier": "Payment for the invoice"

417 },

418 {

419 "objectId": "P2",

420 "qualifier": "Payment created with identifier"

421 }

422 ]

423 },

424 {

425 "id": "e9",

426 "type": "Insert Invoice",

427 "time": "2022-02-02T09:00:00Z",

428 "attributes": [

429 {

430 "name": "invoice_inserter",

431 "value": "Mario"

432 }

433 ],

434 "relationships": [

435 {

436 "objectId": "R3",

437 "qualifier": "Invoice created with identifier"

438 }

439 ]

440 },

441 {

442 "id": "e10",

443 "type": "Create Purchase Order",

444 "time": "2022-02-02T17:00:00Z",

445 "attributes": [

446 {

447 "name": "po_creator",

448 "value": "Mario"

449 }

450 ],

451 "relationships": [

452 {

453 "objectId": "R3",

454 "qualifier": "Purchase order created with maverick buying from"

455 },

456 {

457 "objectId": "PO2",

458 "qualifier": "Purchase order created with identifier"

459 }

460 ]

461 },

462 {

463 "id": "e11",

464 "type": "Set Payment Block",

465 "time": "2022-02-03T07:30:00Z",

466 "attributes": [

467 {

468 "name": "invoice_blocker",

469 "value": "Mario"

470 }

471 ],

472 "relationships": [

473 {

474 "objectId": "R3",

475 "qualifier": "Payment block due to unethical maverick buying"

476 }

477 ]

478 },

479 {

480 "id": "e12",

481 "type": "Remove Payment Block",

482 "time": "2022-02-03T23:30:00Z",

483 "attributes": [

484 {

485 "name": "invoice_block_rem",

486 "value": "Mario"

487 }

488 ],

489 "relationships": [

490 {

491 "objectId": "R3",

492 "qualifier": "Payment block removed ..."

493 }

494 ]

495 },

496 {

497 "id": "e13",

498 "type": "Insert Payment",

499 "time": "2022-02-28T23:00:00Z",

500 "attributes": [

501 {

502 "name": "payment_inserter",

503 "value": "Robot"

504 }

505 ],

506 "relationships": [

507 {

508 "objectId": "R3",

509 "qualifier": "Payment for the invoice"

510 },

511 {

512 "objectId": "P3",

513 "qualifier": "Payment inserted with identifier"

514 }

515 ]

516 }

517 ]

518}

###  8.2 JSON Schema Definition

We defined a validation schema for the OCEL 2.0 JSON specification. The schema
is reported in the following snippet and can be downloaded from
https://www.ocel-standard.org/2.0/ocel20-schema-json.json.

⬇

1{

2 "$schema": "http://json-schema.org/draft-07/schema#",

3 "type": "object",

4 "properties": {

5 "eventTypes": {

6 "type": "array",

7 "items": {

8 "type": "object",

9 "properties": {

10 "name": { "type": "string" },

11 "attributes": {

12 "type": "array",

13 "items": {

14 "type": "object",

15 "properties": {

16 "name": { "type": "string" },

17 "type": { "type": "string" }

18 },

19 "required": ["name", "type"]

20 }

21 }

22 },

23 "required": ["name", "attributes"]

24 }

25 },

26 "objectTypes": {

27 "type": "array",

28 "items": {

29 "type": "object",

30 "properties": {

31 "name": { "type": "string" },

32 "attributes": {

33 "type": "array",

34 "items": {

35 "type": "object",

36 "properties": {

37 "name": { "type": "string" },

38 "type": { "type": "string" }

39 },

40 "required": ["name", "type"]

41 }

42 }

43 },

44 "required": ["name", "attributes"]

45 }

46 },

47 "events": {

48 "type": "array",

49 "items": {

50 "type": "object",

51 "properties": {

52 "id": { "type": "string" },

53 "type": { "type": "string" },

54 "time": { "type": "string", "format": "date-time" },

55 "attributes": {

56 "type": "array",

57 "items": {

58 "type": "object",

59 "properties": {

60 "name": { "type": "string" },

61 "value": { "type": "string" }

62 },

63 "required": ["name", "value"]

64 }

65 },

66 "relationships": {

67 "type": "array",

68 "items": {

69 "type": "object",

70 "properties": {

71 "objectId": { "type": "string" },

72 "qualifier": { "type": "string" }

73 },

74 "required": ["objectId", "qualifier"]

75 }

76 }

77 },

78 "required": ["id", "type", "time"]

79 }

80 },

81 "objects": {

82 "type": "array",

83 "items": {

84 "type": "object",

85 "properties": {

86 "id": { "type": "string" },

87 "type": { "type": "string" },

88 "relationships": {

89 "type": "array",

90 "items": {

91 "type": "object",

92 "properties": {

93 "objectId": { "type": "string" },

94 "qualifier": { "type": "string" }

95 },

96 "required": ["objectId", "qualifier"]

97 }

98 },

99 "attributes": {

100 "type": "array",

101 "items": {

102 "type": "object",

103 "properties": {

104 "name": { "type": "string" },

105 "value": { "type": "string" },

106 "time": { "type": "string", "format": "date-time" }

107 },

108 "required": ["name", "value", "time"]

109 }

110 }

111 },

112 "required": ["id", "type"]

113 }

114 }

115 },

116 "required": ["eventTypes", "objectTypes", "events", "objects"]

117}

##  9 Conclusion

This document provides a comprehensive introduction to the OCEL 2.0 standard.
Given the increasing importance of Object-Centric Process Mining (OCPM), it is
important to be able to standardize Object-Centric Event Data (OCED). OCEL 2.0
aims to provide a middle ground between simplicity and expressiveness,
building upon experiences with OCEL 1.0 over the past three years. We first
provided a contextual understanding of the object-centric process mining
landscape and then discussed the motivation and the necessities that led to
the creation of the OCEL 2.0 standard.

Why is this relevant?

  * •

Using OCEL 2.0, it is possible to create a system-agnostic, single source of
truth. Event data should capture real business-relevant events without being
limited by a single-case notion.

  * •

We no longer need to create a new event log for each process (or view on a
selected process). Using traditional event logs, there may be overlapping logs
that refer to products, suppliers, etc. This leads to duplication and
inconsistencies. Using OCEL 2.0, views can be created on demand without going
back to the source systems.

  * •

OCEL 2.0 and the OCPM techniques that build upon it allow us to stay closer to
reality, also allowing organizations to uncover problems that live at the
intersection points of processes and organizational units.

Through a detailed presentation of formal definitions, we built the
mathematical foundation that equips readers to effectively utilize and
understand the OCEL 2.0 standard in a scientific context. Our illustrative
running example served to bridge the gap between abstract theory and practical
application, enabling readers to fully grasp how the principles of OCEL 2.0
come into play.

The detailed overview of the relational SQLite, XML, and JSON implementations
demonstrated the versatility and compatibility of the standard across multiple
technological contexts. Together, these make OCEL 2.0 an accessible and
practical choice for both academics and industry practitioners.

Compared to OCEL 1.0, OCEL 2.0 allows for changes in objects, is able to
relate objects directly, and can qualify relationships between objects and
events. We hope that this will fuel new OCPM techniques using these
extensions. The relational SQLite implementation also shows that this standard
goes beyond file formats like XML, JSON, and Excel. Because the reference
storage format for the XES standard was XML, people often misunderstood the
XES standard. The XES metamodel can be implemented in many different ways.
However, some vendors used the bulkiness XML as an excuse not to support XES,
thus blocking any form of standardization. However, the critical point is the
standardization and unification of concepts (not the serialization of data
using a specific syntax). Therefore, we encourage researchers and software
companies to come up with new storage formats implementing the OCEL 2.0
metamodel and provide conversations. The SQLite, XML, and JSON formats are
just examples, and we provide tools to convert any one of them into the two
other formats. However, we encourage developers to create novel, highly
scalable formats. This is one of the reasons why we kept OCEL 2.0 as simple
and as concrete as possible.

We also hope that OCEL 2.0 will also be the basis for creating standard object
and event types for different application domains. Organizations struggle to
use ontologies and related technologies because the added value of extensively
modeling data is not so clear. OCPM can address this problem. Event data in
OCEL 2.0 format enables process discovery, conformance checking, performance
analysis, and operational support without the need to process the data
further. However, any organization has standard processes like Order-to-Cash
(O2C) and Procure-to-Pay (P2P) that talk about suppliers, customers, orders,
items, shipments, etc. There is no need to reinvent the wheel. Also, one would
like to keep these things system-agnostic. Definitions of object types and
event types and their attributes need to be standardized. It is possible to
define taxonomies of object types and event types using inheritance notions
[2]. This creates possibilities for both generative and discriminative
Artificial Intelligence (AI). Therefore, researchers and solution providers
should focus on creating standard object and event types and the corresponding
normative object-centric process models. This will prevent organizations from
starting from scratch when applying process mining and AI for the first time.

Lastly, it is essential to note that the rapidly evolving field of object-
centric process mining continues to present new challenges and opportunities.
As such, the OCEL 2.0 standard, despite its substantial contribution, should
be seen as a stepping stone in this exciting journey rather than a final
destination. Furthermore, this standard is intended to help pave the path for
the development of process mining techniques supporting the journey to more
sustainable operational practices. We encourage further research and
development efforts to build on this foundation, with the aim of continuously
advancing the field to new heights of innovation and practical value.

You can find further details of OCEL 2.0, example event logs, and tool
support, on our homepage:

https://www.ocel-standard.org

## Acknowledgments

Funded by the Deutsche Forschungsgemeinschaft (DFG, German Research
Foundation) under Germany’s Excellence Strategy - EXC-2023 Internet of
Production - 390621612. We also thank the Alexander von Humboldt (AvH)
Stiftung for supporting our research.

## References

  * [1] W.M.P. van der Aalst.  Process Mining: Data Science in Action.  Springer-Verlag, Berlin, 2016.
  * [2] W.M.P van der Aalst.  Object-Centric Process Mining: Unraveling the Fabric of Real Processes.  Mathematics, 11(12):2691, 2023.
  * [3] W.M.P. van der Aalst and A. Berti.  Discovering Object-Centric Petri Nets.  Fundamenta Informaticae, 175(1-4):1–40, 2020.
  * [4] W.M.P. van der Aalst and J. Carmona, editors.  Process Mining Handbook, volume 448 of Lecture Notes in Business Information Processing.  Springer-Verlag, Berlin, 2022.
  * [5] G. Acampora, A. Vitiello, B. Di Stefano, W. van der Aalst, C. Günther, and E. Verbeek.  IEEE 1849: The XES Standard - The Second IEEE Standard Sponsored by IEEE Computational Intelligence Society.  IEEE Computational Intelligence Magazine, 12(2):4–8, 2017.
  * [6] J.N. Adams, G. Park, S. Levich, D. Schuster, and W.M.P. van der Aalst.  A Framework for Extracting and Encoding Features from Object-Centric Event Data.  In J. Troya, B.Medjahed, M.Piattini, L. Yao, P. Fernández, and A. Ruiz-Cortés, editors, International Conference on Service-Oriented Computing (ICSOC 2022), volume 13740 of Lecture Notes in Computer Science, pages 36–53. Springer-Verlag, Berlin, 2022.
  * [7] A.F. Ghahfarokhi, G. Park, A. Berti, and W.M.P. van der Aalst.  OCEL Standard.  www.ocel-standard.org, 2020.
  * [8] A.F. Ghahfarokhi, G. Park, A. Berti, and W.M.P. van der Aalst.  OCEL: A Standard for Object-Centric Event Logs.  In L. Bellatreche, M. Dumas, and P. Karras, editors, New Trends in Database and Information Systems (Short Papers ADBIS 2021), volume 1450 of Communications in Computer and Information Science, pages 169–175. Springer-Verlag, Berlin, 2021.
  * [9] IEEE.  IEEE Standard for eXtensible Event Stream (XES) for Achieving Interoperability in Event Logs and Event Streams.  IEEE Std 1849-2023 (Revision of IEEE Std 1849-2016), pages 1–55, 2023.  10.1109/IEEESTD.2023.10267858.
  * [10] IEEE Task Force on Process Mining.  XES Standard Definition.  www.xes-standard.org, 2010.
  * [11] M. Kerremans, K. Iijima, A. Sachelarescu, N. Duffy, and D. Sugden.  Magic Quadrant for Process Mining Tools, Gartner Research Note GG00774746.  www.gartner.com, 2023.
  * [12] M.T. Wynn, J. Lebherz, W.M.P. van der Aalst, R. Accorsi, C. Di Ciccio, L. Jayarathna, and H.M.W. Verbeek.  Rethinking the Input for Process Mining: Insights from the XES Survey and Workshop.  In J. Munoz-Gama and X. Lu, editors, Process Mining Workshops of the International Conference on Process Mining (Revised Selected Papers), volume 433 of Lecture Notes in Business Information Processing, pages 3–16. Springer-Verlag, Berlin, 2021.