Alessandro Berti

Wil Van Der Aalst

Extracting Multiple Viewpoint Models from Relational Databases

Keywords: Process Mining, Process Discovery, Artifact-Centric Process Models, Relational Databases

Much time in process mining projects is spent on finding and understanding data sources and extracting the event data needed. As a result, only a fraction of time is spent actually applying techniques to discover, control and predict the business process. Moreover, current process mining techniques assume a single case notion. However, in reallife processes often different case notions are intertwined. For example, events of the same order handling process may refer to customers, orders, order lines, deliveries, and payments. Therefore, we propose to use Multiple Viewpoint (MVP) models that relate events through objects and that relate activities through classes. The required event data are much closer to existing relational databases. MVP models provide a holistic view on the process, but also allow for the extraction of classical event logs using different viewpoints. This way existing process mining techniques can be used for each viewpoint without the need for new data extractions and transformations. We provide a toolchain allowing for the discovery of MVP models (annotated with performance and frequency information) from relational databases. Moreover, we demonstrate that classical process mining techniques can be applied to any selected viewpoint.

Introduction

Process mining is a growing branch of data science that aims to extract insights from event data recorded in information systems. Examples of process mining techniques include process discovery algorithms that are able to find descriptive process models, conformance checking algorithms that compare event data with a given process model to find deviations, and predictive algorithms that use the discovered process model to anticipate bottlenecks or compliance problems. Gathering high-quality event data is a prerequisite for the successful application of process mining projects. However, event data are often hidden in existing information systems (e.g., the ERP systems of SAP, Microsoft, Oracle). Most systems are built on top of relational databases, to ensure data integrity and normalization. Relational databases contain entities (tables) and relations between entities. Events correspond to updates of the database, i.e., changes of the "state" of the information system. These updates may have been stored in tables of the databases (through in-table versioning like the change tables in SAP or any table that contains dates or timestamps) or can be retrieved using some database log (like redo logs [START_REF] Yano | A practical approach to automated business process discovery[END_REF][START_REF] De Murillas | Redo log process mining in real life: Data challenges & opportunities[END_REF] explicitly storing all database updates).

Extracting events from a database requires domain knowledge and may be very time-consuming. One of the reasons is that process mining techniques require a classical event log where each event needs to refer to a case. The case notion is used to "correlate" events and the corresponding process model shows the life-cycle model for the selected case notion. However, in the same process there may be suppliers, customers, orders, order lines, deliveries, and payments. These correspond to objects of the class model describing the database. One event may refer to a subset of such objects. A payment may refer to the payment itself, a customer, and an order. A delivery may refer to the delivery itself, but also to a subset of order lines or even multiple orders. Several views on the database could be retrieved, this means that, for the same database, several event logs and process models need to be extracted. When the process involves many different entities, the construction of the view is not easy. While there are some methods to automatically infer a/some case notion(s) from unstructured data [START_REF] Bayomie | Deducing case ids for unlabeled event logs[END_REF][START_REF] Helal | Runtime deduction of case id for unlabeled business process execution events[END_REF][START_REF] Burattin | A framework for semi-automated process instance discovery from decorative attributes[END_REF], in most cases the specification happens manually. Moreover, the data extractions and transformations may be time-consuming and one quickly loses the overview. This often leads to divergence and convergence errors: events are forgotten or inadvertently duplicated leading to incorrect conclusions. This paper introduces a new modeling technique that is able to calculate a graph where relationships between activities are shown without forcing the user to specify a case notion, since different case notions are combined in one succint diagram. The resulting models are called MVP models. Such models belong to the class of artifact-centric models [START_REF] Cohn | Business artifacts: A data-centric approach to modeling business operations and processes[END_REF][START_REF] Nigam | Business artifacts: An approach to operational specification[END_REF] that combine data and process in a holistic manner to discover patterns and check compliance [START_REF] Lohmann | Compliance by design for artifact-centric business processes[END_REF]. MVP models are annotated with frequency and performance information (e.g., delays) and provide a holistic view on the whole process. The colors of the relationships refer to the original classes. Using frequency based filtering and selections the MVP model can be seamlessly simplified. Any non-empty subset of classes provides a viewpoint. Given a viewpoint and an MVP model, we can automatically generate a classical event log and apply existing process mining techniques. Hence, the holistic view of the MVP model is complemented by detailed viewpoint models using conventional notations like Petri nets, BPMN models, process trees, or simple directly-follows graphs.

The techniques have been implemented using PM4Py (pm4py.org). In-memory computation is used to handle large data sets quickly. The approach has been evaluated using a log extracted from a real-life information system, and has proven to scale linearly with the number of events, classes and asymptotically linearly with the number of objects per class, while the execution time grows quadratically with the number of activities. This is a stark contrast with existing techniques (like OCBC models) with significantly worse complexity. Fig. 1. Illustration of the approach using an example database taken from [START_REF] De Murillas | Connecting databases with process mining: a meta model and toolset[END_REF]. The classes are highlighted using different colors and labels on arcs. Based on a viewpoint (i.e., a set of classes) a classical event log can be generated and analyzed.

In Section 7.4, an assessment on real-life database event logs is done. Moreover, a comparison with some existing techniques (OpenSLEX [START_REF] De Murillas | Connecting databases with process mining: a meta model and toolset[END_REF][START_REF] De Murillas | Process mining on databases: extracting event data from real life data sources[END_REF] and OCBC models [START_REF] Van Der Aalst | Object-centric behavioral constraints[END_REF]) is performed, considering the execution time and the usability of these approaches.

The remainder of the paper is organized as follows. Section 2 presents related work. In Section 3 classical and database event logs are introduced. Section 4 presents our approach to discover Multiple Viewpoint (MVP) models including Event-to-Object (E2O) graphs, Event-to-Event (E2E) multigraphs, and Activity-to-Activity (A2A) multigraphs. Section 5 introduces the notion of viewpoints and the automatic creation of classical event logs. Section 6 presents our implementation using PM4Py. In Section 7, we evaluate MVP models and our implementation by comparing results for real-life data sets with competing techniques.

2 Related Work Fig. 2. Comparison of four different process mining ETL scenarios. Classical log extraction consider different queries, possibly targeting different tables, to prepare event logs for classic process mining techniques. OpenSLEX provides an easier access point to retrieve event data, but still requires the manual specification of database queries. OCBC technique extracts a single process model from the database schema, that could be useful for the purpose of understanding and checking the schema, but provide no way to retrieve a classical event log. The MVP technique, on the other hand, provides an easy visualization of the relationships between activities on top of a database, moreover it provides the possibility to get formal models (directly from the MVP models) and event logs to use with classic process mining techniques.

Related work may be divided into different categories:

-Approaches to extract event data from databases and to make queries easier.

-Representation of Artifact-centric models.

-Discovery of process models combining several case notions.

A few example approaches are shown in Fig. 2 and related to MVP models.

Related Work: Extracting Event Data From Databases

There has been earlier work on making SQL queries easier [START_REF] Calvanese | Ontop: Answering sparql queries over relational databases[END_REF][START_REF] Bouchou | Semantic mediator querying[END_REF]. The basic idea is to provide the business analyst a way to express queries in a simpler language (SPARQL query). Some other papers related to database querying in the context of process management are [START_REF] Momotko | Process query language: A way to make workflow processes more flexible[END_REF][START_REF] Liu | Semantic enabled complex event language for business process monitoring[END_REF][START_REF] Song | Querying process models based on the temporal relations between tasks[END_REF][START_REF] Metzke | Enabling semantic complex event processing in the domain of logistics[END_REF][START_REF] Tang | Querying workflow logs[END_REF].

In [START_REF] Nooijen | Automatic discovery of data-centric and artifact-centric processes[END_REF], an automated technique to discover, for each notion of data object in the process, a separate process model that describes the evolution of this object, is presented. The technique is based on relational databases, and decomposes the data source into multiple logs, each describing the cases of a separate data object.

The OpenSLEX [START_REF] De Murillas | Connecting databases with process mining: a meta model and toolset[END_REF][START_REF] De Murillas | Process mining on databases: extracting event data from real life data sources[END_REF] is an high-level meta-model, that permits easier queries, obtained from the raw database data scattered through tables (for example, the case identifier, the activity and the timestamp may be columns of different tables that need to be joined together). The aim of OpenSLEX is to let user focus on the analysis, dealing only with elements such as events, activities, cases, logs, objects, objects versions, object classes and attributes that are introduced in [START_REF] De Murillas | Connecting databases with process mining: a meta model and toolset[END_REF]. The meta-model could be seen as a schema that captures all the pieces of information necessary to apply process mining to database environments. To obtain classical event logs, a case notion (connecting events to each other) needs to be used. The OpenSLEX implementation provides indeed some connectors for database logs (redo logs, in-table versioning, or specific database formats [START_REF] De Murillas | Process mining on databases: extracting event data from real life data sources[END_REF][START_REF] Ingvaldsen | Preprocessing support for large scale process mining of SAP transactions[END_REF]). In the implementation described in [START_REF] De Murillas | Connecting databases with process mining: a meta model and toolset[END_REF], OpenSLEX is supported by an SQLite database.

Related Work: Representation of Artifact-Centric Models

Business artifacts (cf. [START_REF] Cohn | Business artifacts: A data-centric approach to modeling business operations and processes[END_REF][START_REF] Narendra | Towards a unified approach for business process modeling using context-based artifacts and web services[END_REF]) combine data and process in an holistic manner as the basic building block. These correspond to key business entities which evolve as they pass through the business's operation.

In [START_REF] Bhattacharya | Towards formal analysis of artifact-centric business process models[END_REF] a formal artifact-based business model, and declarative semantics based on the use of business rules, are introduced along with a preliminary set of technical results on the static analysis of the semantics of an artifact-based business process model.

The Guard-Stage-Milestone (GSM) meta-model [START_REF] Hull | Introducing the guardstage-milestone approach for specifying business entity lifecycles[END_REF][START_REF] Hull | Business artifacts with guard-stage-milestone lifecycles: managing artifact interactions with conditions and events[END_REF] is a formalism for designing business artifacts in which the intended behavior is described in a declarative way, without requiring an explicit specification of the control flow.

Some approaches which focus on compliance checking are introduced in [START_REF] Knuplesch | On enabling dataaware compliance checking of business process models[END_REF][START_REF] Ly | Monitoring business process compliance using compliance rule graphs[END_REF]. In [START_REF] Knuplesch | On enabling dataaware compliance checking of business process models[END_REF], support for data-aware compliance rules is proposed in a scalable way thanks to an abstraction approach that can serve as preprocessing step to the actual compliance checking. In [START_REF] Ly | Monitoring business process compliance using compliance rule graphs[END_REF], compliance rule graphs are introduced, that are a framework with support for root cause analysis, and that can provide assistance in proactively enforcing compliance by deriving measures to render the rule activation satisfied. In [START_REF] Fahland | Behavioral conformance of artifact-centric process models[END_REF], conformance checking on artifact-centric processes is approached by partitioning the problem into behavioral conformance of single artifacts and interaction conformance between artifacts, solving behavioral conformance by a reduction to existing techniques.

In [START_REF] Steinau | The relational process structure[END_REF], the concept of relational process structure is introduced, aiming to overcome some limitations of small processes such as artifacts, object lifecycles, or proclets. In these paradigms, a business process arises from the interactions between small processes. However, many-to-many relationships support is lacking. The relational process structure provides full support for many-to-many relationships and cardinality constraints at both design-and run-time.

Related Work: Discovery of Process Models Using Several Case Notions

Fig. 3. Representation of a small Object-centric Behavioral Constraint (OCBC) model (taken from [START_REF] Van Der Aalst | Object-centric behavioral constraints[END_REF]).

In this category, we aim to describe some models that could be discovered by combining several case notions, or studying the interactions between the different case notions: interacting artifacts [START_REF] Lu | Discovering interacting artifacts from ERP systems (extended version)[END_REF], multi-perspective models [START_REF] Van Eck | Discovering and exploring statebased models for multi-perspective processes[END_REF], object-centric models [START_REF] Van Der Aalst | Object-centric behavioral constraints[END_REF].

In [START_REF] Lu | Discovering interacting artifacts from ERP systems (extended version)[END_REF], a semi-automatic approach is presented to discover the various objects supporting the system from the plain database of an ERP (Enterprise Resources Planning) system. An artifact-centric process model is identified describing the system's objects, their life-cycles, and some detailed information about interactions between objects.

Multi-instance mining [START_REF] Van Eck | Discovering and exploring statebased models for multi-perspective processes[END_REF] was introduced to discover models where different perspectives of the process can be identified. Instead of focusing on the events or activities that are executed in the context of a particular process, the focus is on the states of the different perspectives and on the discovery of the relationships between them. The Composite State Machine Miner [START_REF] Van Eck | Composite state machine miner: Discovering and exploring multi-perspective processes[END_REF] supports the approach [START_REF] Van Eck | Discovering and exploring statebased models for multi-perspective processes[END_REF]. It quantifies and visualises the interactions between perspectives to provide additional process insights.

Object-centric models [START_REF] Van Der Aalst | Object-centric behavioral constraints[END_REF] are process models, involving entities and relations in the ER model, where multiple case notions may coexist. A small OCBC model is represented in Fig. 3. In the representation, the lower part (yellow) represents the class model, and the upper part represents the activities and the constraints between them. The activities and the classes are connected by arcs if they are in relationship. OCBC models can be discovered, and can be used for compliance checking, from XOC logs. The XOC format is important because it extends the XES format with support to database-related information (related objects, relationships, state of the object model), and is one of the few choices to store database event logs along with instances of the OpenSLEX meta-model. XOC logs are using XML and contain a list of events. Each event is referring some objects, and contains the status of the database at the moment the event happened. In [START_REF] Li | Automatic discovery of object-centric behavioral constraint models[END_REF], the algorithm to infer OCBC models is described, that takes an XOC log as well as a set of possible behavioral constraint types as input, that means users can specify the constraint type set based on their needs. ProM 6 plug-ins have been realized to import XOC logs, for the discovery of a process model, and for conformance checking on top of OCBC models. The discovery algorithm can discover constraints of 9 different types.

Database Event Logs

Relational databases are organized in entities (classes of objects sharing some properties), relationships (connections between entities [START_REF] Chen | The entity-relationship model toward a unified view of data[END_REF]), attributes (properties of entities and relationships). Events can be viewed as updates of a database (e.g. insertion of new objects, changes to existing objects, removal of existing objects). Some ways to retrieve events from databases are:

-Using redo logs (see [START_REF] De Murillas | Connecting databases with process mining: a meta model and toolset[END_REF]). These are logs where each operation in the database is saved with a timestamp; this helps to guarantee consistency, and possibility to rollback and recovery. -Using in-table versioning. In this case, the primary key is extended with a timestamp column. For each phase of the lifecycle of an object, a new entry is added to the in-table versioning, sharing the base primary key values but with different values for the timestamp column.

An event may be linked to several objects (for example, the event that starts a marketing campaign in a CRM system may be linked to several customers), and an object may be linked to several events (for example, each customer can be related to all the tickets it opens). For the following definition, let U E be the universe of events (all the events happening in a database context), U C be the universe of case identifiers, U A be the universe of activities (names referring to a particular step of a process), U attr be the universe of attribute names (all the names of the attributes that can be related to an event), U val be the universe of attribute values (all the possible values for attributes).

In this paper we consider event data closer to real-life information systems. Before providing a definition for database event logs, we define the classical event log concept.

Definition 1 (Classical Event Log) A log is a tuple L = (C I , E, A, case ev, act, attr, ≤) where:

-C I ⊆ U C is a set of case identifiers. -E ⊆ U E is a set of events. -A ⊆ U A is the set of activities.
case ev ∈ C I → P(E)\{∅} maps case identifiers onto set of events (belonging to the case). act ∈ E → U A maps events onto activities.

attr ∈ E → (U attr → U val ) maps events onto a partial function assigning values to some attributes. -≤ ⊆ E × E defines a total order on events. This classical event log notion matches the XES storage format [START_REF] Verbeek | Xes, xesame, and prom 6[END_REF], that is the common source of information for process mining tools like Disco, ProcessGold, Celonis, QPR, Minit, . . . An example attribute of an event e is the timestamp attr(e)(time) which refer to the time the event happened. While, in general, an event belongs to a single case, in Def. 1 the function case ev might be such that cases share events.

For events extracted from a database, the function case ev is not given, since an event may be related to different objects, and different case notions may exist. In the following Def. 2, database event logs are introduced.

Definition 2 (Database Event Log) Let U O be the universe of objects (all the objects that are instantiated in the database context) and U OC be the universe of object classes (a class defines the structure and the behavior of a set of objects). A database event log is a tuple L D = (E, O, C, A, class, act, attr, EO, ≤) where:

-E ⊆ U E is the set of events. -O ⊆ U O is the set of objects. -C ⊆ U OC is the set of object classes. -A ⊆ U A is the set of activities.
class : O → C is a function that associates each object to the corresponding object class. act ∈ E → A maps events onto activities.

attr ∈ E → (U attr → U val ) maps events onto a partial function assigning values to some attributes. -EO ⊆ E × O relates events to sets of object references.

-≤ ⊆ E × E defines a total order on events. This definition differs from Def. 1 because a case notion is missing (no case ev function) and events are related to objects in a possible many-to-many relation. A function EO is introduced that relates events to sets of object references. Moreover, the sets of objects and classes in the event log are specified, and a function class that associates each object to its class is introduced.

Approach to Obtain MVP models

In this section, the different ingredients of MVP models will be introduced. The E2O graph will be obtained directly from the database logs; the E2E multigraph will be obtained in linear complexity by calculating directly-follows relationships between events in the perspective of some object; the A2A multigraph will be obtained in linear complexity by calculating directly-follows relationships between activities in the perspective of some object class, using the information stored in the E2E multigraph. The A2A multigraph is the main contributor to the visualization of the MVP model. A projection function will be given in Section 5 to obtain a classical event log when a so-called viewpoint is chosen. MVP models are composed of several graphs (E2O, E2E, A2A) and auxiliary functions (a complete definition will be presented at the end of this section), and are constructed by reading a representation of event data retrieved from a database (importing from intermediate structures like OpenSLEX or XOC logs).

Definition 3 (E2O Graph) Let L D = (E, O, C, A, class, act, attr, EO, ≤) be a database event log. The Event-to-Object graph (E2O) corresponding to the database event log L D can be defined as:

E2O(L D ) = (E ∪ O, EO)
Here, the nodes are the events (E) and the objects (O), and EO (as retrieved from the log) is a subset of E × O. ) be a database event log. The Event-to-Event multigraph (E2E) on the database event log L D can be defined as:

E2E(L D ) = (E, F E , Π E perf )
Where the nodes are the events (E) and the set of edges F E is defined as:

F E = {(e 1 , e 2 , o) ∈ E × E × O | ∃ 2≤i≤| O(o)| O i-1 (o) = e 1 , O i (o) = e 2 }
and Π E perf :

F E → R + ∪ {0}, Π E
perf (e 1 , e 2 , o) = attr(e 2 )(time) -attr(e 1 )(time) associates each edge to a non-negative real number expressing its duration (performance).

The introduction of the set F E is useful for the definition of the A2A multigraph. Although it does not make sense to represent the overall E2E multigraph, involving relationships between all events, it may be useful to display directlyfollows relationships involving a small subgroup of events.

AE(a 1 , a 2 , c) = {(e 1 , e 2 , o) ∈ F E | act(e 1 ) = a 1 ∧ act(e 2 ) = a 2 ∧ class(o) = c}
The AE function associates to each triple (a 1 , a 2 , c) the set of all the events of the corresponding activities and classes. The Activity-to-Activity multigraph (A2A) on the database event log L D can be defined as:

A2A(L D ) = (A, F A , Π A count , Π A perf )
Where the nodes are the activities (A), the set of edges F A is defined as:

F A = {(a 1 , a 2 , c) ∈ A × A × C | AE(a 1 , a 2 , c) = ∅}
and:

-Π A count (a 1 , a 2 , c) = |AE(a 1 , a 2 , c
)| is the number of occurrences associated to the edge (a 1 , a 2 , c) ∈ F A , that is the number of corresponding edges contained in AE(a 1 , a 2 , c).

-Π A perf (a 1 , a 2 , c) = f E ∈AE(a 1 ,a 2 ,c) Π E perf (f E ) Π A count (a1,a2,c)
is the performance associated to the edge (a 1 , a 2 , c) ∈ F A , that is the average of the duration of the corresponding edges contained in AE(a 1 , a 2 , c). An high average duration may correspond to a bottleneck in the process.

The following definitions are useful for the representation of an MVP model, introducing clear start and end points for each class and contributing to the possibility to filter out edges.

Definition 7 (Start and End Activities of a Class)

Let L D = (E, O, C, A, class, act, attr, EO, ≤) be a database event log. Let c ∈ C be a class. The following functions are defined:

-START A (L D ) : C → P(A), START A (L D )(c) = {act( O 1 (o)) | o ∈ O ∧ | O(o)| ≥ 1 ∧ class(o) = c} is the set of start activities of class c. -END A (L D ) : C → P(A), END A (L D )(c) = {act( O | O(o)| (o)) | o ∈ O∧| O(o)| ≥ 1 ∧ class(o) = c} is the set of end activities of class c.

Definition 8 (Dependency Threshold between Activities given a Class)

Let L D = (E, O, C, A, class, act, attr, EO, ≤) be a database event log. Let F A be the set of edges in A2A(L D ). For (a 1 , a 2 , c) ∈ F A it is possible to define a dependency measure in the following way:

dep A (L D ) : F A → [0, 1] dep A (L D )(a 1 , a 2 , c) =    Π A count (a1,a2,c) Π A count (a1,a2,c)+1 if a 1 = a 2 ∨ (a 2 , a 1 , c) ∈ F A Π A count (a1,a2,c)-Π A count (a2,a1,c) Π A count (a1,a2,c)+Π A count (a2,a1,c)+1 if a 1 = a 2 ∧ (a 2 , a 1 , c) ∈ F A Definition 9 (MVP Discovery) Let L D = (E, O, C, A
, class, act, attr, EO, ≤) be a database event log. We define as MVP model discovered from the log L D , and we refer to it as MVP(L D ), the following object:

MVP(L D ) = (L D , E2O(L D ), E2E(L D ), A2A(L D ), START A (L D ), END A (L D ), dep A (L D ))
Given a dependency threshold d ∈ [-1, 1], a representation of an MVP model draws as many edges between a couple of activities (a 1 , a 2 )

∈ A × A as the number of classes c ∈ C such that dep A (L D )(a 1 , a 2 , c) is defined and dep A (L D )(a 1 , a 2 , c) ≥ d.
The visualization of a MVP model is valuable: -An holistic view on the classes and the activities of the database, and on the order in which they happen, is provided. -Arcs are decorated with frequency/performance information. Frequency information helps to understand the most frequent paths of a process, and performance information helps to discover the bottlenecks of a process.

Viewpoints: Retrieval of DFGs and Logs

The goal of this section is to provide some ways to retrieve, from an MVP model MVP(L D ), built upon the database event log L D , a particular viewpoint on the model.

Definition 10 (Viewpoint)

Let L D = (E, O, C, A, class, act, attr, EO, ≤) be a database event log. Let

MVP(L D ) = (L D , E2O(L D ), E2E(L D ), A2A(L D ), START A (L D ), END A (L D ), dep A (L D ))
be an MVP model. A viewpoint is a set of classes V (L D ) ⊆ C. A viewpoint is corresponding to a subset of edges in the E2E graph (that is F E ):

V E (L D ) = {(e 1 , e 2 , o) ∈ F E | o ∈ V (L D )}
From a view, we can obtain two different final outputs.

-A Directly-Follows Graph (DFG), that includes the edges related to the classes contained in V (L D ). -A classical event log, that includes all the events that are related to the objects having a class contained in V (L D ).

An example of projection could be found in Fig. 8, where a singleton viewpoint containing a single class is chosen, a Directly-Follows Graph is obtained and a Petri net is obtained through the application of Inductive Miner Directly-Follows.

Projection on a Directly-Follows Graph

The concept of a Directly-Follows Graph is introduced in the following definition: Where N DFG (the nodes) are the activities, and E DFG ⊆ N DFG × N DFG is the set of all the edges between activities that happened in direct succession, and c DFG : E DFG → R + is the count function that aims to represent how many times two different activities happened in direct succession.

Projection on a Log

The projection of an MVP model MVP(L D ) obtained from a database event log L D to a classical event log (see Section 3) could be introduced when a viewpoint V (L D ) ⊆ C is chosen.

Indeed, the information contained in an MVP model could be used to determine a case notion C D that is used to transform the database event log L D into a classical event log, in a way that events belonging to the same process execution can be grouped.

The definition of case notion on database event logs could be introduced:

Definition 13 (Case Notion) Let L D = (E, O, C, A, class, act, attr, EO, ≤) be a database event log. A case notion is a set of sets of events C D ⊆ P(E) \ {∅}.

The case notion does not need to cover all the events contained in E, moreover the intersection between sets of events contained in the case notion may also not be empty. An example of case notion could be provided. Let E = {e 1 , e 2 , e 3 , e 4 , e 5 , e 6 } be a set of events. Then a case notion might be C D = {{e 1 , e 2 }, {e 3 , e 4 }, {e 1 , e 4 , e 5 }}. Let's note that the union of all these sets is not E, and the intersection between {e 1 , e 2 } and {e 1 , e 4 , e 5 } is not empty.

When a case notion is defined, it is possible to define the projection function from the database event log L D to the classical event log. An assumption is that the case notion C D is contained in the universe of case identifiers U C . This helps to define the function case ev in a simpler way. Given an MVP model MVP(L D ) and a viewpoint V (L D ) on that defines a set of edges V E (L D ) in the E2E multigraph, a case notion is defined as:

C D =    o ∈O,class(o )∈V (L D ), O(o)∩ O(o ) =∅ O(o ) | o ∈ O, class(o) ∈ V (L D )    A classical event log is obtained as L = proj(L D , C D ).

Tool

MVP Models have been implemented in a feature branch of the PM4Py Process Mining library1 [START_REF] Berti | Process Mining for Python (PM4Py): Bridging the Gap Between Process-and Data Science[END_REF]. The architecture of the tool provides a clear separation between the management of the log (object), the MVP discovery algorithm and the MVP visualization. Moreover, utilities have been provided to generate a database event log and to visualize the E2O and the E2E multigraphs. A reference technical manual with a description of the features provided in tool is contained in http://www.alessandroberti.it/technical.pdf.

The provided features are:

- Fig. 9. Representation of a database log in the Parquet columnar format. This is different from classic CSV event logs since the same event is repeated in multiple rows, one for each related object. Both information related to events and related objects are columns of a table. This structure reflects the way information is stored inside the in-memory Pandas dataframe that supports the filtering and the discovery operations.

-logOpportunities.parquet is the database log used in the assessment and extracted from the Dynamics CRM system. metamodel.slexmm provides the OpenSLEX metamodel of the Concert database.

erp.xoc provides an example XOC log extracted from a Dollibar ERP system.

The storage used in the tool for the database event logs is represented in Fig. 9. Several rows are associated to an event, and contain an ID, an activity, a timestamp, and a single object identifier in the column corresponding to its class. This permits to store events in a tabular format using basic types for the columns (strings, integers, dates) to maximize the query performance.

Assessment

The assessment of MVP models will show how they perform against two competing approaches (OCBC models [START_REF] Li | Automatic discovery of object-centric behavioral constraint models[END_REF] and OpenSLEX [START_REF] De Murillas | Connecting databases with process mining: a meta model and toolset[END_REF]), both considering the execution time and the simplicity/readability/amount of information contained in the models. These approaches have been chosen because are very recent. The scalability of the MVP models implementation contained in PM4Py will be analyzed on some synthetic logs. Moreover, an assessment using a real information system (Microsoft Dynamics CRM) will be shown. b) Difference in discovery speed between MVP models (the line with green dots) and OCBC models (the line with orange dots) for different data sets. Fig. 10. Comparison between MVP models and OCBC models, in (a) size on disk of the proposed log storage b) discovery speed. The XOC format that is tested is the one described in [START_REF] Van Der Aalst | Object-centric behavioral constraints[END_REF].

Comparison with Related Approaches

OCBC models are powerful descriptions of the relationships between activities and classes at the database level. Having said that, OCBC models have scalability issues: XOC logs as proposed in [START_REF] Van Der Aalst | Object-centric behavioral constraints[END_REF] store a snapshot of the object model per event, this becomes quickly unfeasible also for few hundred database events (as it will shown in the assessment). In [START_REF] De Carvalho | Extracting object-centric event logs to support process mining on databases[END_REF], an updated version of XOC, storing in each event the updates to the object model, has been proposed, although a XOC event log in such format is not public available. Moreover, the final visualization (even if it can be filtered on some types of constraints) lacks understandability. A serious issue is the lack of support for frequency/performance decoration (i.e. the number of occurrences of the arc, the time passed between activity).

OpenSLEX provides a way to ingest a database event log into a meta-model instance that is easier to query. An issue is that they do not offer any visual clue on underlying relationships between activities, making the life difficult to the user in first instance. Moreover, although the queries on OpenSLEX are easier than the queries done directly on the database, there is an effort required by the user to understand the concepts described in [START_REF] De Murillas | Connecting databases with process mining: a meta model and toolset[END_REF].

Evaluation of the Execution Time

OCBC models (tests have been performed on the original version of XOC, proposed in [START_REF] Van Der Aalst | Object-centric behavioral constraints[END_REF], for which several logs are public available) have scalability problems with regards to the log format (XOC), that requires the storage, for each event, of the status of the entire object model. In Fig. 10 (a), the size on disk (in KB) of a log containing the specified number of events has been considered. To obtain an OCBC model, for a log with just 661 events, a XOC log of 512 MB is required, that is 17476 greater than the amount of disk space that permits to discover an MVP model from the same database.

In Fig. 10 (b), the execution speed of the discovery procedure has been compared between MVP models and OCBC models. To obtain an OCBC model, for a log with just 249 events, a time of 4 minutes and 20 seconds is required, while for discovering an MVP model from the same database 2 seconds are required, that is 127 times faster. This result holds also for the new version of the XOC format [START_REF] De Carvalho | Extracting object-centric event logs to support process mining on databases[END_REF], since in the later version the object model is built in-memory by the discovery algorithm starting from the updates described in the event log.

With OpenSLEX, the comparison is more tight, although the final goal is different: OpenSLEX require a query to get a classical event log, while MVP models do not require this effort. There is only a meta-model instance available in public, that has been extracted from a synthetic database on concert management. The amount of storage required to store the OpenSLEX instance is 11 MB, while the amount of storage that permits to discover an MVP model is 222 KB (storing using Parquet format). To compare the (time) performance of OpenSLEX and MVP models, a query on the OpenSLEX instance needs to be performed. Starting in both cases from the concert database instance of the OpenSLEX meta-model, if an example query2 is chosen, the execution speed of the query on the OpenSLEX instance is 1.73 seconds. The time needed for MVP models to obtain a complete model with frequency and performance information is 1.96 seconds, this without requiring the specification of any query by the user.

Usability of the Approaches

OCBC and MVP models both provide ways to discover a model on top of database event logs. The amount of information and constraints extracted by OCBC models is very high, and although filtering is provided to keep only some constraints, the resulting process model is complex to understand. An explanation of some ingredients of OCBC models is provided by [START_REF] Li | Automatic discovery of object-centric behavioral constraint models[END_REF] and represented in Fig. 11. This amount of information is insane, but it is very difficult also for a process analyst to be able to understand it without proper training.

Moreover, this class of models does not provide frequency/performance information, that can be useful for the process analyst in order to detect the bottlenecks. MVP models, as represented in Fig. 12, can provide a graph in which edges are decorated by frequency/performance information. With MVP models, the following features are also available, that are not available on OCBC models: -Projection to a classic directly-follows graph to be used with techniques like Inductive Miner Directly-Follows and the Heuristics Miner. -Projection to a classical event log to be used with mainstream process mining techniques.

OpenSLEX do not provide a visualization of a process model on top of the database, but require to the user the specification of a query to retrieve an event log. This is an unavoidable step, and requires time and expertise by the user. So, the retrieval of a process model using MVP requires less time and less knowledge than the retrieval from OpenSLEX.

Scalability of the Approach

In the previous section, MVP models have shown greater scalability and usability in comparison to some competing approaches. In this section, the goal is to understand more clearly the performance of the current implementation.

An assessment of the approach on simulated logs (through the log generator included in PM4Py) has been done (see Fig. 13) to see which variables influence the execution time in a quadratic way, and which variables influence it in a linear way:

a) assesses the performance of MVP discovery with the increase of the number of activities, when the number of classes, the number of objects per class and the number of events in the log is kept fixed. The execution time (in seconds) grows quadratically with the number of activities. b) assesses the performance of MVP discovery with the increase of the number of objects per class, when the number of classes, the number of activities and the number of events in the log is kept fixed. Although the behavior in the figure looks erratic, the execution time (in seconds) grows asymptotically linearly with the number of objects per class. c) assesses the performance of MVP discovery with the increase of the number of classes, when the number of objects per class, the number of activities and the number of events in the log is kept fixed. The execution time (in seconds) grows linearly with the number of classes. d) assesses the performance of MVP discovery with the increase of the number of events in the log, when the number of classes, the number of objects per class and the number of activities in the log is kept fixed. The execution time (in seconds) grows linearly with the number of events.

Evaluation using CRM Data

This section presents a study of data extracted from a Microsoft Dynamics CRM demo and analyzed using MVP discovery. A Customer Relationship Management system (CRM) [START_REF] Buttle | Customer relationship management[END_REF] is an information system used to manage the commercial lifecycle of an organization, including management of customers, opportunities and marketing campaigns. Many companies actually involve a CRM system for helping business and sales people to coordinate, share information and goals. Data extracted from Microsoft Dynamics CRM is particularly interesting since this product manages several processes of the business side, providing the possibility to define workflows and to measure KPI also through connection to the Microsoft Power BI business intelligence tool. For evaluation purposes, a database log has been generated containing data extracted from a Dynamics CRM demo. The database supporting the system contains several entities, and each entity contains several entries related to activities happening in the CRM. Each entry could be described by a unique identifier (UUID), the timestamp of creation/change, the resource that created/modified the entry, and some UUIDs of other entries belonging to the same or to different entities. Moreover, each entry is uniquely associated with the entity it belongs to.

The following strategy has been pursued in order to generate a log:

-For each entry belonging to an entity, two events have been associated: creation event (with the timestamp of creation and lifecycle start) and modify event (with the timestamp of modification and lifecycle complete). -Each entry belonging to an entity has also been associated with an object.

-Relationships between events and objects are created accordingly to the relationships expressed by the entries (an entry may cite several UUIDs of other entries stored in the database).

The previous construction means that for the same entry there are two events (start+complete) and one object in the log. The database log contains 5863 events, 4413 objects, 120 activities and 80 object classes, and could be stored in a 386 KB Parquet file. The complete MVP model (525 edges) can be calculated and represented in 5 seconds. Taking a viewpoint containing only classes related to opportunities management (e.g. opportunities, opportunityproducts, campaigns, connections), and choosing the frequency metric, the model obtained is represented in Fig. 14. Projecting the MVP model on a viewpoint containing only the 'opportunities' class and applying Inductive Miner Directly-Follows, the process model represented in Fig. 15 is obtained.

Being able to handle this complex database schema and visualize a model that unifies the different classes, in a very reasonable time, is a thing that is impossible with competing approaches like OCBC models (due to severe scalability issues) and OpenSLEX instances (because the resulting query would be more complex than selecting a viewpoint from an holistic model).

Conclusion

This paper introduces Multiple Viewpoint models (MVP), providing an holistic view on a process supported by a database. MVP models are annotated with frequency and performance measures (e.g., delays), supporting the detection of the most frequent paths and of the bottlenecks without the specification of any case notion. At the same time, a viewpoint (a non-empty subset of classes) can be chosen on the MVP models in order to get classical objects (DFGs and logs) to use with the mainstream process mining techniques. Hence, the holistic view of the MVP model is complemented by detailed viewpoint models using conventional notations like Petri nets, BPMN models and process trees. This possibility is not provided by the competing techniques described in Section 2: the focus is either on the specification of a case notion, or on the retrieval of an artifact-centric model. However, the relationships between the classes are not calculated and represented in the process model, in contrast to the technique of OCBC models. Moreover, the lack of a clear execution semantic of MVP models makes the application of conformance checking techniques possible only after choosing a viewpoint, in contrast with the OCBC technique that provides a (theoretically) powerful conformance checking approach on top of the model.

An MVP model has been discovered from a database event log extracted from a Microsoft Dynamics Customer Relationship Management (CRM) system, showing the possibility to apply the techniques described in this paper to real-life information systems.

Moreover, a comparison considering execution time and usability has been performed against two of the most recent process mining approaches on databases (OpenSLEX and OCBC models); MVP models are relatively well performing and easy to use, since an holistic view could be obtained without any effort from the user, and any viewpoint could be chosen on the MVP model.

Scalability testing proved that MVP models scale linearly with the number of events, classes and asymptotically linearly with the number of objects contained in the database event log, while they scale quadratically with the number of activities (due to the edges calculation in the A2A multigraph). This is a remarkable result in comparison to OCBC models that show an exponential complexity on the number of events (they become unmanageable also for a small number of events).

The techniques described in this paper could in principle be implemented starting from the logs of any relational database. Hence MVP discovery supports process mining analysis directly from real-life complex information systems.

  (a) Database model of a concert database. (b) MVP model annotated with frequencies.

Fig. 4 .

 4 Fig. 4. Visualization of part of the E2O graph of an example database event log (found in the erp.xoc test file). Events (red nodes) are connected to objects (white nodes).

Fig. 5 .

 5 Fig. 5. Visualization of part of the E2E multigraph of an example database event log (erp.xoc test file). Events are connected to events; in the edge label, the (object) perspective has been reported.

Fig. 6 .

 6 Fig. 6. Visualization of the A2A multigraph of an example database event log (erp.xoc test file). Activities are connected to activities; in the edge label, the (class) perspective along with the count of the occurrences has been reported.

Fig. 7 .

 7 Fig.7. Visualization of the MVP Model of an example database event log (erp.xoc test file). Activities are connected to activities; in the edge label, the (class) perspective along with the count of the occurrences has been reported. In addition to the A2A multigraph, start and end nodes are associated to each class; moreover, the edges that are reported in the A2A multigraph are filtered according to the dependency threshold (in this simple example, no arc is filtered).

Definition 11 (

 11 DFG) A Directly-Follows Graph is a weighted directed graph: DFG = (N DFG , E DFG , c DFG )

Fig. 8 .

 8 Fig. 8. Petri net extracted using Inductive Miner Directly-Follows from the projection of the MVP model extracted from the erp.xoc test file on the viewpoint containing the supplier order class.

  From a viewpoint V (L D ) on MVP(L D ), it is possible to obtain a Directly-Follows Graph as explained in the following definition: Definition 12 (DFG given a viewpoint) Given a viewpoint V (L D ) on MVP(L D ), a DFG could be obtained taking:-N DFG = (e1,e2,o)∈V E (L D ) {act(e 1 ), act(e 2 )} -E DFG = (e1,e2,o)∈V E (L D ) {(act(e 1 ), act(e 2 ))} c DFG (a 1 , a 2 ) = |{(e 1 , e 2 , o) ∈ V E (L D ) | act(e 1 ) = a 1 ∧ act(e 2 ) = a 2 }|where V E (L D ) is obtained as in Def.[START_REF] Chen | The entity-relationship model toward a unified view of data[END_REF].An example could be provided. Let V E (L D ) = {(e 1 ,e 2 , o 1 ), (e 2 , e 3 , o 1 ), (e 4 , e 5 , o 2 ), (e 5 , e 6 , o 2 )} be the set of edges associated to a viewpoint, such that: act(e 1 ) = act(e 4 ) = A act(e 2 ) = act(e 5 ) = B act(e 3 ) = C act(e 6 ) = D Then the DFG is such that N DFG = {A, B, C, D}, E DFG = {(A, B), (B, C), (B, D)}, c DFG (B, C) = c DFG (B, D) = 1, c DFG (A, B) = 2.

Definition 14 (

 14 Projection function) Let L D = (E, O, C, A, class, act, attr, EO, ≤) be an event log in a database context. Let C D ⊆ P(E) \ {∅} be a case notion. Then it is possible to define a projection function from a database event log to a classical event log as: proj(L D , C D ) = (C D , E, A, case ev, act, attr, ≤) where case ev ∈ C D → P(E) \ {∅} is such that for all c ∈ C D , case ev(c) = c.

  in storage required for storing MVP logs (the line with green dots) and XOC logs (the line with orange dots) for different data sets.

Fig. 11 .

 11 Fig. 11. Usability assessment: example model illustrating the main ingredients of OCBC models.

Fig. 12 .

 12 Fig. 12. Usability assessment: performance/bottleneck visualization provided by MVP models.

  of MVP discovery with the increase of the number of activities, when the number of classes, the number of objects per class and the number of events in the log is kept fixed: n events = 100000, n classes = 10 and n objects per class = 1000. The logs have been obtained through the generator included in PM4Py. The execution time (in seconds) grows quadratically with the number of activities. of MVP discovery with the increase of the number of objects per class, when the number of classes, the number of activities and the number of events in the log is kept fixed: n events = 100000, n classes = 10 and n activities = 40. The logs have been obtained through the generator included in PM4Py.

  of MVP discovery with the increase of the number of classes, when the number of objects per class, the number of activities and the number of events in the log is kept fixed: n events = 10000, n activities = 40 and n objects per class = 6000. The logs have been obtained through the generator included in PM4Py. The execution time (in seconds) grows linearly with the number of classes. of MVP discovery with the increase of the number of events in the log, when the number of classes, the number of objects per class and the number of activities in the log is kept fixed: n activities = 40, n classes = 10 and n objects per class = 6000. The logs have been obtained through the generator included in PM4Py.The execution time (in seconds) grows linearly with the number of events.

Fig. 13 .

 13 Fig. 13. Scalability assessment of MVP models, with regards to a) the number of activities b) the number of objects per class c) the number of classes d) the number of events in the log.

Fig. 14 .

 14 Fig. 14. Representation in one model of four perspectives (opportunities, opportunityproducts, campaigns, connections) of the Dynamics CRM database (only part of the diagram is reported).

Fig. 15 .

 15 Fig. 15. Petri net obtained by applying Inductive Miner Directly-Follows on the projection of the Dynamics CRM MVP model on a viewpoint containing only the 'opportunities' class. Black boxes represent invisible transitions (transitions that can be executed without correspondence with the activities of the log).

The repository can be accessed at the URL https://github.com/Javert899/pm4pysource

The example query is provided in the technical report available at the address http://www.alessandroberti.it/technical.pdf


Markku Hinkka
email: markku.hinkka@aalto.fi

Teemu Lehto
email: teemu.lehto@qpr.com

Keijo Heljanko
email: keijo.heljanko@helsinki.fi

Exploiting Event Log Event Attributes in RNN Based Prediction

Keywords: process mining, predictive process analytics, prediction, recurrent neural networks, gated recurrent unit

In predictive process analytics, current and historical process data in event logs is used to predict the future, e.g., to predict the next activity or how long a process will still require to complete. Recurrent neural networks (RNN) and its subclasses have been demonstrated to be well suited for creating prediction models. Thus far, event attributes have not been fully utilized in these models. The biggest challenge in exploiting them in prediction models is the potentially large amount of event attributes and attribute values. We present a novel clustering technique that allows for trade-offs between prediction accuracy and the time needed for model training and prediction. As an additional finding, we also find that this clustering method combined with having raw event attribute values in some cases provides even better prediction accuracy at the cost of additional time required for training and prediction.

Introduction

Event logs generated by systems in business processes are used in Process Mining to automatically build real-life process definitions and as-is models behind those event logs. There is a growing number of applications for predicting the properties of newly added event log cases, or process instances, based on case data imported earlier into the system [START_REF] Evermann | Predicting process behaviour using deep learning[END_REF][5] [START_REF] Navarin | LSTM networks for dataaware remaining time prediction of business process instances[END_REF] [START_REF] Tax | Predictive business process monitoring with LSTM neural networks[END_REF]. The more the users start to understand their processes, the more they want to optimize them. This optimization can be facilitated by performing predictions. To be able to predict properties of new and ongoing cases, as much information as possible should be collected that is related to the event log traces and relevant to the properties to be predicted. Based on this information, a model of the system creating the event logs can be created. In our approach, the model creation is performed using supervised machine learning techniques.

In our previous work [START_REF] Hinkka | Structural feature selection for event logs[END_REF] we have explored the possibility to use machine learning techniques for classification and root cause analysis for a process miningrelated classification task. In the paper, experiments were performed on the efficiency of several feature selection techniques and sets of structural features (a.k.a. activity patterns) based on process paths in process mining models in the context of a classification task. One of the biggest problems with the approach is the finding of the structural features having the most impact on the classification result. E.g., whether to use only activity occurrences, transitions between two activities, activity orders, or other even more complicated types of structural features such as detecting subprocesses or repeats. For this purpose, we have proposed another approach in [START_REF] Hinkka | Classifying process instances using recurrent neural networks[END_REF], where we have examined the use of recurrent neural network techniques for classification and prediction. These techniques are capable of automatically learning more complicated causal relationships between activity occurrences in activity sequences. We have evaluated several different approaches and parameters for the recurrent neural network techniques and have compared the results with the results we collected in our work. In both the previous publications [START_REF] Hinkka | Structural feature selection for event logs[END_REF][10], focusing on boolean -type classification tasks based on the activity sequences only.

In this work we build on our previous work to further improve the prediction accuracy of prediction models by exploiting additional event attributes that are often available in the event logs while also taking into account the scalability of the approach to allow users to precisely specify the event attribute detail level suitable for the prediction task ahead. Our goal is to develop a technique that would allow the creation of a tool that is, based on a relatively simple set of parameters and training data, able to efficiently produce a prediction model for any case-level prediction task, such as predicting the next activity or the final duration of a running case. Fast model rebuilding is also required in order for a tool to be able to also support, e.g., interactive event and case filtering capabilities. Thus, the performance of the system under study is measured using four different metrics: Success rate, input vector length that gives a rough indication of the memory usage, the time required for training a model and the time required for performing predictions using the already trained model.

To answer these requirements, we introduce a novel method of exploiting event attributes into RNN prediction models by clustering events by their event attribute values and using the cluster labels in the RNN input vectors instead of the raw event data. This makes it easy to manage the input RNN vector size no matter how many event attributes there are in the data set. E.g., users can configure the absolute maximum length of the one-hot vector used for the event attribute data which will not be exceeded, no matter how many actual attributes the dataset has. RNN is an ideal choice for process mining-related prediction tasks since it learns temporal dynamic behavior by using its internal state to process sequences of inputs. Since predictions are usually made based on sequences of events, this makes it a more natural machine learning technique in process mining context than more traditional approaches, such as random forest and gradient boosting.

Our prediction engine source code is available in GitHub5 . The rest of this paper is structured as follows: Section 2 is a summary of the latest developments around the subject. In Section 3, we present the problem statement and the related concepts. Section 4 presents our solution for the problem. In Section 5 we present our test framework used to test our solution. Section 6 describes the used datasets as well as performed prediction scenarios. Section 7 presents the experiments and their results validating our solution. Finally Section 8 draws the final conclusions.

Related Work

Lately, there has been a lot of interest in the academic world on predictive process monitoring which can clearly be seen, e.g., in [START_REF] Francescomarino | Predictive process monitoring methods: Which one suits me best?[END_REF] where the authors have collected a survey of 55 accepted academic papers on the subject. In [START_REF] Tax | An interdisciplinary comparison of sequence modeling methods for next-element prediction[END_REF], the authors have compared several approaches spanning three different research fields: Machine learning, process mining and grammar inference. As a result, they have found that overall, the techniques from machine learning field generate more accurate predictions than grammar inference and process mining fields.

In [START_REF] Tax | Predictive business process monitoring with LSTM neural networks[END_REF] the authors used Long Short-Term Memory (LSTM) recurrent neural networks to predict the next activity and its timestamp. They use one-hot encoded activity labels and three numerical time-based features: duration between the current activity and the previous activity, time within the day and time within the week. Event attributes were not considered at all. In [START_REF] Evermann | Predicting process behaviour using deep learning[END_REF] the authors trained LSTM networks to predict the next activity. In this case, however, network inputs are created by concatenating categorical, character string-valued event attributes and then encoding these attributes via an embedding space. They also note that this approach is feasible only because of the small number of unique values each attribute had in their test datasets. Similarly, in [START_REF] Schönig | Deep learning process prediction with discrete and continuous data features[END_REF], the authors take a very similar approach based on LSTM networks, but this time also incorporate both discrete and continuous event attribute values. Discrete values are one-hot encoded, whereas continuous values are normalized using min-max normalization and added to the input vectors as single values.

In [START_REF] Nolle | Binet: Multivariate business process anomaly detection using deep learning[END_REF] the authors use Gated Recurrent Unit (GRU) recurrent neural networks to detect anomalies in event logs. One one-hot encoded vector is created for activity labels and one for each of the included string-valued event attributes. These vectors are then concatenated in a similar fashion to our solution into one vector representing one event, which is then given as input to the network. We use this approach for benchmarking our own clustering-based approach (labeled as Raw feature in the text below). The system proposed in their paper is able to predict both the next activity and the next values of event attributes. Specifically, it does not take case attributes and temporal attributes into account.

In [START_REF] Verenich | Tell me what's ahead? predicting remaining activity sequences of business process instances[END_REF] the authors train a RNN to predict the most likely future activity sequence of a running process based only on the sequence of activity labels.

Similarly our earlier publication [START_REF] Hinkka | Structural feature selection for event logs[END_REF] used sequences of activity labels to train a LSTM network to perform a boolean classification of cases.

Also, process mining models obtained using process mining techniques themselves can be used as a model for prediction. In [START_REF] Bernard | Accurate and transparent path prediction using process mining[END_REF] the authors first generate a process tree using the inductive miner algorithm, after which this process tree is used to predict the future path of ongoing cases. This approach does not take any additional event-or case attributes into account.

None of the mentioned earlier works present a solution that is scalable for datasets having lots of event-or case attributes and unique attribute values.

Problem

Using RNN to perform case-level predictions on event logs has lately been studied a lot. However, there has not been any scalable approach to handling event attributes in the RNN setting. Instead, e.g., in [START_REF] Nolle | Binet: Multivariate business process anomaly detection using deep learning[END_REF] authors used separate onehot encoded vector for each attribute value. Having this kind of an approach when you have, e.g., 10 different attributes, each having 10 unique values would already require a vector of 100 elements to be added as input for every event. The longer the input vectors become, the more time and memory it gets for the model to create accurate models from them. This increases the time and memory required to use the model for predictions.

Solution

Since in addition to having activity labels in the input vectors, we need to store also event attribute-related information, we decided to include several feature types into the input vectors of the RNN. Input vectors are formatted as shown in Table 1, where each column represents one feature vector element f ab , where a is the index of the feature and b is the index of the element of that feature. In the table, n represents the number of feature types used in the feature vector and m k represents the number of elements required in the input vector for feature type k. Thus, each feature type produces one or more numeric elements into the input vector, which are then concatenated together into one actual input vector passed to RNN both in training and in prediction phases. Table 2 shows an example input vector having three different feature types: activity label, raw event attribute values (only single event attribute named food having four unique values) and the event attribute cluster where clustering has been performed separately for each unique activity.

For this paper, we encoded only event activity labels and event attributes into the input vectors. However, this mechanism can easily incorporate also other types of features not described here. The only requirement for added features is that it needs to be able to be encoded into a numeric vector as shown in Table 1 whose length must be the same for each event.

f oodpizza f oodwater f ood soda cluster1 cluster2 1 1 0 1 0 0 0 1 0 2 0 1 0 0 1 0 1 0 3 1 0 0 1 0 0 0 1 4 1 0 0 1 0 0 0 1 5 0 1 0 0 0 1 0 1

Event Attributes

Our primary solution for incorporating information in event attributes into input vectors is to cluster all the event attribute values in the training set and then use a one-hot encoded cluster identifier to represent all the attribute values of the element. The used clustering algorithm must be such that it tries to automatically find the optimal number of clusters for the given data set within the range of 0 to N clusters, where N can be configured by the user. By changing N, the user can easily configure the maximum length of the one-hot -vector as well as the precision of how detailed attribute information will be tracked. For this paper, we experimented with a slightly modified version of Xmeans -algorithm [START_REF] Pelleg | X-means: Extending k-means with efficient estimation of the number of clusters[END_REF]. Another option could have been a method where silhouette scoring [START_REF] Rousseeuw | Silhouettes: a graphical aid to the interpretation and validation of cluster analysis[END_REF] is used to determine the optimal number of clusters for k-means [START_REF] Hartigan | Algorithm AS 136: A k-means clustering algorithm[END_REF], but based on our tests, this approach did not perform fast enough to be applied as our selected approach.

It is very common that different activities get processed by different resources yielding a completely different set of possible attribute values. E.g., different departments in a hospital have different people, materials and processes. Also, in the example feature vector shown in Table 2, food -event attribute has completely different set of possible values depending on the activity since it is forbidden by, e.g., the external system to not allow activity of type eat to have food event attribute value of water. If we cluster all the event attributes using single clustering, we would easily lose this activity type-specific information.

In order to retain this activity-specific information, we used separate clustering for each unique activity type. All the event attribute clusters are encoded into one one-hot encoded vector representing only the resulting cluster label for that event, no matter what its activity is. This is shown in the example table as cluster N , which represents the row having N as a clustering label. E.g., in the example case, cluster 1 is 1 in both rows 1 and 2. However, row 1 is in that cluster because it is in the 1st cluster of the activity eat activity, whereas row 2 is in that cluster because it is in the 1st cluster of the activity drink activity. Thus, in order to identify the actual cluster, one would require both the activity label and the cluster label. For RNN to be able to properly learn about the actual event attribute values, it needs to be given both the activity label and the cluster label in the input vector. Below, this approach is labeled as ClustN, where N is the maximum cluster count.

For benchmarking, we also experimented with a raw implementation where event attributes were used so that every event attribute is encoded into its own one-hot encoded vector and then concatenated into the actual input vectors. This method is lossless since every unique event attribute value has its own indicator in the input vector. Below, this approach is referred to as Raw. Finally, we experimented also using both Raw and Clustered event attribute values. Below, this approach is referred to as BothN, where N is the maximum cluster count.

Formal problem definition

Basically, the problem we are solving in this paper is that we encode as much information as possible from event log event attributes into a single numeric RNN input vector whose length is user-configurable. In this section, we will present the formal definitions required to describe our clustering-based approach for solving this problem. We will build our formal definitions on the basis of the definitions given in Process Mining [START_REF] Van Der Aalst | Process Mining -Discovery, Conformance and Enhancement of Business Processes[END_REF] -book Chapter 5 describing the basic concepts in process mining.

First, we define relationships between event log and events as follows:

Definition 1. Event log L is a set of cases c i ∈ L.
Each case c i is a sequence of events c i = e 1 , e 2 , ..., e n . We denote e ∈ L iff ∃c i = e 1 , e 2 , ..., e n ∈ L, such that e j = e, for some 1 ≤ j ≤ n.

Next, we define a function for accessing event attributes of an event:

Definition 2. Let # n : e → v, where (n ∈ AN ) ∧ (e ∈ L), and AN is the finite set of all the attribute labels for the events in the given event log. v is the value of that attribute and can be of any arbitrary type.

Using this function, we can refer to any of the standard attributes (in this paper, only activity, time and caseid are considered as standard attributes), as well as event log-specific attributes. For this paper, we need to define these attribute label sets as follows: Definition 3. Let AN std ⊆ AN , be the set of standard attribute labels: activity, time, caseid . Also, let

(AN L ∩ AN std = ∅) ∧ (AN std ∪ AN L = AN ),
where AN L is the set of event attributes in event log L, which are not part of standard attributes.

The standard attributes listed above have the following meanings: Definition 4. # activity (e) is the activity label associated with the event e. This describes what has occurred. Activity labels in this paper are considered to be textual descriptions of the performed task. # time (e) is the timestamp of the event e. This describes when something has occurred. In this paper, timestamps include both time and date of the occurred event.

# caseid (e) is the identifier of the case associated with the event e. This describes the (case) context of the occurrence. Case identifiers in this paper are considered to be short textual or numeric identifiers identifying the case.

Using these, we can formally define a set of all the activity labels in the event log as follows: Definition 5. Let A L be the set of activity labels so that ∀e ∈ L, # activity (e) ∈ A L .

Next, we split the event log into two disjoint sets: Training set and test set. Formally this can be expressed as:

Definition 6. Training set is L tr ⊂ L, where L tr = ∅. Similarly, test set is L t ⊂ L, where (L t = ∅) ∧ (L t ∩ L tr = ∅) ∧ (L t ∪ L tr = L).
We also formally define separate subsets of activity labels for both the test and the training set as follows: Definition 7. A tr ⊆ A L is used to denote all the activity labels available in the training set, whereas A t ⊆ A L denotes those in the test set.

Similarly, we denote sets of available attributes in both the training set and the test set as follows: Definition 8. AN tr ⊆ AN L is used to denote all the attribute names available in the training set, whereas AN t ⊆ AN L denotes those in the test set.

Next, we define a function used to concatenate multiple vectors to each other. Definition 9. Let concat : X 0 , ..., X n → Y be a function that returns a single numeric vector Y consisting of the concatenated contents of numeric vectors X 0 , ..., X n in the specified order.

Then we define a function that maps each unique value into unique integer value as follows: Definition 10. Let codify : x×X → y, where X is a finite set of all the possible values for x ∈ X, and y ∈ 1, ..., |X| is the value x being mapped bijectively into an integer. Thus, codify creates a bijection between values and an integer representation of that value.

Now we can give a formal definition for the one-hot encoding function as follows:

Table 3: One-hot encoding example

Original After codify

After onehot a, b, c, d 1, 2, 3, 4 1, 0, 0, 0 , 0, 1, 0, 0 , 0, 0, 1, 0 , 0, 0, 0, 1 Definition 11. Let onehot : x × X → Y , where X is a finite set of all the possible values and x ∈ X is the value being encoded, be an onehot encoding function that transforms x into a numeric vector Y of length |X|. Vector Y = y 1 , ..., y |X| , where

y k = 1, iff k = codify(x, X) 0, otherwise
Thus, every unique value in X returns an unique numeric vector.

An example of a one-hot encoding process is shown in Table 3, where the set of all possible values X is a, b, c, d , and we are applying onehot function to each of the four possible values separately.

Next, since we need to be able to iterate through all the attributes, we need to specify an unambiguous way to map iteration index to an attribute name. For this purpose we define the following function: Using the previous definition, we can refer to nth event attribute of e by writing # attname(n) (e). Next, we define a method for creating subsets of events in a way that each subset will have all the events having one specific activity label. Formally we express these sets as: Definition 13. Let B act , where act ∈ A tr be the set of events e ∈ L such that # activity (e) = act.

Next, we will define a function for retrieving a set of all attribute values of a given set of events: Definition 14. Let # n : e 1 , ..., e n → Y , where e i ∈ L∀(1 ≤ i ≤ n). This function returns a set of all the attribute values of attribute having index n for given events.

Using these definitions, the set of all the attribute values of all the events having a specific activity label act can be referred to using # attname(n) (B act ), which yields a set of attribute values of attribute having index n for all the events having activity label act. Next, In order to perform clustering for events in activity buckets, we need to first one-hot encode event attribute values. Using this definition, we can transform all event attribute values into a single numeric vector using the following additional function definition. Definition 16. One-hot encoding function for all event attributes of given event: , where e ∈ L.

Next, we define the actual clustering function that uses the number vectors created by onehot # function as follows.

Definition 17. # cluster : e×max cc → y, where e ∈ L tr , and max cc denotes the configured maximum cluster count, and 1 ≤ y ≤ max cc , and y ∈ Z, denotes the assigned cluster label among the set of all the possible cluster labels. Clustering is performed separately for each activity label B act , where act ∈ A tr using suitable clustering algorithm. Every clustered event is translated into clustering input vector using onehot # (e) function. These input vectors are then used as data points for the clustering algorithm.

Thus, every activity will have its own independent clustering having max cc as the maximum cluster count. In the testing phase, the clusterings created from the training data will be used to fit the input vectors created from the events in the testing data.

Finally, we can specify the vector used as input vector in RNN training as follows:

Definition 18. Generating input vector for one event in training is performed using:

inputvector : e × max cc → concat(onehot(# activity (e), ACT tr ), onehot(# cluster (e, max cc ), cl))

, where e ∈ L tr , and cl = 1, ..., n , where n ≤ max cc represents the set of all the possible cluster labels. The value of n ∈ Z depends on the clustering algorithm and represents the actual maximum number of clusters that were created for event attribute data of any single activity in L tr .

These input vectors are then passed to the RNN training as ordered sequences of event input vectors, where each sequence represents all the events of a single case in the L tr in the order determined by their ascending timestamps.

As a result, when training, every event is preprocessed by performing the input vector generation using inputvector function. At the testing phase, the same encoding functions are used, however, if the event used in testing has some attributes, attribute values or activities that were not part of the training data set, those will just be ignored. Also, event attribute clustering in the testing phase is performed using the clustering models created in the training phase. Thus, in order to store the trained model, also all the trained clustering models must be stored.

Test Framework

We have performed our test runs using an extended Python-based prediction engine that was used in our earlier work [START_REF] Hinkka | Structural feature selection for event logs[END_REF]. The engine is still capable of supporting most of the hyperparameters that we experimented with in our earlier work, such as used RNN unit type, number of RNN layers and the used batch size. The prediction engine we built for this work takes a single JSON configuration file as input and outputs test result rows into a CSV file.

Tests were performed using a commonly used 3-fold cross-validation technique to measure the generalization characteristics of the trained models. In 3-fold cross-validation, the input data is split into three subsets of equal size. Each of the subsets is tested one by one against models trained using the other two subsets.

Training

Training begins by loading the event log data contained in the two of the three event log subsections. After this, the event log is split into actual training data and validation data that used to find the best performing model out of all the model states during all the test iterations. For this, we picked 75% of the cases for the training and the rest for the validation dataset. After this, we initialize event attribute clusters as described in Section 4.1.

The actual prediction model and the data used to generate the actual input vectors is performed next. This data initialization involves splitting cases into prefixes and also taking a random sample of the actual available data if the amount of data exceeds the configured maximum amount of prefixes. To avoid running out of memory during any of our tests, these limits were set to 75000 for training data and 25000 for validation data. We also had to filter out all the cases having more than 100 events.

Finally, after the model is initialized, we start the actual training in which we concatenate all the requested feature vectors as well as the expected outcome into the RNN model repeatedly for the whole training set until 100 test iterations have passed. The number of actual epochs trained in each iteration is configurable. In our experiments, the total number of epochs was set to be 10. After every test iteration, the model is validated against the validation set. To improve validation performance, if the size of the validation set is larger than a separately specified limit (10000), a random sample of the whole validation set is used. These test results, including additional status and timing-related information, are written into resulting test result CSV file. If the prediction accuracy of the model against the validation set is found to be better than the accuracy of any of the models found thus far, then the network state is stored for that model. Finally, after all the training, the model having the best validation test accuracy is picked as the actual result of the model training.

Testing

In the testing phase, the third subset of cross-validation folding is tested against the model built in the previous step. After initializing the event log following similar steps as in the training phase, the model is asked for a prediction for each input vector built from the test data. To prevent running out of memory and to ensure tests are not taking an exceedingly long time to run, we limited the number of final test traces to 100000 traces and used random sampling when needed. The prediction result accuracy, as well as other required statistics, are written to the resulting CSV file.

Test Setup

We performed our tests using several different data sets. Some details of the used data sets can be found in the Table 4. The table lists the number of cases, activities, events and event attributes for each event log. # Unique values column shows the sum of all the unique attribute values for each of the selected attributes.

The criteria for selecting or not selecting an event attribute in a model were based on the maximum usage of any unique value that the attribute has in the event log. If a value of an attribute was used in more than 4% of all the events in the event log, then that attribute was included in the test. Besides, we did not select any attributes that had just one unique attribute value. Names of all the selected event attributes are listed in the Table 5.

For each dataset, we performed the next activity prediction where we wanted to predict the next activity of any ongoing case. This was accomplished by splitting every input case into possibly multiple virtual cases depending on the number of events the case had. If the length of the case was shorter than 4, the whole case was ignored. If the length was equal or higher, then a separate virtual case was created for all prefixes at least of length 4. Thus, for a case of length 6, 3 cases were created: One with length 4, one with 5 and one with 6. For all 6 https://doi.org/10.4121/uuid:3926db30-f712-4394-aebc-75976070e91f 7 https://doi.org/10.4121/uuid:500573e6-accc-4b0c-9576-aa5468b10cee 8 https://doi.org/10.4121/uuid:c3e5d162-0cfd-4bb0-bd82-af5268819c35 9 https://doi.org/10.4121/uuid:5f3067df-f10b-45da-b98b-86ae4c7a310b 10 https://doi.org/10.4121/uuid:3301445f-95e8-4ff0-98a4-901f1f204972 these prefixes, the next activity label was used as the expected outcome. For the full-length case, the expected outcome was a special finished -token.

Experiments

For experiments, we have used the same system that we used already in our previous work [START_REF] Hinkka | Structural feature selection for event logs[END_REF]. The system had Windows 10 operating system and its hardware consisted of 3.5 GHz Intel Core i5-6600K CPU with 32 GB of main memory and NVIDIA GeForce GTX 960 GPU having 4 GB of memory. Out of those 4 GB, we reserved 3 GB for the tests. The testing framework was built on the test system using the Python programming language. The actual recurrent neural networks were built using Lasagne11 library that works on top of Theano 12 . Theano was configured to use GPU via CUDA for expression evaluation. We used one layer GRU [START_REF] Cho | On the properties of neural machine translation: Encoder-decoder approaches[END_REF] as the RNN type. Adam [START_REF] Kingma | A method for stochastic optimization[END_REF] was used as gradient descent optimizer with parameters of beta 1 = 0.9 and beta 2 = 0.999. 256 was used as the hidden dimension size as well as the mini-batch size and 0.01 as the learning rate. Even though it is quite probable that more accurate results could have been achieved by selecting, e.g., different hidden dimension sizes and learning rates depending on the size of the input vectors, we decided to use the fixed values. This decision was made in order to make the interpretation of the test results easier by minimizing the number of variables affecting the test results.

We performed next activity predictions using all the four combinations of features, five data sets and three different maximum cluster counts: 20, 40, and 80 clusters. The results of these runs are shown in Table 6. In the table, Features -column shows the used set of features. S.rate shows the achieved prediction success rate. In.v.s. shows the size of the input vector. This column can be used to give some kind of indication on the memory usage of using that configuration. Finally, Tra.t. and Pred.t. columns tell us the time required for performing the training and the prediction for all the cases in the test dataset. In both cases, this time includes the time for setting up the neural network, clusterings and preparing the dataset from JSON format. Sample standard deviation has been included in both S.rate and Tra.t in parentheses to indicate how spread out the measurements are within all the three test runs. Each row in the table represents three cross-validation runs with a unique combination of dataset and feature that was tested. Rows having the best prediction accuracy within a dataset are shown using bold font. None -feature represents the case in which there were no event attribute information at all in the input vector, ClustN represents a test with one-hot encoded cluster labels of event attributes clustered into maximum of N clusters, Raw represents having all one-hot encoded attribute values individually in the input vector, and finally, BothN represents having both one-hot encoded attribute values and one-hot encoded cluster labels in the input vector.

We also aggregated some of these results over all the datasets using the maximum cluster size of 80 clusters. Figure 1 shows the average success rates of different event attribute encoding techniques over all the tested datasets. Figure 2 shows the average input vector lengths. Figure 3 and Figure 4 shows the averaged training and prediction times respectively. Finally, Figure 5 shows the average success rates of different event attribute encoding techniques over all the tested datasets in the case where the maximum cluster count was set to be 80.

Next, we measured the statistical significance of the results. First, we measured whether we could reject the null hypothesis: "the best success rate results could have been achieved by using Raw features". By performing a one-tailed t -test, while assuming equal variances, for the results, we find out that this hypothesis can not be completely rejected in any of the test datasets. However, when assessing the null hypothesis: "we can achieve better success rates without taking event attributes into account at all than by taking them into account as clustered attribute values", we can reject it in all the datasets. Similarly, we can easily reject null hypothesis: "training a model using Raw features can be as fast as using the most accurate tested clustered features" in all the other cases, except in BPIC12, where the used input vectors were essentially identical due to the small number of unique attribute values in that model.

Based on all of the test results and statistical significance analysis, we can see that having event attribute values included improved the prediction accuracy over not having them included at all in all datasets. The effect ranged from 0.5% in BPIC12 model to 8.5% in BPIC18. As shown in Figure 1, very similar success rates were achieved using ClustN features as with Raw. However, model training and the actual prediction can be performed faster using ClustN approaches than either Raw or BothN. This effect is the most prominently visible in BPIC13 , where, due to the model having a large amount of unique attribute values, the size of the input vector is almost 68 times bigger and the training time almost 14 times longer using Raw feature than Clust20. At the same time, the accuracy is still better than not having event attributes at all (about 3.9% better) and only slightly worse (about 1.4%) than when using Raw feature. This indicates that clustering can be a really powerful technique for minimizing the time required for training especially when there are a lot of unique event attribute values in the used event log. Even when using the maximum cluster count of 20, prediction results will be either not affected or improved with a relatively small impact on the training and prediction time. Input vector size and memory usage are affected by clustered features in a similar fashion with the training and testing time: The more there are unique attribute values in the event log, the greater the difference between the input vector sizes needed in ClustN and Raw features. In all the datasets, the best prediction accuracy is always achieved either by using only clustering or by using both clustering and raw attributes at the same time.

Threats to validity

As threats to the validity of the results in this paper, it is clear that there are a lot of variables involved. As the initial set of parameter values, we used parameters that were found good enough in our earlier work and did some improvement attempts based on the results we got. It is most probable that the set of parameters we used were not optimal ones in each test run. We also did not test all the parameter combinations and the ones we did, we tested often only once, even though there was some randomness involved, e.g., selecting the initial cluster centers in the XMeans algorithm. However, we think that since we tested the results in several different datasets using a 3-fold cross-validation technique, our results can be used at least as a baseline for further studies. All the results generated by the test runs, as well as all the source data and the test framework itself, are available in support materials 13 . Also, we did not test with datasets having a huge number of event attribute values, the maximum amount tested being 2890. However, it can be seen that since the size of the input vectors is completely user-configurable when performing event attribute clustering, the user him/herself can easily set limits to the input vector length which should take the burden off from the RNN and move the burden to the clustering algorithms, which are usually more efficient in handling lots of features and feature values. When evaluating the results of the performed tests and comparing them with other similar works, it should be taken into account that data sampling was used in several phases of the testing process.

Conclusions

Clustering can be applied to attribute values to improve the accuracy of predictions performed on running cases. In four of the five experimented data sets, having event attribute clusters encoded into the input vectors outperforms having the actual attribute values in the input vector. Also, due to raw attribute values having direct effect to input vector lengths, the training and prediction time will be directly affected by the number of unique event attribute values. Clustering does not have this problem: The number of elements reserved in the input vector for clustered event attribute values can be adjusted freely. The memory usage is directly affected by the length of the input vector. In the tested cases, the number of clusters to use to get the best prediction accuracy seemed to depend very much on the used datasets, when the tested cluster sizes were 20, 40 and 80. In some cases, having more clusters improved the performance, whereas, in others, it did not have any significant impact, or even made the accuracy worse. We also found out that in some cases, having attribute cluster indicators in the input vectors improved the prediction even if the input vectors also included all the actual attribute values.

As future work, it would be interesting to test this clustering approach also with other machine learning model types such as more traditional random forest and gradient boosting machines. Similarly, it could be interesting to first filter out some of the most rarely occurring attribute values before clustering the values. This could potentially reduce the amount of noise added to the clustered data and make it easier for the clustering algorithm to not be affected by noisy data. Another idea that we leave for future study is whether it would be a good idea to first perform some kind of a feature selection algorithm such as influence analysis [START_REF] Lehto | Focusing business improvements using process mining based influence analysis[END_REF], recursive feature elimination [START_REF] Granitto | Recursive feature elimination with random forest for PTR-MS analysis of agroindustrial products[END_REF] or mRMR [START_REF] Ding | Minimum redundancy feature selection from microarray gene expression data[END_REF] to find the attribute values that correlate the most with the prediction results and have those attribute values added into the input vectors as raw one-hot encoded attribute values in addition to having the one-hot encoded cluster labels. More work is also required to understand exactly what properties of the event log affect the optimal number of clusters to use. Finally, more study is required to understand whether a similar clustering approach performed for event attributes in this work could be applicable also for encoding case attributes.

Definition 12 .

 12 Let attname : n → an, where an ∈ AN L , and n ∈ 1, ..., |AN L | be a bijective function for mapping an positive integer iteration index to an attribute name.

Definition 15 .

 15 Let onehot Bact : e × n → Y , where e ∈ L, act ∈ A tr , and n ∈ 1, ..., |AN L |, be a function that performs one-hot encoding for attribute having attribute iteration index of n for event e. Thus, Y = onehot(# attname(n) (e), # attname(n) (B #activity(e) )).

  onehot # : e → concat(onehot B # activity (e) (e, 1), ..., onehot B # activity (e) (e, |AN L |))

Fig. 1 :Fig. 2 :Fig. 3 :Fig. 5 :

 1235 Fig. 1: Average prediction success rate over all the datasets

Table 1 :

 1 Feature input vector structure f11 f12 ... f1m 1 f21 ... f2m 2 ... fn1 ... fnm n

Table 2 :

 2 Feature input vector example content row activityeat activity drink f ood salad

Table 4 :

 4 Used Event logs and their relevant statistics

	Event log	# Cases # Activities # Events # Attributes # Unique values
	BPIC12 6	13087	24	262200	1	3
	BPIC13, incidents 7 7554	13	65533	8	2890
	BPIC14 8	46616	39	466737	1	242
	BPIC17 9	31509	26	1202267	4	164
	BPIC18 10	43809	41	2514266	5	360

Table 5 :

 5 Included event attributes

	Event log	Attribute names
	BPIC12	lifecycle:transition
		impact
		lifecycle:transition
		org:group
	BPIC13, incidents	org:resource organization country
		organization involved
		product
		resource country
	BPIC14	Assignment Group
		Action
	BPIC17	EventOrigin lifecycle:transition
		org:resource
		activity
		doctype
	BPIC18	note
		org:resource
		subprocess

https://github.com/mhinkka/articles

https://lasagne.readthedocs.io/

https://github.com/mhinkka/articles

Acknowledgments

We want to thank QPR Software Plc for funding our research. Financial support of Academy of Finland project 313469 is acknowledged.