Specification-driven predictive business process monitoringducted in order to deal with various...

Software and Systems Modelinghttps://doi.org/10.1007/s10270-019-00761-w

SPEC IAL SECT ION PAPER

Specification-driven predictive business process monitoring

Ario Santoso1,2 ·Michael Felderer1,3

Received: 30 November 2018 / Accepted: 5 October 2019© The Author(s) 2019

AbstractPredictive analysis in business process monitoring aims at forecasting the future information of a running business process.The prediction is typically made based on the model extracted from historical process execution logs (event logs). In practice,different business domains might require different kinds of predictions. Hence, it is important to have a means for properlyspecifying the desired prediction tasks, and a mechanism to deal with these various prediction tasks. Although there have beenmany studies in this area, they mostly focus on a specific prediction task. This work introduces a language for specifying thedesired prediction tasks, and this language allows us to express various kinds of prediction tasks. This work also presents amechanism for automatically creating the corresponding prediction model based on the given specification. Differently fromprevious studies, instead of focusing on a particular prediction task, we present an approach to deal with various predictiontasks based on the given specification of the desired prediction tasks. We also provide an implementation of the approachwhich is used to conduct experiments using real-life event logs.

Keywords Predictive business process monitoring · Prediction task specification language · Automatic prediction modelcreation · Machine learning-based prediction

1 Introduction

Process mining [66,67] provides a collection of techniquesfor extracting process-related information from the logs ofbusiness process executions (event logs). One important areain this field is predictive business process monitoring, whichaims at forecasting the future information of a running pro-cess based on the models extracted from event logs. Through

Communicated by Dr. Rainer Schmidt and Jens Gulden.

This research has been supported by the Euregio Interregional ProjectNetwork IPN12 “Knowledge-Aware Operational Support” (KAOS),which is funded by the “European Region Tyrol-SouthTyrol-Trentino” (EGTC) under the first call for basic research projects.

B Ario [email protected]; [email protected]

Michael [email protected]

1 Department of Computer Science, University of Innsbruck,Innsbruck, Austria

2 Faculty of Computer Science, Free University ofBozen-Bolzano, Bozen-Bolzano, Italy

3 Department of Software Engineering, Blekinge Institute ofTechnology, Karlskrona, Sweden

predictive analysis, potential future problems can be detectedand preventive actions can be taken in order to avoid unex-pected situation, e.g., processing delay and service-levelagreement (SLA) violations. Many studies have been con-ducted in order to deal with various prediction tasks suchas predicting the remaining processing time [52–54,63,69],predicting the outcomes of a process [18,35,50,72], and pre-dicting future events [19,24,63] (cf. [11,15,41,42,49,58]). Anoverview of various works in the area of predictive businessprocess monitoring can be found in [20,36].

In practice, different business areas might need differentkinds of prediction tasks. For instance, an online retail com-pany might be interested in predicting the processing timeuntil an order can be delivered to the customer, while foran insurance company, predicting the outcome of an insur-ance claim process would be interesting. On the other hand,both of them might be interested in predicting whether theirprocesses comply with some business constraints (e.g., theprocessing time must be less than a certain amount of time).

When it comes to predicting the outcome of a process,business constraint satisfaction, and the existence of an unex-pected behaviour, it is important to specify the desired out-comes, the business constraint, and the unexpected behaviourprecisely. For instance, in the area of customer problemman-

123

http://crossmark.crossref.org/dialog/?doi=10.1007/s10270-019-00761-w&domain=pdf

http://orcid.org/0000-0001-6212-4365

A. Santoso, M. Felderer

agement, to increase the customer satisfaction as well as topromote efficiency, we might be interested in predicting thepossibility of “ping-pong behaviour” among the customerservice (CS) officers while handling the customer problems.However, the definition of a ping-pong behaviour could bevaried. For instance, when a CS officer transfers a customerproblem to another CS officer who belongs into the samegroup, it can already be considered as a ping-pong behavioursince both of them should be able to handle the sameproblem.Another possible definitionwould be to consider a ping-pongbehaviour as a situation when a CS officer transfers a prob-lem to another CS officer who has the same expertise, andthe problem is transferred back to the original CS officer.

To have a suitable prediction service for our domain, weneed to be able to specify the desired prediction tasks prop-erly. Thus,weneed ameans to express the specification.Oncewe have characterized the prediction objectives and are ableto express them properly, we need a mechanism to create thecorresponding prediction model. To automate the predictionmodel creation, the specification should be unambiguous andmachine processable. Such specification mechanism shouldalso allowus to specify constraints over the data, and comparedata values at different time points. For example, to charac-terize the ping-pong behaviour, one possibility is to specifythe behaviour as follows: “there is an event at a certain timepoint in which the CS officer (who handles the problem) isdifferent from the CS officer in the event at the next time point,but both of them belong to the same group”. Note that herewe need to compare the information about the CS officernames and groups at different time points. In other cases,we might even need to involve arithmetic expressions. Forinstance, consider a business constraint that requires that thelength of customer order processing time to be less than 3hours, where the length of the processing time is the timedifference between the timestamp of the first activity and thelast activity within the process. To express this constraint, weneed to be able to specify that “the time difference betweenthe timestamp of the first activity and the last activity withinthe process is less than 3 hours”.

The language should also enable us to specify the targetinformation to be predicted. For instance, in the prediction ofremaining processing time, we need to be able to define thatthe remaining processing time is the time difference betweentimestamp of the last activity and the current activity. Wemight also need to aggregate some data values, for instance,in the prediction of the total processing cost where the totalcost is the sum over the cost of all activities/events. In othercases, we might even need to specify an expression thatcounts the number of a certain activity. For example, in theprediction of the amount of work to be done (workload), wemight be interested in predicting the number of the remain-ing validation activities that are necessary to be done forprocessing a client application.

In this work, we tackle those problems by proposing anapproach for obtaining the desired prediction services basedon the specification of the desired prediction tasks. This workanswers the following questions:

RQ1: How can a specification-driven mechanism for build-ing predictionmodels for predictive process monitor-ing look like?

RQ2: How can an expressive specification language thatallows us to express various desired prediction tasks,and at the same time enables us to automaticallycreate the corresponding prediction model from thegiven specification, look like? Additionally, can thatlanguage allow us to specify complex expressionsinvolving data, arithmetic operations and aggregatefunctions?

RQ3: Once we are able to specify the desired predictiontasks properly, howcan amechanism to automaticallybuild the corresponding prediction model based onthe given specification look like?

To answer these questions, we aim at introducing a rich lan-guage for expressing the desired prediction tasks, as well asa mechanism to process the specification in order to build thecorresponding prediction model. Specifically, in this work,we provide the following contributions:

1. We introduce a rich language that allows us to specify var-ious desiredprediction tasks. In some sense, this languageallows us to specify how to create the desired predictionmodels based on the event logs.We also provide a formalsemantics for the language in order to ensure a uniformunderstanding and avoid ambiguity.

2. We devise a mechanism for building the correspondingprediction model based on the given specification. Thisincludes the mechanism for automatically processing thespecification. Once created, the prediction model can beused to provide predictive analysis services in businessprocess monitoring.

3. To provide a general idea on the capability of our lan-guage, we exhibit how our proposal can be used forspecifying various prediction tasks (cf.Sect. 5).

4. We provide an implementation of our approach whichenables the automatic creation of prediction modelsbased on the specified prediction objective.

5. To demonstrate the applicability of our approach, wecarry out experiments using real-life event logs that wereprovided for the Business Process Intelligence Challenge(BPIC) 2012, 2013, and 2015.

Figure 1 illustrates our approach for obtaining predictionservices. Essentially, it consists of the following main steps:(i) First, we specify the desired prediction tasks, (ii) sec-

123


Specify thePrediction Task

Automatically Createthe Prediction Model

Predict the FutureInformation

Fig. 1 Illustration of our approach for obtaining the prediction services

ond, we automatically create the prediction models basedon the given specification, (iii) once created, we can use theconstructed predictionmodels for predicting the future infor-mation of a running process.

Roughly speaking, we specify the desired prediction taskby specifying how we want to map each (partial) businessprocesses execution information into the expected predictedinformation. Based on this specification, we train either aclassification or regression model that will serve as the pre-dictionmodel. By specifying a set of desired prediction tasks,we could obtain multi-perspective prediction services thatenable us to focus on different aspects and predict vari-ous information of interest. Our approach is independentwith respect to the classification/regression model that isused. In our implementation, to get the expected quality ofpredictions, the users are allowed to choose the desired clas-sification/regression model as well as the feature encodingmechanisms (in order to allow some sort of feature engineer-ing).

This paper extends [57] in several ways. First, we extendthe specification language so as to incorporate various aggre-gate functions such as Max, Min, Average, Sum, Count, andConcat. Importantly, our aggregate functions allow us notonly to perform aggregation over some values but also tochoose the values to be aggregated. Obviously, this exten-sion increases the expressivity of the language and allows usto specify many more interesting prediction tasks. Next, weadd various new showcases that exhibit the capabilities of ourlanguage in specifying prediction tasks. We also extend theimplementation of our prototype in order to incorporate thoseextensions. To demonstrate the applicability of our approach,more experiments on different prediction tasks are also con-ducted and presented. Apart from using the real-life event logthat was provided for BPIC 2013 [62], we also use anotherreal-life event logs, namely the event logs that were providedfor BPIC 2012 [70] andBPIC 2015 [71]. Notably, our experi-ments also exhibit the usage of a deepLearning approach [30]in predictive process monitoring. In particular, we use deepfeed-forward neural network. Though there have been someworks that exhibit the usage of deep learning approach inpredictive processmonitoring (cf. [19,23,24,38,63]), hereweconsider the prediction tasks that are different from the tasksthat have been studied in those works. We also add morethorough explanation on several concepts and ideas of ourapproach so as to provide a better understanding. The discus-sion on the related work is also extended. Last but not least,several examples are added in order to support the expla-

nation of various technical concepts as well as to ease theunderstanding of the ideas.

The remainder of this paper is structured as follows: InSect. 2, we provide the required background on the conceptsthat are needed for the rest of the paper. Having laid thefoundation, in Sect. 3, we present the language that we intro-duce for specifying the desired prediction tasks. In Sect. 4,we present a mechanism for building the corresponding pre-diction model based on the given specification. In Sect. 5,we continue the explanation by providing numerous show-cases that exhibit the capability of our language in specifyingvarious prediction tasks. In Sect. 6, we present the implemen-tation of our approach aswell as the experiments that we haveconducted. Relatedwork is presented in Sect. 7. In Sect. 8,wepresent various discussions concerning this work, includinga discussion on some potential limitations, which pave theway towards our future direction. Finally, Sect. 9 concludesthis work.

2 Preliminaries

We will see later that we build the prediction models byusing machine learning classification/regression techniquesand based on the data in event logs. To provide some back-ground concepts, this section briefly explains the typicalstructure of event logs as well as the notion of classificationand regression in machine learning.

2.1 Trace, event, and event log

We follow the usual notion of event logs as in processmining [67]. Essentially, an event log captures historicalinformation of business process executions. Within an eventlog, an execution of a business process instance (a case) isrepresented as a trace. In the following, wemay use the termstrace and case interchangeably. Each trace has several events,and each event in a trace captures the information about aparticular event/activity that happens during the process exe-cution. Events are characterized by various attributes, e.g.,timestamp (the time when the event occurred).

We now proceed to formally define the notion of eventlogs as well as their components. Let E be the event uni-verse (i.e., the set of all event identifiers), andA be the set ofattribute names. For any event e ∈ E , and attribute namen ∈ A, #n(e) denotes the value of attribute n of e. Forexample, #timestamp(e) denotes the timestamp of the evente. If an event e does not have an attribute named n, then#n(e) = ⊥ (where ⊥ is undefined value). A finite sequenceover E of length n is a mapping σ : {1, . . . , n} → E , and werepresent such a sequence as a tuple of elements of E , i.e.,σ = 〈e1, e2, . . . , en〉 where ei = σ(i) for i ∈ {1, . . . , n}.

123


The set of all finite sequences over E is denoted by E∗. Thelength of a sequence σ is denoted by |σ |.

A trace τ is a finite sequence over E such that each evente ∈ E occurs at most once in τ , i.e., τ ∈ E∗ and for1 ≤ i < j ≤ |τ |,wehave τ(i) = τ( j),where τ(i) refers tothe event of the trace τ at the index i . Let τ = 〈e1, e2, . . . , en〉be a trace, τ k = 〈e1, e2, . . . , ek〉 denotes the k-length traceprefix of τ (for 1 ≤ k < n).

Example 1 For example, let {e1, e2, e3, e4, e5, e6, e7} ⊂ Ebe some event identifiers, then the sequence τ = 〈e3, e7, e6,e4, e5〉 ∈ E∗ is an example of a trace. In this case, we havethat |τ | = 5, and τ(3) refers to the event of the trace τ at theindex 3, i.e., τ(3) = e6. Moreover, τ 2 is the prefix of length2 of the trace τ , i.e., τ 2 = 〈e3, e7〉. �

Finally, an event log L is a set of traces such that eachevent occurs at most once in the entire log, i.e., for eachτ1, τ2 ∈ L such that τ1 = τ2, we have that τ1 ∩ τ2 = ∅,where τ1 ∩ τ2 = {e ∈ E | ∃i, j ∈ Z

+ . τ1(i) = τ2( j) = e}.An IEEE standard for representing event logs, called XES

(eXtensible Event Stream), has been introduced in [32]. Thestandard defines the XML format for organizing the struc-ture of traces, events, and attributes in event logs. It alsointroduces some extensions that define some attributes withpre-defined meaning such as:

1. concept:name, which stores the name of event/trace;2. org:resource, which stores the name/identifier of the

resource that triggered the event (e.g., a person name);3. org:group, which stores the group name of the resource

that triggered the event.

Event logs that obey this IEEE standard for event logs areoften called XES event logs.

2.2 Classification and regression

In machine learning, a classification and regression modelcan be seen as a function f : �X → Y that takes some inputfeatures/variables �x ∈ �X and predicts the corresponding tar-get value/output y ∈ Y . The key difference is that the outputrange of the classification task is a finite number of discretecategories (qualitative outputs), while the output range ofthe regression task is continuous values (quantitative out-puts) [28,31]. Both of them are supervised machine learningtechniques where the models are trained with labelled data.That is, the inputs for the training are pairs of input vari-ables �x and (expected) target value y. This way, the modelslearn how to map certain inputs �x into the expected targetvalue y.

3 Specifying the desired prediction tasks

This section elaborates our mechanism for specifying thedesired prediction tasks. In predictive business process mon-itoring, we are interested in predicting the future informationof a running process. Thus, the input of the prediction isinformation about the process that is currently running, e.g.,what is the sequence of activities that have been executedso far, who executes a certain activity, etc. This informationis often referred to as a (partial) business process executioninformation or a (partial) trace, which consists of a sequenceof events that have occurred during the process execution.On the other hand, the output of the prediction is the futureinformation of the process that is currently running, e.g., howlong is the remaining processing time, whether the processwill comply to a certain constraint, whether an unexpectedbehaviour will occur, etc. Based on these facts, here we intro-duce a language that can capture the desired prediction taskin terms of the specification for mapping each (partial) tracein the event log into the desired prediction results. In somesense, this specification language enables us to specify thedesired prediction function that maps each input (partial)trace into an output that gives the corresponding predictedinformation. Such specification can be used to train a classi-fication/regression model that will be used as the predictionmodel.

To express the specification of a prediction task, we intro-duce the notion of analytic rule. An analytic rule R is anexpression of the form:

R = 〈 Cond1 �⇒ Target1,Cond2 �⇒ Target2,

...

Condn �⇒ Targetn,DefaultTarget 〉,

where (i) Condi (for i ∈ {1, . . . , n}) is called conditionexpression; (ii) Targeti (for i ∈ {1, . . . , n}) is called targetexpression. (iii) DefaultTarget is a special target expres-sion called default target expression. (iv) The expressionCondi �⇒ Targeti is called conditional-target expression.

Section 3.1 provides an informal intuition on our lan-guage for specifying prediction tasks. It also gives someintuitive examples that illustrate the motivation of some ofour language requirements. In Sect. 3.2, we elaborate severalrequirements that guide the development of our specificationlanguage. Throughout Sects. 3.3 and 3.4, we introduce thelanguage for specifying the condition and target expressionsin analytic rules. Specifically, Sect. 3.4 introduces a languagecalled First-Order Event Expression (FOE), while Sect. 3.3elaborates several components that are needed to define suchlanguage. We will see later that FOE can be used to formally

123


specify condition expressions and a fragment of FOE can beused to specify target expressions. Finally, the formalizationof analytic rules is provided in Sect. 3.5.

3.1 Overview: prediction task specificationlanguage

An analytic rule R is interpreted as a mapping that mapseach (partial) trace into a value that is obtained by evaluatingthe target expression in which the corresponding conditionis satisfied by the corresponding trace. Let τ be a (partial)trace, such mapping R can be illustrated as follows:

R(τ ) =

⎧⎪⎪⎪⎪⎪⎨

⎪⎪⎪⎪⎪⎩

eval(Target1) if τ satisfies Cond1,eval(Target2) if τ satisfies Cond2,

......

eval(Targetn) if τ satisfies Condn ,eval(DefaultTarget) otherwise

where eval(DefaultTarget) and eval(Targeti ) consecu-tively denote the results of evaluating the target expressionDefaultTarget and Targeti , for i ∈ {1, . . . , n}. (The formaldefinition of this evaluation operation is given later.)

We will see later that a target expression specifies eitherthe desired prediction result or expresses the way to obtainthe desired prediction result from a trace. Thus, an analyticrule R can also be seen as a means to map (partial) traces intoeither the desired prediction results, or to obtain the expectedprediction results of (partial) traces.

To specify condition expressions in analytic rules, weintroduce a language called First-Order Event Expression(FOE). Roughly speaking, an FOE formula is a First-OrderLogic (FOL) formula [61] where the atoms are expressionsover some event attribute values and some comparison oper-ators, e.g., ==, =, >, ≤. The quantification in FOE isrestricted to the indices of events (so as to quantify the timepoints). The idea of condition expressions is to capture acertain property of (partial) traces. To give some intuition,before we formally define the language in Sect. 3.4, considerthe ping-pong behaviour that can be specified as follows:

Cond1 = ∃i .(i > curr ∧ i + 1 ≤ last ∧e[i]. org:resource = e[i + 1]. org:resource ∧e[i]. org:group == e[i + 1]. org:group)

where (i) e[i + 1]. org:group is an expression for gettingthe org:group attribute value of the event at index i + 1(similarly for e[i]. org:resource, e[i + 1]. org:resource, ande[i]. org:group), (ii) curr refers to the current time point, and(iii) last refers to the last time point.

The formula Cond1 basically says that there exists a timepoint i that is greater than the current time point (i.e., inthe future), in which the resource (the person in charge) is

different from the resource at the time point i + 1 (i.e., thenext time point), their groups are the same, and the nexttime point is still not later than the last time point. As forthe target expression, some simple examples would be somestrings such as “ping-pong” and “not ping-pong”. Based onthese, we can create an example of an analytic rule R1 asfollows:

R1 = 〈Cond1 �⇒ “ping-pong”, “not ping-pong”〉,

where Cond1 is as above. In this case, R1 specifies a taskfor predicting the ping-pong behaviour. In the predictionmodel creation phase,wewill create a classifier that classifies(partial) traces based on whether they satisfy Cond1 or not(i.e., a trace will be classified into “ping-pong” if it satisfiesCond1, otherwise it will be classified into “not ping-pong”).During the prediction phase, such classifier can be used topredict whether a given (partial) trace will lead to ping-pongbehaviour or not.

The target expression can be more complex than merelya string. For instance, it can be an expression that involvesarithmetic operations over numeric values such as1

TargetremainingTime =e[last]. time:timestamp − e[curr]. time:timestamp,

where e[last]. time:timestamp refers to the timestamp ofthe last event and e[curr]. time:timestamp refers to thetimestamp of the current event. Essentially, the expressionTargetremainingTime computes the time difference between thetimestamp of the last event and the current event (i.e., remain-ing processing time). Then, we can create an analytic rule:

R2 = 〈curr < last �⇒ TargetremainingTime, 0〉,

which specifies a task for predicting the remaining processingtime, because R2 maps each (partial) trace into its remainingprocessing time. In this case, during the prediction modelcreation phase, we will create a regression model for pre-dicting the remaining processing time of a given (partial)trace. Section 5 provides more examples of prediction tasksspecification using our language.

3.2 Specification language requirements

Driven by various typical prediction tasks that are studiedin the area of predictive process monitoring (see [20,36] foran extensive overview), in the following, we elaborate sev-eral requirements for our language as well as the motivation

1 Note that, as usual, a timestamp can be represented as millisecondssince Unix epoch (i.e., the number of milliseconds that have elapsedsince Jan 1, 1970 00:00:00 UTC).

123


for each requirement. These requirements guide the devel-opment of our language.

As can be seen from the illustrative examples in Sect. 3.1,the output of the prediction could be either numerical or non-numerical (categorical) values. This immediately gives thefirst requirement of our language as follows:

Req. 1: The language should support the specification ofprediction tasks in which the outputs could be eithernumerical or non-numerical values/information.

One of our goals is to have a mechanism for automaticallyprocessing the prediction task specification so as to build thecorresponding predictionmodel. Consequently, our languageshould fulfil the following requirement:

Req. 2: The language should allow us to automatically buildthe corresponding prediction model from the givenspecification.

When it comes to predicting the outcome of a process, theexistence of an unexpected behaviour, as well as the satisfac-tion of business constraints, we need to be able to preciselyspecify the desired outcomes, the corresponding unexpectedbehaviour, and the corresponding business constraint. Ascan be seen from the example in Sect. 3.1, these kinds oftasks often require us to express complex properties involv-ing events data (attribute values). Additionally, wemight alsoneed to be able to universally or existentially quantify dif-ferent event time points (e.g., saying that there exist a timepoint where a certain condition holds) and to compare differ-ent event attribute values at different time points (e.g., sayingthat the person in charge at time point i is different from theperson in charge at time point i + 1). As a consequence, thisgives us the following requirement:

Req. 3: The language should allow us to express com-plex constraints/properties over sequence of eventsby also involving the corresponding events data(attribute values). This includes the capability touniversally/existentially quantify different eventtime points and to compare different event attributevalues at different time points.

In Sect. 1, we have seen that we might even need to specifya business constraint that requires that the length of cus-tomer order processing to be less than 3 hours. Obviously,this requires us to specify an arithmetic expression involvingthe data. On the other hand, we might also need to specify aconstraint saying that the total cost of all validation activitiesshould be less than 100 Eur. In order to be able to specifythis constraint, we need to be able to aggregate (sum up) the

cost of each validation activity, and only to sum up those val-idation activities. Thus, we need to be able to aggregate someparticular attribute values. All of these give us the followingrequirement:

Req. 4: The language should allow us to specify arithmeticexpressions aswell as aggregate functions involvingthe data. Additionally, the language should allow usto do selective aggregation operations (i.e., selectingthe values to be aggregated).

In the example of predicting the remaining processing timein Sect. 3.1, we also need to be able to specify the targetinformation to be predicted. This often requires us to spec-ify the way to obtain a certain value. For instance, to obtainthe remaining processing time, we need to take the differencebetween the timestamp of the last event and the current event.Hence, we need to be able to specify that the remaining pro-cessing time is the difference between the timestamp of thelast event and the current event. This gives us the followingrequirement:

Req. 5: The language should allow us to specify the targetinformation to be predicted, and this might includethe way to obtain a certain value (which mightinvolve some arithmetic expressions).

3.3 Towards formalizing the condition and targetexpressions

This section is devoted to introduce several components thatare needed to define the language for specifying conditionand target expressions in Sect. 3.4.

As we have seen in Sect. 3.1, we often need to refer to aparticular index of an event within a trace. Recall the expres-sion e[i +1]. org:group that refers to the org:group attributevalue of the event at the index i +1, and also the expressione[last]. time:timestamp that refers to the timestamp of thelast event. The former requires us to refer to the event at theindex i + 1, while the latter requires us to refer to the lastevent in the trace. To capture this, we introduce the notion ofindex expression idx defined as follows:

idx :: = i | pint | last | curr | idx1+idx2 | idx1 − idx2

where (i) i is an index variable. (ii) pint is a positive integer(i.e., pint ∈ Z

+). (iii) last and curr are special indices inwhich the former refers to the index of the last event in atrace, and the latter refers to the index of the current event(i.e., last event of the trace prefix under consideration). Forinstance, given a k-length trace prefix τ k of the trace τ , curr isequal to k (or |τ k |), and last is equal to |τ |. (iv) idx+ idx and

123


idx − idx are the usual arithmetic addition and subtractionoperations over indices.

The semantics of index expression is defined over tracesand considered trace prefix length. Since an index expressioncan be a variable, given a trace τ and a considered trace pre-fix length k, we first introduce a variable valuation ν, i.e., amapping from index variables into Z

+. We assign meaningto index expression by associating with τ , k, and ν an inter-pretation function (·)τ,kν whichmaps an index expression intoZ

+. Formally, (·)τ,kν is inductively defined as follows:

(i)τ,kν = ν(i)(pint)τ,kν = pint ∈ Z

+(curr)τ,kν = k(last)τ,kν = |τ |

(idx1 + idx2)τ,kν = (idx1)τ,kν + (idx2)τ,kν

(idx1 − idx2)τ,kν = (idx1)τ,kν − (idx2)τ,kν

The definition above says that the interpretation function(·)τ,kν interprets index expressions as follows: (i) Each vari-able is interpreted based on how the variable valuation ν mapsthe corresponding variable into a positive integer in Z

+; (ii)each positive integer is interpreted as itself, e.g., (2603)τ,kν =2603; (iii) curr is interpreted into k; (iv) last is interpretedinto |τ |; and (v) the arithmetic addition/subtraction operatorsare interpreted as usual.

To access the value of an event attribute, we introduce so-called event attribute accessor, which is an expression of theform

e[idx]. attName

where attName is an attribute name and idx is an indexexpression. To define the semantics of event attribute acces-sor, we extend the definition of our interpretation function(·)τ,kν such that it interprets an event attribute accessor expres-sion into the attribute value of the corresponding event at thegiven index. Formally, (·)τ,kν is defined as follows:

(e[idx]. attName)τ,kν =

⎧⎪⎪⎪⎪⎨

⎪⎪⎪⎪⎩

#attName(e) if (idx)τ,kν = i,1 ≤ i ≤ |τ |,and e = τ(i)

⊥ otherwise

Note that the above definition also says that if the eventattribute accessor refers to an index that is beyond the validevent indices in the corresponding trace, then we will getundefined value (i.e., ⊥).

As an example of event attribute accessor, the expres-sion e[i]. org:resource refers to the value of the attributeorg:resource of the event at the position i .

Example 2 Consider the trace τ = 〈e1, e2, e3, e4, e5〉, let“Bob” be the value of the attribute org:resource of the evente3 in τ , i.e., #org:resource(e3) = “Bob”, and e3 does not haveany attributes named org:group, i.e., #org:group(e3) = ⊥. Inthis example, we have that (e[3]. org:resource)τ,kν = “Bob”,and (e[3]. org:group)τ,kν = ⊥. �

The value of an event attribute within a trace can be eithernumeric (e.g., 26, 3.86) or non-numeric (e.g., “sendOrder”),and we might want to specify properties that involve arith-metic operations over numeric values. Thus, we introduce thenotion of numeric expression and non-numeric expression asfollows:

nonNumExp ::= true | false | String |e[idx].NonNumericAttribute

numExp ::= number | idx |e[idx].NumericAttribute |numExp1 + numExp2 |numExp1 − numExp2

where (i) true and false are the usual boolean values, (ii)String is the usual string (i.e., a sequence of characters), (iii)number is a real number, (iv) e[idx].NonNumericAttributeis an event attribute accessor for accessing an attributewith non-numeric values, and e[idx].NumericAttribute isan event attribute accessor for accessing an attribute withnumeric values, (v) numExp1 + numExp2 and numExp1 −numExp2 are the usual arithmetic operations over numericexpressions.

To give the semantics for numeric expression and non-numeric expression, we extend the definition of our interpre-tation function (·)τ,kν by interpreting true, false, String, andnumber as themselves, e.g.,

(3)τ,kν = 3,

(“sendOrder”)τ,kν = “sendOrder”,

and by interpreting the arithmetic operations as usual, e.g.,

(26 + 3)τ,kν = (26)τ,kν + (3)τ,kν = 26 + 3 = 29,

(86 − 3)τ,kν = (86)τ,kν − (3)τ,kν = 86 − 3 = 83.

Formally, we extend our interpretation function as follows:

(true)τ,kν = true

(false)τ,kν = false

(String)τ,kν = String

(number)τ,kν = number

(numExp1 + numExp2)τ,kν = (numExp1)

τ,kν + (numExp2)

τ,kν

(numExp1 − numExp2)τ,kν = (numExp1)

τ,kν − (numExp2)

τ,kν

123


Note that the value of an event attribute might be undefined,i.e., it is equal to⊥. In this case, we define that the arithmeticoperations involving ⊥ give ⊥, e.g., 26 + ⊥ = ⊥.

We now define the notion of event expression as a com-parison between either numeric expressions or non-numericexpressions. Formally, it is defined as follows:

eventExp ::= true | false |numExp1 == numExp2 |numExp1 = numExp2 |numExp1 < numExp2 |numExp1 > numExp2 |numExp1 ≤ numExp2 |numExp1 ≥ numExp2 |nonNumExp1 == nonNumExp2 |nonNumExp1 = nonNumExp2

where (i) numExp is a numeric expression; (ii) nonNumExpis a non-numeric expression; (iii) the operators == and =are the usual logical comparison operators, namely equalityand inequality; (iv) the operators<,>,≤, and≥ are the usualarithmetic comparison operators, namely less than, greaterthan, less than or equal, and greater than or equal.

Example 3 The expression

e[i]. org:resource = e[i + 1]. org:resource

is an example of an event expression which says that theresource at the time point i is different from the resource atthe time point i + 1. As another example, the expression

e[i]. concept:name == “OrderCreated”

is an event expression saying that the value of the attributeconcept:name of the event at the index i is equal to“OrderCreated”. �

We interpret each logical/arithmetic comparison operator(i.e., ==, =, <, >, etc) in the event expressions as usual.For instance, the expression 26 ≥ 3 is interpreted as true,while the expression “receivedOrder” == “sendOrder” isinterpreted as false. Additionally, any comparison involvingundefined value (⊥) is interpreted as false. It is easy to seehow to extend the formal definition of our interpretation func-tion (·)τ,kν towards interpreting event expressions; therefore,we omit the details.

3.3.1 Adding aggregate functions

We now extend the notion of numeric expression andnon-numeric expression by adding several numeric and non-numeric aggregate functions. A numeric (resp. non-numeric)

aggregate function is a function that performs an aggrega-tion operation over some values and return a numeric (resp.non-numeric) value. Before providing the formal syntax andsemantics of our aggregate functions, in the following weillustrate the needs of having aggregate functions and weprovide some intuition on the shape of our aggregate func-tions.

Suppose that each event in each trace has an attributenamed cost. Consider the situation where we want to specifya task for predicting the total cost of all activities (from thefirst until the last event) within a trace. In this case, we needto sum up all values of the cost attribute in all events. Toexpress this need, we introduce the aggregate function sumand we can specify the notion of total cost as follows:

sum(e[x]. cost; where x = 1 : last).

The expression above computes the sum of the values ofe[x]. cost for all x ∈ {1, . . . , last}. In this case x is calledaggregation variable, the expression e[x]. cost specifies theaggregation source, i.e., the source of the values to beaggregated, and the expression x = 1 : last specifies theaggregation range by defining the range of the aggregationvariable x .

In some situation, we might only be interested to computethe total cost of a certain activity, e.g., the total cost of allvalidation activities within a trace. To do this, we introducethe notion of aggregation condition, which allows us to selectonly some values that wewant to aggregate. For example, theexpression

sum(e[x]. cost; where x = 1 : last;and e[x]. concept:name == “Validation”)

.

computes the sum of the values of the attribute e[x]. cost forall x ∈ {1, . . . , last} in which the expression

e[x]. concept:name == “Validation”

is evaluated to true. Therefore, the summation only considersthe values of x in which the activity name is “Validation”,and we only compute the total cost of all validation activities.As before, e[x]. cost specifies the source of the values to beaggregated, the expression x = 1 : last specifies the aggre-gation range by defining the range of the aggregation variablex , and the expression e[x]. concept:name == “Validation”provides the aggregation condition.

The expression for specifying the source of the values tobe aggregated can be more complex, for example when wewant to compute the average activity running time within atrace. In this case, the running time of an activity is specifiedas the time difference between the timestamp of that activityand the next activity, i.e.,

123


e[x + 1]. time:timestamp − e[x]. time:timestamp.

Then, the average activity running time can be specified asfollows:

avg(e[x + 1]. time:timestamp − e[x]. time:timestamp;where x = 1 : last)

.

Essentially, the expression above computes the average of thetime difference between the activity at the time point x + 1and x , where x ∈ {1, . . . , last}.

In other cases, we might not be interested in aggregatingthe data values, but we are interested in counting the num-ber of a certain activity/event. To do this, we introduce theaggregate function count. As an example, we can specify anexpression to count the number of validation activities withina trace as follows:

count(e[x]. concept:name == “validation”;where x = 1 : last)

where e[x]. concept:name == “validation” is an aggre-gation condition. The expression above counts how manytimes the specified aggregation condition is true within thespecified range. Thus, in this case, it counts the number ofthe events between the first and the last event, in which theactivity name is “validation”.

Wemight also be interested in counting the number of dif-ferent values of a certain attributewithin a trace. For example,we might be interested in counting the number of differ-ent resources that are involved within a trace. To capturethis, we introduce the aggregate function countVal. We canthen specify the expression to count the number of differentresources between the first and the last event as follows:

countVal(org:resource; within 1 : last)

where (i) org:resource is the name of the attribute in whichwe want to count its number of different values; and (ii) theexpression “within 1 : last” is the aggregation range.

We will see later in Sect. 5 that the presence of aggregatefunctions allows us to express numerous interesting pre-diction tasks. Towards formalizing the aggregate functions,we first formalize the notion of aggregation conditions. Anaggregation condition is an unquantified First-Order Logic(FOL) [61] formula where the atoms are event expressionsand may use only a single unquantified variable, namelythe aggregation variable. The values of the unquantified/freevariable in aggregation conditions are ranging over thespecified aggregation range in the corresponding aggregatefunction. Formally, aggregation conditions are defined as fol-lows:

aggCond ::= eventExp | ¬ψ | ψ1 ∧ ψ2 | ψ1 ∨ ψ2

where eventExp is an event expression, and the semanticsof aggCond is based on the usual FOL semantics. Formally,we extend the definition of our interpretation function (·)τ,kν

as follows:

(¬ψ)τ,kν = true, if (ψ)

τ,kν = false

(ψ1 ∧ ψ2)τ,kν = true, if (ψ1)

τ,kν = true, and (ψ2)

τ,kν = true

(ψ1 ∨ ψ2)τ,kν = true, if (ψ1)

τ,kν = true, or (ψ2)

τ,kν = true

With this machinery in hand, we are ready to define thesyntax and the semantics of numeric and non-numeric aggre-gate functions. We first extend the syntax of the numeric andnon-numeric expressions by adding the numeric and non-numeric aggregate functions as follows:

nonNumExp ::=true | false | String | e[idx].NonNumericAttribute |concat(nonNumSrc; where x = st : ed; and aggCond)

numExp ::= number | idx | e[idx].NumericAttribute |numExp1 + numExp2 | numExp1 − numExp2 |sum(numSrc; where x = st : ed; and aggCond) |avg(numSrc; where x = st : ed; and aggCond) |min(numSrc; where x = st : ed; and aggCond) |max(numSrc; where x = st : ed; and aggCond) |min(numExp1,numExp2) | max(numExp1, numExp2)|count(aggCond; where x = st : ed) |countVal(attName; within st : ed)

where (i) number, idx, e[idx].NumericAttribute,e[idx].NonNumericAttribute, numExp1 + numExp2, andnumExp1 − numExp2 are as before; (ii) st and ed are eitherpositive integers (i.e., st ∈ Z

+ and ed ∈ Z+) or special

indices (i.e., last or curr), and st ≤ ed; (iii) x is a vari-able called aggregation variable, and the range of its valueis between st and ed (i.e., st ≤ x ≤ ed). The expressionswhere x = st : ed and within st : ed are called aggregationvariable range; (iv) numSrc and nonNumSrc specify thesource of the values to be aggregated. The numSrc is speci-fied as numeric expression, while nonNumSrc is specified asnon-numeric expression. Both of themmay and can only usethe corresponding aggregation variable x , and they cannotcontain any aggregate functions; (v) aggCond is an aggre-gation condition over the corresponding aggregation variablex and no other variables are allowed to occur in aggCond;(vi) attName is an attribute name; (vii) for the aggregatefunctions, as the names describe, sum stands for summa-tion, avg stands for average,min stands for minimum,maxstands for maximum, count stands for counting, countValstands for counting values, and concat stands for concate-nation. The behaviour of these aggregate functions is quiteintuitive. Some intuition has been given previously, and weexplain their details behaviour while providing their formalsemantics below. The aggregate functions sum, avg, min,

123


max, concat that have aggregation conditions aggCond arealso called conditional aggregate functions.

Notice that a numeric aggregate function is also a numericexpression and a numeric expression is also a component ofa numeric aggregate function (either in the source value orin the aggregation condition). Hence, it may create somesort of nested aggregate function. However, to simplify thepresentation, in this workwe do not allow nested aggregationfunctions of this form, but technically it is possible to do thatunder a certain care on the usage of the variables (similarlyfor the non-numeric aggregate function).

To formalize the semantics of aggregate functions, we firstintroduce some notations. Given a variable valuation ν, wewrite ν[x �→ d] to denote a new variable valuation obtainedfrom the variable valuation ν as follows:

ν[x �→ d](y) ={d if y = xν(y) if y = x

Intuitively, ν[x �→ d] substitutes each variable x with d,while the other variables (apart from x) are substituted thesame way as ν is defined. Given a conditional summationaggregate function

sum(numSrc; where x = st : ed; and aggCond),

a trace τ , a considered trace prefix length k, and a vari-able valuation ν, we define its corresponding set Idx of validaggregation indices as follows:

Idx = {d ∈ Z+ | st ≤ d ≤ ed, (aggCond)

τ,kν[x �→ d] = true,

and (numSrc)τ,kν[x �→ d] = ⊥}.

basically, Idx collects the values within the given aggrega-tion range (i.e., between st and ed), in which, by substitutingthe aggregation variable x with those values, the aggrega-tion condition aggCond is evaluated to true and numSrc isnot evaluated to undefined value⊥. For the other conditionalaggregate functions avg, max, min, and concat, the cor-responding set of valid aggregation indices can be definedsimilarly.

Example 4 Consider the trace τ = 〈e1, e2, e3, e4〉, let“validation” be the value of the attribute concept:name ofthe event e2 and e4 in τ , i.e.,

#concept:name(e2) = #concept:name(e4) = “validation”.

Moreover, let #concept:name(e1) = “initialization” and#concept:name(e3) = “assembling”. Suppose that the costof each activity is the same, let say it is equal to 3, i.e.,

#cost(e1) = #cost(e2) = #cost(e3) = #cost(e4) = 3,

and we have the following aggregate function specification:

sum(e[x]. cost; where x = 1 : last; and true),

and

sum(e[x]. cost; where x = 1 : last;and e[x]. cost == “validation”)

The former computes the total cost of all activities, while thelatter computes the total cost of validation activities. In thiscase, the corresponding set of the valid aggregation indices(with respect to the given trace τ ) for the first aggregate func-tion is Idx1 = {1, 2, 3, 4}, while for the second aggregatefunction we have Idx2 = {2, 4} because the second aggre-gate function requires that the activity name (i.e., the valueof the attribute concept:name) to be equal to “validation” andit is only true when x is equal to either 2 or 4. �

Having this machinery in hand, we are now ready toformally define the semantics of aggregate functions. Theformal semantics of the conditional aggregate functions sum,avg, max, min is provided in Fig. 2. Intuitively, the aggre-gate function sum computes the sum of the values thatare obtained from the evaluation of the specified numericexpression numSrc over the specified aggregation range (i.e.,between st and ed). Additionally, the computation of thesummation ignores undefined values and it only considersthose indices within the specified aggregation range in whichthe aggregation condition is evaluated to true. The intuitionfor the aggregate functions avg,max,min is similar, exceptthat avg computes the average,max computes themaximumvalues, and min computes the minimum values.

Example 5 Continuing Example 4, the first aggregate func-tion is evaluated to 12 because we have that Idx1 ={1, 2, 3, 4}, and

∑

d∈Idx1(e[x]. cost)τ,kν[x �→ d] = (e[x]. cost)τ,kν[x �→ 1] +

(e[x]. cost)τ,kν[x �→ 2] +(e[x]. cost)τ,kν[x �→ 3] +(e[x]. cost)τ,kν[x �→ 4]

= 12.

On the other hand, the second aggregate function is evaluatedto 6 because we have that Idx2 = {2, 4}, and

∑

d∈Idx2(e[x]. cost)τ,kν[x �→ d] = (e[x]. cost)τ,kν[x �→ 2] +

(e[x]. cost)τ,kν[x �→ 4]= 6

�

123


Fig. 2 Formal semantics of aggregate functions sum, avg,max,min in the presence of aggregation conditions

The aggregate functionmax(numExp1,numExp2) com-putes the maximum value between the two values that areobtained by evaluating the specified two numeric expressionsnumExp1 and numExp2. It gives undefined value ⊥ if oneof them is evaluated to undefined value ⊥ (similarly for theaggregate function min(numExp1,numExp2) except that itcomputes the minimum value). The detailed formal seman-tics of these functions is provided in Appendix A.

The formal semantics of the aggregate function count isprovided below

(count(aggCond; where x = st : ed))τ,kν =

|{d ∈ Z+ | st ≤ d ≤ ed, and (aggCond)

τ,kν[x �→ d] = true}|

Intuitively, it counts how many times the aggCond is eval-uated to true within the given range, i.e., between st anded. This aggregate function is useful to count the number ofevents/activities within a certain range that satisfy a certaincondition, for example to count the number of the activitynamed “modifying delivery appointment” within a certainrange in a trace.

Notice that count is a syntactic variant of sum. It is easyto see that we could express

count(aggCond; where x = st : ed)

as

sum(1; where x = st : ed; and aggCond).

Both of the expressions above count how many times theaggCond is evaluated to true within the given range. How-ever, since expressing the counting aggregation using sum

is a bit less intuitive, we choose to explicitly introduce theaggregate function count.

The semantics of the aggregate function countVal is for-mally defined as follows:

(countVal(attName; within st : ed))τ,kν =|{v | (e[x]. attName)τ,kν[x �→ d] = v, and st ≤ d ≤ ed}|.

Intuitively, it counts the number of all possible values of theattribute attName within all events between the given startand end time points (i.e., between st and ed).

The aggregate function concat concatenates the valuesthat are obtained from the evaluation of the given non-numeric expression under the valid aggregation range (i.e.,we only consider the valuewithin the given aggregation rangein which the aggregation condition is satisfied). Moreover,the concatenation ignores undefined values and treats themas empty string. The detailed formal semantics of the aggre-gate function concat is provided in Appendix A.

Notice that, for convenience, we could easily extend ourlanguage with unconditional aggregate functions by addingthe following:

sum(numSrc; where x = st : ed)

avg(numSrc; where x = st : ed)

min(numSrc; where x = st : ed)

max(numSrc; where x = st : ed)

concat(nonNumSrc; where x = st : ed)

In this case, they simply perform an aggregation computationover the values that are obtained by evaluating the specifiednumeric/non-numeric expression over the specified aggrega-tion range. However, they do not give additional expressive

123


power since they are only syntactic variant of the currentconditional aggregate functions. This is the case becausewe can simply put “true” as the aggregation condition, e.g.,sum(numSrc; where x = st : ed; and true). Based ontheir semantics, we get the aggregate functions that behaveas unconditional aggregate functions. That is, they ignorethe aggregation condition since it will always be true forevery values within the specified aggregation range. In thefollowing, for the brevity of presentation, when aggregationcondition is not important we often simply use the uncondi-tional version of aggregate functions.

3.4 First-Order Event Expression (FOE)

Finally, we are ready to define the language for specifyingcondition expression, namely First-Order Event Expression(FOE). A part of this language is also used to specify targetexpression.

An FOE formula is a First-Order Logic (FOL) [61]formula where the atoms are event expressions and the quan-tification is ranging over event indices. Syntactically, FOE isdefined as follows:

ϕ ::= eventExp | ¬ϕ | ∀i .ϕ | ∃i .ϕ |ϕ1 ∧ ϕ2 | ϕ1 ∨ ϕ2 | ϕ1 → ϕ2

where (i) eventExp is an event expression; (ii)¬ϕ is negatedFOE formula; (iii) ∀i .ϕ is an FOE formula where the vari-able i is universally quantified; (iv) ∃i .ϕ is an FOE formulawhere the variable i is existentially quantified; (v) ϕ1∧ϕ2 is aconjunction of FOE formulas; (vi) ϕ1 ∨ϕ2 is a disjunction ofFOE formulas; (vii) ϕ1 → ϕ2 is an FOE implication formulasaying that ϕ1 implies ϕ2; (viii) The notion of free and boundvariables is as usual in FOL, except that the variables insideaggregate functions, i.e., aggregation variables, are not con-sidered as free variables; (ix) the aggregation variables cannotbe existentially/universally quantified.

The semantics of FOE constructs is based on the usualFOL semantics. Formally, we extend the definition of ourinterpretation function (·)τ,kν as follows2:

(¬ϕ)τ,kν = true, if (ϕ)τ,kν = false

(ϕ1 ∧ ϕ2)τ,kν = true, if (ϕ1)

τ,kν = true, and (ϕ2)

τ,kν = true

(ϕ1 ∨ ϕ2)τ,kν = true, if (ϕ1)

τ,kν = true, or (ϕ2)

τ,kν = true

(ϕ1 → ϕ2)τ,kν = true, if (ϕ1)

τ,kν = true, implies

(ϕ2)τ,kν = true

2 We assume that variables are standardized apart, i.e., no two quanti-fiers bind the same variable (e.g., ∀i .∃i .(i > 3)), and no variable occursboth free and bound (e.g., (i > 5) ∧ ∃i .(i > 3)). As usual in FOL,every FOE formula can be transformed into a semantically equivalentformula where the variables are standardized apart by applying somevariable renaming [61].

(∃i .ϕ)τ,kν = true, if for some c ∈ {1, . . . , |τ |}, we havethat (ϕ)

τ,kν[i �→ c] = true

(∀i .ϕ)τ,kν = true, if for every c ∈ {1, . . . , |τ |}, we havethat (ϕ)

τ,kν[i �→ c] = true

As before, ν[i �→ c] substitutes each variable i with c,while the other variables are substituted the same way asν is defined. When ϕ is a closed formula, its truth value doesnot depend on the valuation of the variables, and we denotethe interpretation of ϕ simply by (ϕ)τ,k . We also say that thetrace τ and the prefix length k satisfy ϕ, written τ, k |� ϕ,if (ϕ)τ,k = true. With a little abuse of notation, sometimeswe also say that the k-length trace prefix τ k of the trace τ

satisfies ϕ, written τ k |� ϕ, if τ, k |� ϕ.

Example 6 An example of a closed FOE formula is as fol-lows:

∀i .(e[i]. concept:name == “OrderCreated” →∃ j .( j > i ∧ e[i]. orderID == e[ j]. orderID ∧

e[ j]. concept:name == “OrderDelivered” ∧(e[ j]. time:timestamp − e[i]. time:timestamp) ≤10.800.000

)

)

which essentially says that whenever there is an event wherean order is created, eventually there will be an event wherethe corresponding order is delivered and the time differencebetween the two events (the processing time) is less than orequal to 10.800.000 milliseconds (3 hours). �

In general, FOE has the following main features: (i) Itallows us to specify constraints over the data (attribute val-ues); (ii) it allows us to (universally/existentially) quantifydifferent event time points and to compare different eventattribute values at different event time points; (iii) it allowsus to specify arithmetic expressions/operations involving thedata as well as aggregate functions; (iv) it allows us to doselective aggregation operations (i.e., selecting the valuesto be aggregated). (v) The fragments of FOE, namely thenumeric and non-numeric expressions, allow us to specifythe way to compute a certain value.

Notice that herewe opt for FOL-style syntax for providingthemechanism to refer to a certain event attribute at a particu-lar time point as well as to compare the event attribute valuesat two different time points. Another possible alternative forexpressing properties that involve time points would be toadopt the LTL-style syntax [51] by using the temporal oper-ators. For instance, we could roughly express the followingproperty:

∀i .(e[i]. org:resource = “Bob”)

123


which says that, at every time points, it is always be the casethat the value of the attribute ‘org:resource’ is not equal to’Bob’, as

G(org:resource = “Bob”)

where G is the usual LTL temporal operator that is typicallycalled ‘Global’. However, when we want to compare the val-ues of two attributes at two different time points, e.g.,

∃i .(e[i]. org:resource == e[i + 3]. org:resource)

we cannot easily do it using the usual LTL-style syntax, andthe expression might become less intuitive since we cannoteasily refer to a particular time point (by explicitly saying thecorresponding time points). Similarly, we also cannot easilyspecify an arithmetic expression that involves event attributesat two different time points, e.g.,

e[i + 1]. time:timestamp − e[i]. time:timestamp

Therefore, in order to have a more intuitive language, we optfor FOL-style syntax.

3.4.1 Checking whether a closed FOE formula is satisfied

We now proceed to introduce several properties of FOE for-mulas that are useful for checking whether a trace τ and aprefix length k satisfy a closed FOE formula ϕ, i.e., to checkwhether τ, k |� ϕ. This check is needed when we create thepredictionmodel based on the specification of prediction taskprovided by an analytic rule.

Let ϕ be an FOE formula, we write ϕ[i �→ c] to denotea new formula obtained by substituting each variable i in ϕ

by c. In the following, Theorems 1 and 2 show that whilechecking whether a trace τ and a prefix length k satisfy aclosed FOE formula ϕ, we can eliminate the presence ofexistential and universal quantifiers.

Theorem 1 Given a closed FOE formula ∃i .ϕ, a trace τ , anda prefix length k,

τ, k |� ∃i .ϕ iff τ, k |�∨

c∈{1,...|τ |} ϕ[i �→ c]

Proof By the definition of the semantics of FOE, we havethat τ and k satisfy ∃i .ϕ (i.e., τ, k |� ∃i .ϕ) iff thereexists an index c ∈ {1, . . . , |τ |}, such that τ and k sat-isfy the formula ψ that is obtained from ϕ by substitutingeach variable i in ϕ with c (i.e., τ, k |� ψ where ψ isϕ[i �→ c]) Thus, it is the same as satisfying the disjunctionsof formulas that is obtained by considering all possible sub-stitutions of the variable i in ϕ by all possible values of c(i.e.,

∨c∈{1,...|τ |} ϕ[i �→ c]). This is the case because such

disjunctions of formulas can be satisfied by τ and k if andonly if there exists at least one formula in that disjunctionsof formulas that is satisfied by τ and k. ��

Theorem 2 Given a closed FOE formula ∀i .ϕ, a trace τ , anda prefix length k,

τ, k |� ∀i .ϕ iff τ, k |�∧

c∈{1,...|τ |}ϕ[i �→ c]

Proof The proof is quite similar to Theorem 1, except thatwe use the conjunctions of formulas. Basically, we have thatτ and k satisfy ∀i .ϕ (i.e., τ, k |� ∀i .ϕ) iff for every c ∈{1, . . . , |τ |}, we have that τ, k |� ψ , where ψ is obtainedfrom ϕ by substituting each variable i in ϕ with c. In otherwords, τ and k satisfy each formula that is obtained from ϕ

by considering all possible substitutions of variable i with allpossible values of c. Hence, it is the same as satisfying theconjunctions of those formulas (i.e.,

∧c∈{1,...|τ |} ϕ[i �→ c]).

This is the case because such conjunctions of formulas canbe satisfied by τ and k if and only if each formula in thatconjunctions of formulas is satisfied by τ and k. ��

To check whether a trace τ and a prefix length k satisfy aclosed FOE formula ϕ, i.e., τ, k |� ϕ, we could perform thefollowing steps:

1. First, we eliminate all quantifiers. This can be done easilyby applying Theorems 1 and 2. As a result, each quanti-fied variable will be instantiated with a concrete value;

2. Evaluate all aggregate functions as well as all eventattribute accessor expressions basedon the event attributesin τ so as to get the actual values of the correspondingevent attributes. After this step, we have a formula that isconstituted by only concrete values composed by eitherarithmetic operators (i.e., + or −), logical comparisonoperators (i.e.,== or =), or arithmetic comparison oper-ators (i.e., <, >, ≤, ≥, == or =);

3. Last, we evaluate all arithmetic expressions as well asall expressions involving logical and arithmetic com-parison operators. If the whole evaluation gives us true(i.e., (ϕ)τ,k = true), then we have that τ, k |� ϕ, other-wise τ, k |� ϕ (i.e., τ and k do not satisfy ϕ).

The existence of this procedure gives us the following theo-rem:

Theorem 3 Given a closed FOE formula ϕ, a trace τ , and aprefix length k, checking whether τ, k |� ϕ is decidable.

This procedure has been implemented in our prototype asa part of the mechanism for processing the specification ofprediction task while constructing the prediction model.

123


3.5 Formalizing the analytic rule

With this machinery in hand, we can formally say how tospecify condition and target expressions in analytic rules,namely that condition expressions are specified as closedFOE formulas,while target expressions are specified as eithernumeric expression or non-numeric expression, except thattarget expressions are not allowed to have index variables.Thus, they do not need variable valuation. We require ananalytic rule to be coherent, i.e., all target expressions of ananalytic rule should be either only numeric or non-numericexpressions. An analytic rule in which all of its target expres-sions are numeric expressions is called numeric analytic rule,while an analytic rule in which all of its target expressionsare non-numeric expressions is called non-numeric analyticrule.

We can now formalize the semantics of analytic rules asillustrated in Sect. 3.1. Formally, given a trace τ , a consideredprefix length k, and an analytic rule R of the form

R = 〈 Cond1 �⇒ Target1,Cond2 �⇒ Target2,

...

Condn �⇒ Targetn,DefaultTarget 〉,

R maps τ and k into a value obtained from evaluating thecorresponding target expression as follows:

R(τ, k) =

⎧⎪⎪⎪⎪⎪⎨

⎪⎪⎪⎪⎪⎩

(Target1)τ,k if τ, k |� Cond1,

(Target2)τ,k if τ, k |� Cond2,

......

(Targetn)τ,k if τ, k |� Condn ,

(DefaultTarget)τ,k otherwise

where (Targeti )τ,k is the application of our interpretation

function (·)τ,k to the target expression Targeti in order toevaluate the expression and get the value. Checking whetherthe given trace τ and the given prefix length k satisfy Condi ,i.e., τ, k |� Condi , can be done as explained in Sect. 3.4.1.We also require an analytic rule to be well defined, i.e., givena trace τ , a prefix length k, and an analytic rule R, we say thatR is well defined for τ and k if R maps τ and k into exactlyone target value, i.e., for every condition expressions Condiand Cond j in which τ, k |� Condi and τ, k |� Cond j ,we have that (Targeti )

τ,k = (Target j )τ,k . This notion of

well-definedness can be easily generalized to event logs asfollows: Given an event log L and an analytic rule R, we saythat R is well defined for L if for every possible trace τ inL and every possible prefix length k, we have that R is welldefined for τ and k. Note that such condition can be easilychecked for the given event log L and an analytic rule R since

the event log is finite. This notion of well defined is requiredin order to guarantee that the given analytic rule R behavesas a function with respect to the given event log L , i.e., Rmaps every pair of trace τ and prefix length k into a uniquevalue.

Compared to enforcing that each condition in analyticrules must not be overlapped, our notion of well definedgives us more flexibility in making a specification using ourlanguage while also guaranteeing reasonable behaviour. Forinstance, one can specify several characteristics of ping-pongbehaviour in a more convenient way by specifying severalconditional-target expressions, i.e.,

Cond1 �⇒ “Ping-Pong”,Cond2 �⇒ “Ping-Pong”,

...

Condm �⇒ “Ping-Pong”

(where each condition expressionCondi captures a particularcharacteristic of a ping-pong behaviour), instead of usingdisjunctions of these several condition expressions, i.e.,

Cond1 ∨ Cond2 ∨ . . . ∨ Condm �⇒ “Ping-Pong”

which could end up into a very long specification of a con-dition expression.

4 Building the predictionmodel

Oncewe are able to specify the desired prediction tasks prop-erly, how can we build the corresponding prediction modelbased on the given specification? In this case, we need amechanism that fulfils the following requirement: For thegiven specification of the desired prediction task providedin our language, it should create the corresponding reliableprediction function, which maps each input partial trace intothe most probable predicted output.

Given an analytic rule R and an event log L , our aim isto create a prediction function that takes (partial) trace asthe input and predict the most probable output value for thegiven input. To this aim, we train a classification/regressionmodel inwhich the input is the features that are obtained fromthe encoding of all possible trace prefixes in the event log L(the training data). If R is a numeric analytic rule, we builda regression model. Otherwise, if R is a non-numeric ana-lytic rule, we build a classification model. There are severalways to encode (partial) traces into input features for train-ing a machine learning model. For instance, [33,60] studyvarious encoding techniques such as index-based encodingand boolean encoding. In [63], the authors use the so-calledone-hot encoding of event names, and also add some time-related features (e.g., the time increase with respect to the

123


previous event). Some works consider the feature encodingsthat incorporate the information of the last n-events. Thereare also several choices on the information to be incorporated.One can incorporate only the name of the events/activities,or one can also incorporate other information (provided bythe available event attributes) such as the (human) resourcewho is in charged in the activity.

In general, an encoding technique can be seen as a func-tion enc that takes a trace τ as the input and produces a set{x1, . . . , xm} of features, i.e., enc(τ ) = {x1, . . . , xm}. Fur-thermore, since a trace τ might have arbitrary length (i.e.,arbitrary number of events), the encoding function must beable to transform these arbitrary number of trace informationinto a fix number of features. This can be done, for exam-ple, by considering the last n-events of the given trace τ orby aggregating the information within the trace itself. In theencoding that incorporates the last n-events, if the numberof the events within the trace τ is less than n, then typicallywe can add 0 for all missing information in order to get a fixnumber of features.

In our approach, users are allowed to choose the desiredencoding mechanism by specifying a set Enc of preferredencoding functions (i.e., Enc = {enc1, . . . , encn}). Thisallows us to do some sort of feature engineering (note thatthe desired feature engineering approach, which might helpincreasing the prediction performance, can also be added asone of these encoding functions). The set of features of atrace is then obtained by combining all features producedby applying each of the selected encoding functions into thecorresponding trace. In the implementation (cf. Sect. 6), weprovide some encoding functions that can be selected in orderto encode a trace.

Algorithm 1 - Procedure for building the prediction modelInput: an analytic rule R,

an event log L , anda set Enc = {enc1, . . . , encn} of encoding functions

Output: a prediction function P1: for each trace τ ∈ L do2: for each k where 1 < k < |τ | do3: τ kencoded = enc1(τ k) ∪ . . . ∪ encn(τ k)4: targetValue = R(τ k)

5: add a new training instance for P , whereP(τ kencoded) = targetValue

6: end for7: end for8: Train the prediction function P (either classification or regression

model)

Algorithm 1 illustrates our procedure for building theprediction model based on the given inputs, namely: (i)an analytic rule R, (ii) an event log L , and (iii) a setEnc = {enc1, . . . , encn} of encoding functions. The algo-rithm works as follows: for each k-length trace prefix τ k of

each trace τ in the event log L (where 1 < k < |τ |), wedo the following: In line 3, we apply each encoding functionenci ∈ Enc into τ k , and combine all obtained features. Thisstep gives us the encoded trace prefix. In line 4, we com-pute the expected prediction result (target value) by applyingthe analytical rule R to τ k . In line 5, we add a new traininginstance by specifying that the prediction function P mapsthe encoded trace prefix τ kencoded into the target value com-puted in the previous step. Finally, we train the predictionfunction P and get the desired prediction function.

Observe that the procedure above is independent withrespect to the classification/regression model and traceencoding technique that are used. One can plug in differ-ent machine learning classification/regression technique aswell as use different trace encoding technique in order to getthe desired quality of prediction.

We elaborate why our approach fulfils the requirementthat is described in the beginning of this section as follows:In our approach,wemainly rely on supervisedmachine learn-ing technique in order to learn the desired prediction functionfrom the historical business process execution log (event log).Recall that a supervised machine learning approach learnsand approximates a function that maps each input to an out-put based on training data containing examples of input andoutput pairs. Additionally, recall that a prediction task spec-ification essentially specifies the way to map a partial trace(input) into the corresponding desired prediction result (out-put). As can be seen from our approach, by using the givenprediction task specification and the given event log, we cancreate a training data containing various examples of inputsand outputs. Therefore, each example of input and output inthis training data is generated based on the given predictiontask specification. Since the prediction function is built basedon this training data (which is created based on the predictiontask specification), the way the learned prediction functionmaps each input to output is influenced by the given spec-ification as well. Thus, the generated prediction function isbasically built based on the given specification of predictiontask. As for the reliability of the generated prediction func-tions, when we apply our whole approach in our experiments(cf. Sect. 6), the reliability of the created prediction functionsis measured by several metrics, e.g., accuracy, AUC, preci-sion, etc.

5 Showcases andmulti-perspectiveprediction service

An analytic rule R specifies a particular prediction task ofinterest. To specify several desired prediction tasks, we onlyhave to specify several analytic rules, i.e., R1, R2, . . . , Rn .Given a set R = {R1, R2, . . . , Rn} of analytic rules, ourapproach allows us to construct a prediction model for each

123


analytic rule Ri ∈ R. By having all of the constructed pre-diction models where each of them focuses on a particularprediction objective, we can obtain a multi-perspective pre-diction analysis service.

In Sect. 3, we have seen some examples of predictiontask specification for predicting the ping-pong behaviourand the remaining processing time. In this section, wepresent numerous other showcases of prediction task speci-fication using our language. More showcases can be foundin Appendix B.

5.1 Predicting unexpected behaviour/situation

We can specify the task for predicting unexpected behaviourby first expressing the characteristics of the unexpectedbehaviour.

Ping-pong Behaviour. The condition expression Cond1 (inSect. 3.1) expresses a possible characteristic of ping-pongbehaviour. Another possible characterization of ping-pongbehaviour is shown below:

Cond2 = ∃i . (i > curr ∧ i + 2 ≤ last ∧e[i]. org:resource = e[i + 1]. org:resource ∧e[i]. org:resource == e[i + 2]. org:resource ∧e[i]. org:group == e[i + 1]. org:group ∧e[i]. org:group == e[i + 2]. org:group)

In other word, Cond2 characterizes the condition where “anofficer transfers a task into another officer of the same group,and then the task is transferred back to the original officer”.In the event log, this situation is captured by the changes ofthe org:resource value in the next event, but then it changesback into the original value in the next two events, while thevalues of org:group remain the same.

We can then create an analytic rule to specify the task forpredicting ping-pong behaviour as follows:

R3 = 〈 Cond1 �⇒ “ping-pong”,Cond2 �⇒ “ping-pong”,

“not ping-pong”〉,

where Cond1 is the same as specified in Sect. 3.1. During theconstruction of the prediction model, in the training phase,R3 maps each trace prefix τ k that satisfies either Cond1 orCond2 into the target value “ping-pong”, and those prefixesthat neither satisfy Cond1 nor Cond2 into “not ping-pong”.After training the model based on this rule, we get a classifierthat is trained for distinguishing between (partial) traces thatmost likely and unlikely lead to ping-pong behaviour. Thisexample also exhibits the ability of our language to specifya behaviour that has multiple characteristics.

Abnormal Activity Duration. The following expressionspecifies the existence of abnormal waiting duration by stat-

ing that there exists a waiting activity in which the durationis more than 2 hours (7.200.000 milliseconds):

Cond3 = ∃i .(i < last) ∧e[i]. concept:name == “Waiting” ∧(e[i + 1]. time:timestamp −

e[i]. time:timestamp) > 7.200.000

As before, we can then specify an analytic rule for predictingwhether a (partial) trace is likely to have an abnormal waitingduration or not as follows:

R4 = 〈Cond3 �⇒ “Abnormal”, “Normal”〉.

Applying the approach for constructing the prediction modelin Sect. 4, we obtain a classifier that is trained to predictwhether a (partial) trace is most likely or unlikely to have anabnormal waiting duration.

5.2 Predicting SLA/business constraints compliance

Using FOE, we can easily specify numerous expressiveSLA conditions as well as business constraints. Furthermore,using the approach presented in Sect. 4, we can create the cor-responding prediction model, which predicts the complianceof the corresponding SLA/business constraints.

Time-relatedSLA. LetCond4 be the FOE formula inExam-ple 6. Roughly speaking, Cond4 expresses an SLA statingthat each order that is created will be eventually deliveredwithin 3 hours. We can then specify an analytic rule for pre-dicting the compliance of this SLA as follows:

R5 = 〈Cond4 �⇒ “Comply”, “Not Comply”〉.

Using R5, our procedure for constructing the predictionmodel in Sect. 4 generates a classifier that is trained to predictwhether a (partial) trace is likely or unlikely to comply withthe given SLA.

Separation of Duties (SoD). We could also specify a con-straint concerning Separation of Duties (SoD). For instance,we require that the person who assembles the product is dif-ferent from the person who checks the product (i.e., qualityassurance). This can be expressed as follows:

Cond5 = ∀i .∀ j .((i < last) ∧ ( j < last) ∧e[i]. concept:name == “assembling” ∧e[ j]. concept:name == “checking”) →

(e[i]. org:resource = e[ j]. org:resource).

Intuitively, Cond5 states that for every two activities, if theyare assembling and checking activities, then the resourceswho are in charge of those activitiesmust be different. Similar

123


to previous examples, we can specify an analytic rule forpredicting the compliance of this constraint as follows:


Applying our procedure for building the prediction model,we obtain a classifier that is trained to predict whether or nota trace is likely to fulfil this constraint.

Constraint on Activity Duration. Another example wouldbe a constraint on the activity duration, e.g., a requirementwhich states that eachactivitymust be finishedwithin 2 hours.This can be expressed as follows:

Cond6 = ∀i .(i < last) →(e[i + 1]. time:timestamp −

e[i]. time:timestamp) < 7.200.000.

Cond6 basically says that the time difference between twoactivities is always less than 2 hours (7.200.000 millisec-onds). An analytic rule to predict the compliance of this SLAcan be specified as follows:


Notice that we can express the same specification in a differ-ent way, for instance

R8 = 〈Cond7 �⇒ “Not Comply”, “Comply”〉

where

Cond7 = ∃i .(i < last) ∧(e[i + 1]. time:timestamp −

e[i]. time:timestamp) > 7.200.000.

Essentially, Cond7 expresses a specification on the existenceof abnormal activity duration. It states that there exists anactivity in which the time difference between that activityand the next activity is greater than 7.200.000 milliseconds(2 hours). Using either R7 or R8, our procedure for buildingthe prediction model (cf. Algorithm 1) gives us a classifierthat is trained to distinguish between the partial traces thatmost likely will and will not satisfy this activity durationconstraint.

We could even specify a more fine-grained constraint byfocusing into a particular activity. For instance, the follow-ing expression specifies that each validation activity must bedone within 2 hours (7.200.000 milliseconds):

Cond8 = ∀i .((i < last) ∧e[i]. concept:name == “Validation”) →

(e[i + 1]. time:timestamp −e[i]. time:timestamp) < 7.200.000.

Cond8 basically says that for each validation activity, thetime difference between that activity and its next activity isalways less than 2 hours (7.200.000 milliseconds). Similar tothe previous examples, it is easy to see that we could specifyan analytic rule for predicting the compliance of this SLAandcreate a prediction model that is trained to predict whether a(partial) trace is likely or unlikely fulfilling this SLA.

5.3 Predicting time-related information

In Sect. 3.1, we have seen how we can specify the task forpredicting the remaining processing time (by specifying a tar-get expression that computes the time difference between thetimestamp of the last and the current events). In the follow-ing, we provide another examples on predicting time-relatedinformation.

Predicting Delay. Delay can be defined as a condition whenthe actual processing time is longer than the expected pro-cessing time. Suppose we have the information about theexpected processing time, e.g., provided by an attribute“expectedDuration” of the first event, we can specify an ana-lytic rule for predicting the occurrence of delay as follows:

R9 = 〈Cond9 �⇒ “Delay”, “Normal”〉.

where Cond9 is specified as follows:

(e[last]. time:timestamp −e[1]. time:timestamp) > e[1]. expectedDuration.

Cond9 states that the difference between the last event times-tamp and the first event timestamp (i.e., the processing time)is greater than the expected duration (provided by the valueof the event attribute “expectedDuration”). While trainingthe classification model, R9 maps each trace prefix τ k intoeither “Delay” or “Normal” depending on whether the pro-cessing time of the whole trace τ is greater than the expectedprocessing time or not.

Predicting the Overhead of Running Time. The over-head of running time is the amount of time that exceedsthe expected running time. If the actual running time doesnot go beyond the expected running time, then the over-head is 0. Suppose that the expected running time is 3 hours(10.800.000 milliseconds), the task for predicting the over-head of running time can then be specified as follows:

R10 = 〈curr < last �⇒ max(Overhead, 0), 0〉.

where Overhead = TotalRunTime − 10.800.000, and

TotalRunTime =e[last]. time:timestamp − e[1]. time:timestamp.

123


In this case, R10 computes the difference between the actualtotal running time and the expected total running time.More-over, it outputs 0 if the actual total running time is less thanthe expected total running time, since it takes the maximumvalue between the computed time difference and 0. Applyingour procedure for creating the prediction model, we obtain aregression model that predicts the overhead of running time.

Predicting the Remaining Duration of a Certain Event.Let the duration of an event be the time difference betweenthe timestamp of that event and its succeeding event. The taskfor predicting the total duration of all remaining “waiting”events can be specified as follows:

R11 = 〈curr < last �⇒ RemWaitingDur, 0〉.

where RemWaitingDur is defined as the sum of the durationof all remaining waiting events, formally as follows:

sum(e[x + 1]. time:timestamp − e[x]. time:timestamp;where x = curr : last;and e[x]. concept:name == “waiting”)

As before, based on this rule, we can create a regressionmodel that predicts the total duration of all remainingwaitingevents.

Predicting Average Activity Duration.We can specify theway to compute the average of activity duration as follows:

AvgActDur =avg(e[x + 1]. time:timestamp − e[x]. time:timestamp;

where x = 1 : last)

where the activity duration is defined as the time differencebetween the timestamp of that activity and its next activity.We can then specify an analytic rule that expresses the taskfor predicting the average activity duration as follows:

R12 = 〈curr < last �⇒ AvgActDur, 0〉.

Similar to previous examples, applying our procedure forcreating the prediction model, we get a regression model thatcomputes the approximation of the average activity durationof a process.

5.4 Predicting workload-related information

Knowing the information about the amount of work to bedone (i.e., workload) would be beneficial. Predicting theactivity frequency is one of the ways to get an overview ofworkload. The following task specifies how to predict thenumber of the remaining activities that are necessary to beperformed:

R13 = 〈curr < last �⇒count(true; where x = curr : last), 0〉

In this case, R13 counts the number of remaining activities.We could also provide a more fine-grained specification byfocusing on a certain activity. For instance, in the followingwe specify the task for predicting the number of the remainingvalidation activities that need to be done:

R14 = 〈curr < last �⇒ NumOfRemValidation, 0〉.

where NumOfRemValidation is specified as follows:

count(e[x]. concept:name == “validation”;where x = curr : last)

NumOfRemValidation counts the occurrence of validationactivities between the current event and the last event (theoccurrence of validation activity is reflected by the factthat the value of the attribute concept:name is equal to“validation”). Applying our procedure for creating the pre-diction model over R13 and R14, consecutively we getregression models that predict the number of remainingactivities as well as the number of the remaining validationactivities.

We could also classify a process into complex or normalbased on the frequency of a certain activity. For instance, wecould consider a process that requiresmore than 25 validationactivities as complex (otherwise it is normal). The followinganalytic rule specifies this task:

R15 = 〈Cond10 > 25 �⇒ “complex”, “normal”〉


count(e[x]. concept:name == “validation”;where x = 1 : last)

Based on R15, we could train a model to classify whether a(partial) trace is likely to be a complex or a normal process.

5.5 Predicting resource-related information

Human resources could be a crucial factor in the processexecution. Knowing the number of different resources thatare needed for handling a process could be beneficial. Thefollowing analytic rule specifies the task for predicting thenumber of different resources that are required:

R16 = 〈curr < last �⇒countVal(org:resource; within 1 : last), 0〉.

During the training phase, since

123


countVal(org:resource; within 1 : last)is evaluated to the number of different values of the attributeorg:resource within the corresponding trace, R16 maps eachtrace prefix τ k into the number of different resources.

To predict the number of task handovers among resources,we can specify the following prediction task:

R17 = 〈curr < last �⇒ NumHandovers, 0〉.

where NumHandovers is defined as follows:

count(e[x]. org:resource = e[x + 1]. org:resource;where x = 1 : last)

,

i.e., NumHandovers counts the number of changes onthe value of the attribute org:resource and the changes ofresources reflect the task handovers among resources. Thus,in this case, R17 maps each trace prefix τ k into the numberof task handovers.

A process can be considered as labour intensive if itinvolves at least a certain number of different resources, e.g.,three different number of resources. This kind of task can bespecified as follows:

R18 = 〈Cond11 �⇒ “LaborIntensive”, “normal”〉

where Cond11 is as follows:

∃i .∃ j .∃k. (i = j ∧ i = k ∧ j = k ∧e[i]. org:resource = e[ j]. org:resource ∧e[i]. org:resource = e[k]. org:resource ∧e[ j]. org:resource = e[k]. org:resource)

Essentially,Cond11 states that there are at least three differentevents in which the values of the attribute org:resource inthose events are different.

5.6 Predicting value-added related information

Value-added analysis in BPM aims at identifying unneces-sary steps within a process with the purpose of eliminatingthose steps [22]. The steps within a process can be classifiedinto either value-added, business value-added, or non-valueadded. Value-added steps are the steps that produce/addvalues to the customer or to the final outcome/product ofthe process. Business value-added steps are those steps thatmight not directly add value to the customer but theymight benecessary or useful for the business. Non-value-added stepsare those that are neither value-added nor business value-added. Based on this analysis, typically we would like toretain those value-added steps, and eliminate (or reduce)those non-value-added steps. These non-value-added stepsare often also associated with wastes. An example of waste is

overprocessing waste. An overprocessingwaste occurs whenan activity is performed unnecessarily with respect to theoutcome of a process (i.e., it is performed in a way that doesnot add value to the final outcome/product of the process). Itincludes tasks that are performed but later found to be unnec-essary. In this light, the work by [73] proposes an approachfor minimizing the overprocessing waste by employing pre-diction techniques.

Using our language, we can characterize prediction tasksthat could assist in minimizing overprocessing waste. Forinstance, consider the process of handing personal loan appli-cations. Suppose that there are several checking activities thatneed to be performed on each application, and these checkscan be performed in any order (each check is independent ofeach other). Failure in any of these checks would make theapplication rejected and the process stops immediately. Onlycases that successfully pass all checks are accepted. Thiskind of process is often called a knockout process [65]. Forinstance, let these checking activities be (i) Applicant’s Iden-tity Check (IDC); (ii) Loan Worthiness Assessment (LWA);and (iii) Applicant’s Documents Verification (DV ). In thisscenario, if we first perform the Identity Check activity andthen the Documents Verification activity, but the DocumentVerification gives negative outcome (i.e., the application isrejected), then the efforts that we have spent on performingthe Identity Check activity would be a waste. Thus, it mightbe desirable to perform the Document Verification step firstso that we could reject the application immediately beforespending any efforts on any other activities.

In the situation above, it might be desirable to predict thechecking activity that most likely would lead to a negativeoutcome for a certain case of a loan application.Bydoing this,we can prioritize that activity and reduce the waste of effortsthat we spend on unnecessary activities. The analytic rulebelow specifies the prediction task that predicts the activitythat most likely would lead to the negative outcome (i.e., therejection of the application).

R32 = 〈 Cond16 �⇒ “Identity Check (IDC)”,Cond17 �⇒ “Loan Worthiness Assesment (LWA)”,Cond18 �⇒ “Document Verification (DV)”,

“None”〉,

where

Cond16 = ∃i .( i > curr ∧ e[i]. concept:name == “IDC” ∧e[i + 1]. concept:name == “Reject App.”),

Cond17 = ∃i .( i > curr ∧ e[i]. concept:name == “LWA” ∧e[i + 1]. concept:name == “Reject App.”),

Cond18 = ∃i .( i > curr ∧ e[i]. concept:name == “DV” ∧e[i + 1]. concept:name == “Reject App.”).

123


As observed by [65], another aspect that can be considered inprioritizing the activities in this kind of process is the effortthat needs to be spent on each activity. This effort couldbe either in terms of the processing time that is needed toperform the activity, the cost that needs to be spent, or theamount of resources that needs to be allocated. An activityis expensive if it requires a lot of efforts to perform (e.g., anactivity that requires a large amount of time). By knowingthis information, we could give a priority to the activity thatis less expensive, and leave those expensive activities to thelast so that they are only performed when they are reallynecessary. For each checking activity, we can specify thecorresponding prediction task that predicts the required effortfor performing that activity. For instance, we can specify thetask for predicting the duration of the identity checking (IDC)activity as follows:

R33 = 〈curr < last �⇒ DurationIDC, 0〉.

where DurationIDC is defined as follows:

sum(e[x + 1]. time:timestamp − e[x]. time:timestamp;where x = curr : last;and e[x]. concept:name == “IDC”)

Similarly, we can specify the tasks for predicting the dura-tion of the Loan Worthiness Assessment (LWA) activity andthe duration of the Document Verification (DV) activity asfollows:

R34 = 〈curr < last �⇒ DurationLWA, 0〉.

R35 = 〈curr < last �⇒ DurationDV, 0〉.

whereDurationLWA andDurationDV are defined as follows:

sum(e[x + 1]. time:timestamp − e[x]. time:timestamp;where x = curr : last;and e[x]. concept:name == “LWA”)

sum(e[x + 1]. time:timestamp − e[x]. time:timestamp;where x = curr : last;and e[x]. concept:name == “DV”)

As we have seen, all information from all of these simplepredictions could, in some sense, be combined/used in orderto help to minimize the unnecessary steps in a process, whichis one of the goals of value-added analysis.

6 Implementation and experiments

As a proof of concept, we develop a prototype that imple-ments our approach 3 This prototype includes a parser forour language and a program for automatically processing thegiven prediction task specification as well as for buildingthe corresponding prediction model based on our approachexplained in Sects. 3 and 4. We also build a ProM4 plug-in that wraps these functionalities. Several feature encodingfunctions to be selected are also provided, e.g., one-hotencoding of event attributes, time since the previous event,plain attribute values encoding, etc. We can also choose thedesired machine learning model to be built. Our implemen-tation uses Java and Python. For the interaction between JavaandPython,weuse Jep (JavaEmbeddedPython).5 In general,we use Java for implementing the program for processing thespecification andwe use Python for dealingwith themachinelearning models.

The main goal of our experiments is to demonstrate theapplicability of our whole approach in a real-world setting byapplying them into some case studies over real-life data, andto demonstrate the applicability of our approach in automat-ically constructing reliable prediction models based on thegiven specification. This includes the demonstration of thecapability of our language in specifying relevant interestingprediction tasks based on the case study over real-life data.Basically, our experiments answer the following questions:

1. Is the whole proposed approach applicable in practice (ina real-life setting)?

2. In practice, can we generate reliable prediction modelsby following our approach (starting from specifying thedesired prediction task)?

3. What are the factors that influence the quality of the gen-erated prediction models?

The experimentswere conductedbyapplyingour approachinto several case studies/problems that are based on real-life event logs. Particularly, we use the publicly availableevent logs that were provided for Business Process Intelli-gence Challenge (BPIC) 2012, BPIC 2013, and BPIC 2015.For each event log, several relevant prediction tasks areformulated based on the corresponding domain of the cor-responding event log, and also by considering the availableinformation. For instance, predicting the occurrence of ping-pong behaviour among support groups might be suitable forthe BPIC 13 event log, but not for BPIC 12 event log since

3 More information about the implementation architecture, the code,the tool, and the screencast can be found at http://bit.ly/sdprom2.4 ProM is a widely used extendable framework for process mining(http://www.promtools.org).5 Jep—https://pypi.org/project/jep/.

123

http://bit.ly/sdprom2

http://www.promtools.org

https://pypi.org/project/jep/


there is no information about groups in BPIC 12 event log(in fact, they are event logs from two different domains). Foreach prediction task, we provide the corresponding formalspecification that can be fed into our tool in order to createthe corresponding prediction model.

For the experiment, we follow the standard holdoutmethod [31]. Specifically, we partition the data into two setsas follows: We use the first two-thirds of the log for the train-ing data and the last one-third of the log for the testing data.For each prediction task specification, we apply our approachin order to generate the corresponding prediction model, andthen we evaluate the prediction quality of the generated pre-diction model by considering each k-length trace prefix τ k

of each trace τ in the testing set (for 1 < k < |τ |). In orderto provide a baseline, we use a statistical-based predictiontechnique, which is often called Zero Rule (ZeroR). Specif-ically, for the classification task, the prediction by ZeroR isperformed based on the most common target value in thetraining set, while for the regression task, the prediction isbased on the mean value of the target values in the trainingdata. Although ZeroR seems to be quite naive, dependingon the data, in some cases it can outperform some advancedmachine learning models. The datasets and our source codeare available online so as to enable the replication of theexperiments 3.

Recall that our approach for building the predictionmodelpresented in Sect. 4 is independent with respect to the super-vised machine learning model that is used. Within theseexperiments, we consider several machine learning models,namely (i) Logistic Regression, (ii) Linear Regression, (iii)Naive Bayes Classifier, (iv) Decision Tree [10], (v) RandomForest [9], (vi)AdaBoost [27] with Decision Tree as the baseestimator, (vii)Extra Trees [29], (viii)VotingClassifier that iscomposed of Decision Tree, Random Forest, AdaBoost, andExtra Trees. Among these, logistic regression, naive Bayes,and voting classifier are only used for classification tasks,and linear regression is only used for regression tasks. Therest are used for both. Notably, we also use a deep learningapproach [30]. In particular, we use the deep feed-forwardneural network and we consider various sizes of the networkby taking into account several different depth and width ofthe network. We consider different numbers of hidden lay-ers ranging from 2 to 6 and three variants of the number ofneurons, namely 75, 100, and 150. For compactness of thepresentation, we do not show the evaluation results on all ofthese network variations but we only show the best result.The detail results are available at http://bit.ly/sdprom2 as asupplementary material. In the implementation, we use themachine learning libraries provided by scikit-learn [46]. Forthe implementation of neural network, we use Keras6 withTheano [64] backend.

6 https://keras.io.

To assess the prediction quality, we use the standard met-rics for evaluating classification and regression models thatare generally used in the machine learning literature. Thesemetrics are also widely used in many works in this researcharea (e.g., [33,35,37,63,69,72]). For the classification task,we use accuracy, area under the ROC curve (AUC), pre-cision, recall, and F-measure. For the regression task, weuse mean absolute error (MAE) and root mean square error(RMSE). In the following, we briefly explain these metrics.A more elaborate explanation on these metrics can be foundin the typical literature on machine learning and data mining,e.g., [28,31,43].

Accuracy is the fraction of predictions that are correct. Itis computed by dividing the number of correct predictions bythe number of all predictions. The range of accuracy value isbetween 0 and 1. The value 1 indicates the bestmodel,while 0indicates the worst model. AnROC (receiver operating char-acteristic) curve allows us to visualize the prediction qualityof a classifier. If the classifier is good, the curve should be ascloser to the top left corner as possible. A random guessingis depicted as a straight diagonal line. Thus, the closer thecurve to the straight diagonal line, the worse the classifier.The value of the area under the ROC curve (AUC) allowsus to assess a classifier as follows: The AUC value equal to1 shows a perfect classifier, while the AUC value equal to0.5 shows the worst classifier that is not better than randomguessing. Thus, the closer the value to 1, the better it is, andthe closer the value to 0.5, the worse it is. Precisionmeasuresthe exactness of the prediction. When a classifier predicts acertain output for a certain case, the precision value intu-itively indicates how much is the chance that such predictionis correct. Specifically, among all cases that are classifiedinto a particular class, precision measures the fraction ofthose cases that are correctly classified. On the other hand,recall measures the completeness of the prediction. Specifi-cally, among all cases that should be classified as a particularclass, recall measures the fraction of those cases that can beclassified correctly. Intuitively, given a particular class, therecall value indicates the ability of the model to correctlyclassify all cases that should be classified into that particularclass. The best precision and recall value is 1. F-Measure isharmonic mean of precision and recall. It provides a mea-surement that combines both precision and recall values byalso giving equal weight to them. Formally, it is computedas follows: F-Measure = (2 × P × R)/(P + R), where Pis precision and R is recall. The best F-measure value is 1.Thus, the closer the value to 1, the better it is.

MAE computes the average of the absolute error ofall predictions over the whole testing data, where eacherror is computed as the difference between the expectedand the predicted values. Formally, given n testing data,MAE = (∑n

i=1 |yi − yi |)/n, where yi (resp. yi ) is

the predicted value (resp. the expected/actual value) for

123


https://keras.io


the testing instance i . RMSE can be computed as follows:

RMSE =√(∑n

i=1(yi − yi )2)/n, where yi (resp. yi ) is the

predicted value (resp. the expected/actual value) for the test-ing instance i . Compared to MAE, RMSE is more sensitiveto errors since it gives larger penalty to larger errors by usingthe ‘square’ operation. For both MAE and RMSE, the lowerthe score, the better the model.

In our experiments, we use the trace encoding that incor-porates the information of the last n-events, where n is themaximal length of the traces in the event log under considera-tion. Furthermore, for each experimentwe consider two typesof encoding, where each of them considers different avail-able event attributes (one encoding incorporates more eventattributes than the others). The detail of event attributes thatare considered is explained in each experiment below.

6.1 Experiment on BPIC 2013 event log

The event log from BPIC 20137 [62] contains the data fromthe Volvo IT incident management system called VINST.It stores information concerning the incidents handling pro-cess. For each incident, a solution should be found as quicklyas possible so as to bring back the service with minimuminterruption to the business. It contains 7554 traces (processinstances) and 65533 events. There are also several attributesin each event containing various information such as theproblem status, the support team (group) that is involved inhandling the problem, the person who works on the problem,etc.

In BPIC 2013, ping-pong behaviour is one of the interest-ing problems to be analyzed. Ideally, an incident should besolved quickly without involving too many support teams.To specify the tasks for predicting whether a process wouldprobably exhibit a ping-pong behaviour, we first identify andexpress the possible characteristics of ping-pong behaviouras follows:

CondE1 = ∃i .(i > curr ∧ i < last ∧e[i]. org:group = e[i + 1]. org:group ∧e[i]. concept:name = “Queued”)

CondE2 = ∃i .(e[i]. org:resource = e[i + 1]. org:resource ∧e[i]. org:resource == e[i + 2]. org:resource)

CondE3 = ∃i .(e[i]. org:resource = e[i + 1]. org:resource ∧e[i]. org:resource == e[i + 3]. org:resource)

CondE4 = ∃i .(e[i]. org:group = e[i + 1]. org:group ∧e[i]. org:group == e[i + 2]. org:group)

7 More information on BPIC 2013 can be found in http://www.win.tue.nl/bpi/doku.php?id=2013:challenge.

CondE5 = ∃i .(e[i]. org:group = e[i + 1]. org:group ∧e[i]. org:group == e[i + 3]. org:group)

CondE6 = ∃i .∃ j .∃k.(i < j ∧ j < k ∧e[i]. org:group = e[ j]. org:group ∧e[i]. org:group = e[k]. org:group ∧e[ j]. org:group = e[k]. org:group)

Roughly speaking, CondE1 says that there is a change inthe support team while the problem is not being “Queued”.CondE2 and CondE3 state that there is a change in the personwho handles the problem, but then at some point it changesback into the original person. CondE4 and CondE5 say thatthere is a change in the support team (group) who handlesthe problem, but then at some point it changes back intothe original support team. CondE6 states that the process ofhandling the incident involves at least three different groups.

We then specify three different analytic rules below inorder to specify three different tasks for predicting ping-pongbehaviour based on various characteristics of this unexpectedbehaviour.

RE1 = 〈CondE1 �⇒ “Ping-Pong”, “Not Ping-Pong”〉

RE2 = 〈 CondE2 �⇒ “Ping-Pong”,CondE3 �⇒ “Ping-Pong”,CondE4 �⇒ “Ping-Pong”,CondE5 �⇒ “Ping-Pong”,

“Not Ping-Pong” 〉,RE3 = 〈CondE6 �⇒ “Ping-Pong”, “Not Ping-Pong”〉

In this case, RE1 specifies the task for predicting ping-pongbehaviour based on the characteristic provided by CondE1(similarly for RE2 and RE3). These analytic rules can be fedinto our tool in order to obtain the prediction model, and forthese cases we create classification models.

In BPIC 2013 event log, an incident can have several sta-tuses. One of them is waiting. In this experiment, we predictthe remaining duration of all waiting-related events by spec-ifying the following analytic rule:

RE4 = 〈curr < last �⇒ RemWaitingTime, 0〉

where RemWaitingTime is as follows:

sum(e[x + 1]. time:timestamp − e[x]. time:timestamp;where x = curr : last;and e[x]. lifecycle:transition == “Await.Assign.” ∨

e[x]. lifecycle:transition == “Wait” ∨e[x]. lifecycle:transition == “Wait - Impl.” ∨e[x]. lifecycle:transition == “Wait - User” ∨e[x]. lifecycle:transition == “Wait - Cust.” ∨e[x]. lifecycle:transition == “Wait - Vendor”)

123

http://www.win.tue.nl/bpi/doku.php?id=2013:challenge



i.e., RemWaitingTime is the sum of all event durationin which the status is related to waiting (e.g., AwaitingAssignment, Wait, Wait-User, etc). Similarly, we predict theremaining duration of all (exactly) waiting events by speci-fying the following:

RE5 = 〈curr < last �⇒ RemWaitDur, 0〉

where RemWaitDur is as follows:

sum(e[x + 1]. time:timestamp − e[x]. time:timestamp;where x = curr : last;and e[x]. lifecycle:transition == “Wait”)

i.e., RemWaitDur is the sum of all event duration in whichthe status is “wait”. Both RE4 and RE5 can be fed into ourtool, and in this case we generate regression models.

For all of these tasks, we consider two different traceencodings. First, we use the trace encoding that incorporatesseveral available event attributes, namely concept:name,org:resource, org:group, lifecycle:transition, organizationinvolved, impact, product, resource country, organizationcountry, org:role. Second,we use the trace encoding that onlyincorporates the event names, i.e., the values of the attributeconcept:name. Intuitively, the first encoding considers moreinformation than the second encoding. Thus, the predictionmodels that are obtained by using the first encoding use moreinput information for doing the prediction. The evaluationon the generated prediction models from all prediction tasksspecified above is reported in Tables 1 and 2.


The event log forBPIC20128 [70] comes from aDutch finan-cial institute. It stores the information concerning the processof handling either personal loan or overdraft application.It contains 13.087 traces (process instances) and 262.200events. Generally, the process of handling an application isas follows: Once an application is submitted, some checksare performed. After that, the application is augmented withnecessary additional information that is obtained by contact-ing the client by phone. An offer will be send to the client, ifthe applicant is eligible. After this offer is received back, itis assessed. The customer will be contacted again if there isa missing information. After that, a final assessment is per-formed. In this experiment, we consider two prediction taskas follows:

1. One type of activity within this process is namedW_Completeren aanvraag, which stands for “Filling in


information for the application”. The task for predictingthe total duration of all remaining activities of this typeis formulated as follows:

RE6 = 〈curr < last �⇒ RemTimeFillingInfo, 0〉

where RemTimeFillingInfo is as follows:

sum(e[x + 1]. time:timestamp−e[x]. time:timestamp;where x = curr : last;and e[x]. concept:name ==

“W_Completeren aanvraag”),

i.e., it computes the sum of the duration of all remainingW_Completeren aanvraag activities.

2. At the end of the process, an application can be declined.The task to predict whether an applicationwill eventuallybe declined is specified as follows:

RE7 = 〈CondE8 �⇒ “Declined, “Not_Declined〉

where CondE8 is as follows:

CondE8 = ∃i .(i > curr ∧e[i]. concept:name == “A_DECLINED”),

i.e., CondE8 says that eventually there will be an event inwhich the application is declined.

Both RE6 and RE7 can be fed into our tool. For RE6, wegenerate a regression model, while for RE7, we generate aclassificationmodel.Different from theBPIC2013 andBPIC2015 event logs, there are not so many event attributes in thislog. For all of these tasks, we consider two different traceencodings. First, we use the trace encoding that incorporatesseveral available event attributes, namely concept:name andlifecycle:transition. Second, we use the trace encoding thatonly incorporates the event names, i.e., the values of theattribute concept:name. Thus, intuitively the first encodingconsiders more information than the second encoding. Theevaluation on the generated prediction models from the pre-diction tasks specified above is shown in Tables 3 and 4.


In BPIC 20159 [71], 5 event logs from 5 Dutch Municipal-ities are provided. They contain the data of the processesfor handling the building permit application. In general,the processes in these 5 municipalities are similar. Thus,in this experiment we only consider one of these logs.


123






Table 1 The results from the experiments on BPIC 2013 event log using prediction tasks RE1, RE2, and RE3

Model First encoding (more features) Second encoding (less features)

AUC Accuracy W. Prec W. Rec F-Measure AUC Accuracy W. Prec W. Rec F-Measure

Experiments with the analytic rule RE1 (change of group while the concept:name is not ‘queued’)

RE1

ZeroR 0.50 0.82 0.68 0.82 0.75 0.50 0.82 0.68 0.82 0.75

Logistic Reg. 0.64 0.81 0.75 0.81 0.76 0.55 0.82 0.68 0.82 0.75

Naive Bayes 0.51 0.21 0.80 0.21 0.12 0.54 0.19 0.79 0.19 0.09

Decision Tree 0.67 0.78 0.80 0.78 0.79 0.68 0.82 0.76 0.82 0.77

Random Forest 0.83 0.84 0.83 0.84 0.83 0.68 0.82 0.76 0.82 0.77

AdaBoost 0.73 0.81 0.77 0.81 0.78 0.66 0.82 0.75 0.82 0.75

Extra Trees 0.81 0.83 0.81 0.83 0.82 0.68 0.82 0.76 0.82 0.77

Voting 0.81 0.81 0.81 0.81 0.81 0.68 0.82 0.76 0.82 0.77

Deep Neural Net. 0.73 0.83 0.81 0.83 0.81 0.68 0.83 0.78 0.83 0.75

Experiments with the analytic rule RE2 (change of people/group and change back to the original person/group)

RE2

ZeroR 0.50 0.79 0.63 0.79 0.70 0.50 0.79 0.63 0.79 0.70

Logistic Reg. 0.77 0.82 0.80 0.82 0.80 0.62 0.81 0.78 0.81 0.76

Naive Bayes 0.69 0.79 0.75 0.79 0.75 0.63 0.80 0.77 0.80 0.76

Decision Tree 0.73 0.82 0.82 0.82 0.82 0.76 0.82 0.80 0.82 0.80

Random Forest 0.85 0.86 0.85 0.86 0.85 0.78 0.82 0.80 0.82 0.80

AdaBoost 0.81 0.84 0.83 0.84 0.83 0.68 0.81 0.79 0.81 0.77

Extra Trees 0.85 0.86 0.85 0.86 0.86 0.78 0.82 0.80 0.82 0.80

Voting 0.85 0.86 0.85 0.86 0.85 0.77 0.82 0.81 0.82 0.81

Deep Neural Net. 0.77 0.86 0.86 0.86 0.85 0.78 0.83 0.82 0.83 0.80

Experiments with the analytic rule RE3 (involves at least three different groups)

RE3

ZeroR 0.50 0.74 0.54 0.74 0.63 0.50 0.74 0.54 0.74 0.63

Logistic Reg. 0.78 0.78 0.76 0.78 0.76 0.77 0.79 0.77 0.79 0.77

Naive Bayes 0.75 0.76 0.73 0.76 0.70 0.76 0.77 0.75 0.77 0.73

Decision Tree 0.79 0.82 0.83 0.82 0.83 0.81 0.82 0.82 0.82 0.82

Random Forest 0.92 0.87 0.87 0.87 0.87 0.83 0.82 0.82 0.82 0.82

AdaBoost 0.89 0.86 0.86 0.86 0.86 0.83 0.81 0.80 0.81 0.80

Extra Trees 0.91 0.87 0.87 0.87 0.87 0.82 0.82 0.82 0.82 0.82

Voting 0.91 0.85 0.85 0.85 0.85 0.82 0.82 0.81 0.82 0.82

Deep Neural Net. 0.85 0.85 0.84 0.85 0.84 0.83 0.83 0.82 0.83 0.82

The bold values indicate the best values that we obtained with respect to the corresponding metric. The best value is not always the highest value.For example, when the metric measures the error (e.g., MAE or RMSE), the smallest value is the best value. However, for the metrics such asaccuracy, AUC, precision, recall, and F-measure, the highest value is the best value

There are several information available such as the activ-ity name and the resource/person that carried out a certaintask/activity. The statistic about the log that we consider isas follows: It has 1409 traces (process instances) and 59681events.

For this event log, we consider several tasks related topredicting workload-related information (i.e., related to theamount of work/activities need to be done). First, we dealwith the task for predicting whether a process of handlingan application is complex or not based on the number of the

remaining different activities that need to be done. Specif-ically, we consider a process is complex (or need moreattention) if there are still more than 25 different activitiesneed to be done. This task can be specified as follows:

RE8 = 〈NumDifRemAct ≥ 25 �⇒ “Complex”, “Normal”〉

where NumDifRemAct is specified as follows:

countVal(activityNameEN; within curr : last),

123


Table 2 The results of theexperiments on BPIC 2013event log using prediction tasksRE4 and RE5

Model First Encoding (more features) Second Encoding (less features)

MAE (in days) RMSE (in days) MAE (in days) RMSE (in days)

Experiments with the analytic rule RE4 (the remaining duration of all waiting-related events)

RE4

ZeroR 5.977 6.173 5.977 6.173

Linear Reg. 5.946 6.901 6.16 6.462

Decision Tree 5.431 17.147 5.8 7.227

Random Forest 4.808 8.624 5.81 7.114

AdaBoost 14.011 18.349 14.181 15.164

Extra Trees 4.756 8.612 5.799 7.132

Deep Neural Net. 2.205 4.702 4.064 4.596

Experiments with the analytic rule RE5 (the remaining duration of all events in which the status is “wait”)

RE5

ZeroR 1.061 1.164 1.061 1.164

Linear Reg. 1.436 1.974 1.099 1.233

Decision Tree 0.685 5.165 1.003 1.66

Random Forest 0.713 3.396 1.016 1.683

AdaBoost 1.507 3.89 1.044 1.537

Extra Trees 0.843 3.719 1.005 1.649

Deep Neural Net. 0.37 2.037 0.683 0.927

The bold values indicate the best values that we obtained with respect to the corresponding metric. The bestvalue is not always the highest value. For example, when the metric measures the error (e.g., MAE or RMSE),the smallest value is the best value. However, for the metrics such as accuracy, AUC, precision, recall, andF-measure, the highest value is the best value

Table 3 The results of theexperiments on BPIC 2012event log using the predictiontask RE6


MAE (in days) RMSE (in days) MAE (in days) RMSE (in days)

Experiments with the analytic rule RE6 (total duration of allremaining activities named ‘W_Completeren aanvraag’)

RE6

ZeroR 3.963 5.916 3.963 5.916

Linear Reg. 3.613 5.518 3.677 5.669

Decision Tree 2.865 5.221 2.876 5.228

Random Forest 2.863 5.198 2.877 5.213

AdaBoost 3.484 5.655 3.484 5.655

Extra Trees 2.857 5.185 2.868 5.191

Deep Neural Net. 2.487 5.683 2.523 5.667


i.e.,NumDifRemAct counts the number of different values ofthe attribute ‘activityNameEN’ from the current time pointuntil the end of the process. As the next workload-relatedprediction task, we specify the task for predicting the numberof remaining events/activities as follows:

RE9 = 〈curr < last �⇒ RemAct, 0〉

where RemAct = count(true; where x = curr : last), i.e.,RemAct counts the number of events/activities from the cur-rent time point until the end of the process.

Both RE8 and RE9 can be fed into our tool. For the former,we generate a classification model, and for the latter, we gen-erate a regression model. For all of these tasks, we considertwodifferent trace encodings. First,we use the trace encodingthat incorporates several available event attributes, namely

123


Table 4 The results from the experiments on BPIC 2012 event log using the prediction task RE7



Experiments with the analytic rule RE7 (predict whether an application will be eventually ‘DECLINED’)

RE7

ZeroR 0.50 0.78 0.61 0.78 0.68 0.50 0.78 0.61 0.78 0.68

Logistic Reg. 0.69 0.78 0.75 0.78 0.76 0.69 0.77 0.71 0.77 0.71

Naive Bayes 0.67 0.33 0.74 0.33 0.30 0.67 0.33 0.73 0.33 0.30

Decision Tree 0.70 0.78 0.76 0.78 0.77 0.70 0.78 0.76 0.78 0.77

Random Forest 0.71 0.79 0.77 0.79 0.78 0.71 0.79 0.77 0.79 0.78

AdaBoost 0.71 0.81 0.78 0.81 0.78 0.71 0.80 0.78 0.80 0.78

Extra Trees 0.71 0.79 0.77 0.79 0.78 0.71 0.79 0.77 0.79 0.78

Voting 0.71 0.79 0.77 0.79 0.78 0.71 0.79 0.77 0.79 0.77

Deep Neural Net. 0.71 0.80 0.77 0.80 0.78 0.71 0.80 0.78 0.80 0.78


monitoringResource, org:resource, activityNameNL, activ-ityNameEN, question, concept:name. Second, we use thetrace encoding that only incorporates the event names, i.e.,the values of the attribute concept:name. As before, the firstencoding considers more information than the second encod-ing. The evaluation on the generated prediction models fromthe prediction tasks specified above is shown in Tables 5 and6.

6.4 Discussion on the experiments

In total, our experiments involve 9 different prediction tasksover 3 different real-life event logs from 3 different domains(1 event log from BPIC 2015, 1 event log from BPIC 2012,and 1 event log from BPIC 2013).

Overall, these experiments show the capabilities of ourlanguage in capturing and specifying the desired predictiontasks that are based on the event logs coming from real-lifesituation. These experiments also exhibit the applicabilityof our approach in automatically constructing reliable pre-diction models based on the given specification. This issupported by the following facts: First, for all prediction tasksthat we have considered, by considering different input fea-tures and machine learning models, we are able to obtainprediction models that beat the baseline. Moreover, for allprediction tasks that predict categorical values, in our exper-iments we are always able to get a prediction model that hasAUC value greater than 0.5. Recall that AUC = 0.5 indicatesthe worst classifier that is not better than a random guess.Thus, since we have AUC > 0.5, the prediction models thatwe generate certainly take into account the given input andpredict the most probable output based on the given input,instead of randomly guessing the output no matter what the

input is. In fact, in many cases, we could even get very highAUC values which are ranging between 0.8 and 0.9 (seeTables 1, 5). This score is very close to the AUC value forthe best predictor (recall that AUC = 1 indicates the bestclassifier).

As can be seen from the experiments, the choice of theinput features and the machine learning models influence thequality of the prediction model. The result of our experi-ments also shows that there is no single machine learningmodel that always outperforms other models on every task.Since our approach does not rely on a particular machinelearning model, it justifies that we can simply plug in dif-ferent supervised machine learning models in order to getdifferent/better performance. In fact, in our experiments, byconsidering different models we could get different/betterprediction quality. Concerning the input features, for eachtask in our experiments, we intentionally consider two differ-ent input encodings. The first one includes many attributes(hence it incorporates many information), and the secondone includes only a certain attribute (i.e., it incorporates lessinformation). In general, our common sense would expectthat the more information, the better the prediction qualitywould be. This is simply because we thought that, by hav-ing more information, we have a more holistic view overthe situation. Although many of our experiment results showthis fact, there are several cases where considering less fea-tures could give us a better result, e.g., the RMSE score inthe experiment with several models on the tasks RE5, and thescores of several metrics in the experiment RE8 show this fact(see Tables 2, 5). In fact, this aligns with the typical observa-tion in machine learning. Irrelevant features could decreasethe prediction performance because they might introducenoise in the prediction. Although in the learning process a

123


Table 5 The results from the experiments on BPIC 2015 event log using the prediction task RE8



Experiments with the analytic rule RE8 (predicting whether a process is complex)

RE8

ZeroR 0.50 0.57 0.32 0.57 0.41 0.50 0.57 0.32 0.57 0.41

Logistic Reg. 0.92 0.83 0.85 0.83 0.83 0.90 0.84 0.84 0.84 0.83

Naive Bayes 0.81 0.72 0.82 0.72 0.71 0.93 0.68 0.81 0.68 0.66

Decision Tree 0.80 0.79 0.80 0.79 0.80 0.84 0.85 0.85 0.85 0.85

Random Forest 0.95 0.89 0.89 0.89 0.89 0.95 0.90 0.90 0.90 0.90

AdaBoost 0.92 0.87 0.87 0.87 0.87 0.93 0.88 0.88 0.88 0.88

Extra Trees 0.95 0.88 0.88 0.88 0.88 0.95 0.88 0.89 0.88 0.88

Voting 0.94 0.85 0.86 0.85 0.86 0.95 0.88 0.88 0.88 0.88

Deep Neural Net. 0.89 0.84 0.84 0.84 0.84 0.92 0.84 0.84 0.84 0.84


Table 6 The results of theexperiments on BPIC 2015event log using the predictiontask RE9


MAE RMSE MAE RMSE

Experiments with the analytic rule RE9 (the number of the remaining events/activities)

RE9

ZeroR 11.21 13.274 11.21 13.274

Linear Reg. 6.003 7.748 14.143 18.447

Decision Tree 6.972 9.296 6.752 9.167

Random Forest 4.965 6.884 4.948 6.993

AdaBoost 4.971 6.737 4.879 6.714

Extra Trees 4.684 6.567 4.703 6.627

Deep Neural Net. 6.325 8.185 5.929 7.835


goodmodel should (or will try to) give a very lowweight intoirrelevant features, the absence of these unrelated featuresmight improve the quality of the prediction. Additionally, insome situation, too many features might cause overfitting,i.e., the model fits the training data very well, but it fails togeneralize well while doing prediction with new input data.

Based on the experience from these experiments, timeconstraint would also be a crucial factor in choosing themodel when we would like to apply this approach in prac-tice. Somemodels require a lot of tuning in order to achieve agood performance (e.g., neural network), while other modelsdo not need many adjustment and able to achieve relativelygood performance (e.g., Extra Trees, Random Forest).

Looking at another perspective, our experiments com-plement various studies in the area of predictive processmonitoring in several ways. First, instead of using machine

learning models that are typically used in many studieswithin this area such as Random Forest and Decision Tree(cf. [17,18,35,72]), we also consider other machine learningmodels that, to the best of our knowledge, are not typi-cally used. For instance, we use Extra Trees, AdaBoost, andVoting Classifier. Thus, we provide a fresh insight on theperformance of these machine learning models in predic-tive process monitoring by using them in various differentprediction tasks (e.g., predicting (fine-grained) time-relatedinformation, unexpected behaviour). Although this work isnot aimed at comparing various machine learning models, aswe see from the experiments, in several cases, Extra Treesexhibits similar performance (in terms of accuracy) as Ran-dom Forest. There are also some cases where it outperformstheRandomForest (e.g., see the experimentwith the task RE9

in Table 6). In the experiment with the task RE7, AdaBoost

123


outperforms all other models. Regarding the type of the pre-diction tasks,we also look into the tasks that are not yet highlyexplored in the literature within the area of predictive processmonitoring. For instance, while there are numerous workson predicting the remaining processing time, to the best ofour knowledge, there is no literature exploring a more fine-grained task such as the prediction of the remaining durationof a particular type of event (e.g., predicting the durationof all remaining waiting events). We also consider severalworkload-related prediction tasks, which is rarely exploredin the area of predictive process monitoring.

Concerning the deep learning approach, there have beenseveral studies that explore the usage of deep neural networkfor predictive process monitoring (cf. [19,23,24,38,63]).However, they focus on predicting the name of the futureactivities/events, the next timestamp, and the remaining pro-cessing time. In this light, our experiments contribute newinsights on exhibiting the usage of deep learning approach indealing with different prediction tasks other than just thosetasks. Although the deep neural network does not always givethe best result in all tasks in our experiments, there are severalinteresting cases where it shows a very good performance.Specifically, in the experiments with the tasks RE4 and RE5

(cf. Table 2), where all other models cannot beat the RMSEscore of the baseline, the deep neural network comes to therescue and be the only model that could beat the RMSE scoreof our baseline.

To sum up, concerning the three questions regarding thisexperiment that are described in the beginning of this sec-tion, the first two questions are positively answered by ourexperiment. In our experiments of applying our approachover three different real-life event logs and nine differentprediction tasks, we have successfully obtained (reliable)prediction models and positively demonstrate the applica-bility of our approach. Regarding the third question, ourexperiments show that the choice of the machine learningmodel and the information that is incorporated in the traceencoding would influence the quality of the prediction.

7 Related work

This work is tightly related to the area of predictive analy-sis in business process management. In the literature, therehave been several works focusing on predicting time-relatedproperties of running processes. Theworks by [52–55,68,69]focus on predicting the remaining processing time. In [68,69], the authors present an approach for predicting theremaining processing time based on annotated transition sys-tem that contains time information extracted from event logs.The work by [54,55] proposes a technique for predictingthe remaining processing time using stochastic Petri nets.The works by [41,49,58,59] focus on predicting delays in

process execution. In [58,59], the authors use queueing the-ory to address the problem of delay prediction, while [41]explores the delay prediction in the domain of transportand logistics process. In [25], the authors present an ad hocpredictive clustering approach for predicting process perfor-mance. The authors of [63] present a deep learning approach(using LSTM neural network) for predicting the timestampof the next event and use it to predict the remaining cycle timeby repeatedly predicting the timestamp of the next event.

Looking at another perspective, the works by [18,35,72]focus on predicting the outcomes of a running process. Thework by [35] introduces a framework for predicting the busi-ness constraints compliance of a running process. In [35], thebusiness constraints are formulated in propositional LinearTemporal Logic (LTL), where the atomic propositions areall possible events during the process executions. The workby [18] improves the performance of [35] by using a cluster-ingpreprocessing step.Anotherworkonoutcomespredictionis presented by [50], which proposes an approach for pre-dicting aggregate process outcomes by taking into accountthe information about overall process risk. Related to pro-cess risks, [14,15] propose an approach for risks prediction.The work by [37] presents an approach based on evolution-ary algorithm for predicting business process indicators of arunning process instance, where business process indicatoris a quantifiable metric that can be measured by data thatis generated by the processes. The authors of [40] present awork on predicting business constraint satisfaction. Particu-larly, [40] studies the impact of considering the estimationof prediction reliability on the costs of the processes.

Another major stream of works tackle the problem ofpredicting the future activities/events of a running process(cf. [11,19,23,24,38,53,63]). The works by [19,23,24,38,63]use deep learning approach for predicting the future events,e.g., the next event of the current running process. Specif-ically, [19,23,24,63] use LSTM neural network, while [38]uses deep feed-forward neural network. In [19,53,63] theauthors also tackle the problem of predicting the wholesequence of future events (the suffix of the current runningprocess).

A key difference betweenmany of those works and ours isthat, instead of focusing on dealing with a particular predic-tion task (e.g., predicting the remaining processing time orthe next event), this work introduces a specification languagethat enables us to specify various desired prediction tasks forpredicting various future information of a running businessprocess. To deal with these various desired prediction tasks,we present a mechanism to automatically process the givenspecificationof prediction task and to build the correspondingprediction model. From another point of view, several worksin this area often describe the prediction tasks under studysimply by using a (possibly ambiguous) natural language.In this light, the presence of our language complements this

123


area by providing a means to formally and unambiguouslyspecify/describe the desired prediction tasks. Consequently,it could ease the definition of the task and the comparisonamong different works that propose a particular predictiontechnique for a particular prediction task.

Regarding the specification language, unlike the proposi-tional LTL [51], which is the basis of Declare language [47,48] and often used for specifying business constraints over asequence of events (cf. [35]), our FOE language (which is partof our rule-based specification language) allows us not onlyto specify properties over sequence of events but also to spec-ify properties over the data (attribute values) of the events,i.e., it is data-aware. Concerning data-aware specificationlanguage, the work by [1] introduces a data-aware specifi-cation language by combining data querying mechanismsand temporal logic. Such language has been used in sev-eral works on verification of data-aware processes systems(cf. [2,12,13,56]). Theworks by [16,34] provide a data-awareextension of the Declare language based on the First-OrderLTL (LTL-FO). Although those languages are data-aware,they do not support arithmetic expressions/operations overthe data which is absolutely necessary for our purpose, e.g.,for expressing the time difference between the timestamp ofthefirst and the last event.Another interestingdata-aware lan-guage is S-FEEL, which is part of the Decision Model andNotation (DMN) standard [45] by OMG. Though S-FEELsupports arithmetic expressions over the data, it does notallow us to universally/existentially quantify different eventtime points and to compare different event attribute values atdifferent event time points, which is important for our needs,e.g., in specifying the ping-pong behaviour.

Concerning aggregation, there are several formal lan-guages that incorporate such feature (cf. [5,8,21]) and manyof them have been used in system monitoring. The workby [21] extends the temporal logic Past Time LTL withcounting quantifier. Such extension allows us to express aconstraint on the number of occurrences of events (similarto our count function). In [8] a language called SOLOISTis introduced and it supports several aggregate functions onthe number of event occurrences within a certain time win-dow. Differently from ours, both [21] and [8] do not consideraggregation over data (attribute values). The works by [5,6]extend the temporal logic that was introduced in [4,7] withseveral aggregate functions. Such language allowsus to selectthe values to be aggregated. However, due to the interplaybetween the set and bag semantics in their language, as theyhave illustrated, some values might be lost while computingthe aggregation because they first collect the set of tuples ofvalues that satisfy the specified condition and then they col-lect the bag of values to be aggregated from that set of tuplesof values. To avoid this situation, they need to make sure thateach tuple of values has a sort of unique identifier. This sit-uation does not happen in our aggregation because, in some

sense, we directly use the bag semantics while collecting thevalues to be aggregated.

Importantly, unlike those languages above, apart fromallowing us to specify a complex constraint/pattern, a frag-ment of our FOE language also allows us to specify theway to compute/obtain certain values from a trace, whichis needed for specifying the desired information/values tobe predicted, e.g., the remaining processing time, or theremaining number of a certain activity/event. Our language isalso specifically tuned for expressing data-aware propertiesbased on the typical structure of business process executionlogs (cf. [32]), and the design is highly driven by the typi-cal prediction tasks in business process management. Fromanother point of view, our work complements the works onpredicting SLA/business constraints compliance by provid-ing an expressive language to specify complex data-awareconstraints that may involve arithmetic expression and dataaggregation.

8 Discussion

This work should be beneficial for the researchers in thearea of predictive process monitoring. As we have seen, sev-eral works in this area often describe the prediction tasksunder study simply by using a (possibly ambiguous) naturallanguage. In this light, the presence of our language comple-ments this area by providing a means to formally and unam-biguously specify/describe the desired prediction tasks. Con-sequently, it could ease the definition of the task and the com-parison among different works that propose a particular pre-diction technique for a particular prediction task. Similarly, asfor the business process analyst, the presence of our languageshould help them in precisely specifying and communicatingthe desired prediction tasks so as to have suitable predictionservices. The presence of ourmechanism for creating the cor-responding prediction model would also help practitioners inautomatically obtaining the corresponding prediction model.

In the following, we provide a discussion concerning theresearch questions described in Sect. 1 as well as the lan-guage requirements in Sect. 3. Furthermore, we also providea discussion regarding the usability aspect. Finally, this sec-tion also discusses potential limitations of this work, whichmight pave the way towards our future direction.

8.1 Discussion on the research questions

Concerning RQ1, i.e., “How can a specification-drivenmechanism for building predictionmodels for predictive pro-cess monitoring look like?”, as introduced in this work, ourspecification-driven approach for building predictionmodelsfor predictive process monitoring essentially consists of sev-eral steps: (i) First, we have to specify the desired prediction

123


tasks by using the specification language that we have intro-duced in this work; (ii) second, we create the correspondingprediction models based on the given specification by usingthe approach that is explained in Sect. 4. (iii) Finally, oncethe prediction models are created, we can use the constructedprediction models for predicting the future information of arunning process. Notice that this approach requires a mech-anism to express various desired prediction tasks and also amechanism to process the given specification so as to buildthe corresponding prediction models. In this work, we pro-vide all of these and we have also applied this approach intosome case studies based on real-life data (cf. Sect. 6).

Regarding RQ2, i.e., “How can an expressive specifi-cation language that allows us to express various desiredprediction tasks, and at the same time enables us to auto-matically create the corresponding prediction model fromthe given specification, look like? Additionally, can that lan-guage allow us to specify complex expressions involvingdata, arithmetic operations and aggregate functions?”, asexplained in Sect. 3, the specification of a prediction task canbe expressed by using an analytic rule, which is introducedin this work. Essentially, an analytic rule consists of severalconditional-target expressions and it allows us to specify howwe want to map each partial business processes executioninformation into the expected predicted information. As canbe seen in Sects. 4 and 6, a specification provided in this lan-guage can be used to train a classification/regression modelthat can be used as the prediction model. Additionally, as apart of analytic rules, we introduce an FOL-based languagecalled FOE. As can be seen from Sects. 3 and 5, FOE allowsus to specify complex expression involving data, arithmeticoperations and aggregate functions.

Concerning RQ3, i.e., “how can a mechanism to auto-matically build the corresponding prediction model based onthe given specification look like?”, as explained in Sect. 4,roughly speaking, our mechanism to build the correspondingpredictionmodel from the given specification in our languageconsists of two core steps: (i) First, we build the training databased on the given specification in our language; (ii) second,we use supervised machine learning technique to learn thecorresponding prediction model based on the training datathat is generated in the first step.

8.2 Discussion on the language requirements

We now elaborate why our language fulfils all require-ments in Sect. 3.2. For the first requirement, since the targetexpression in the analytic rules can be either numeric or non-numeric expressions, it is easy to see that the first requirementis fulfilled. Various examples of prediction tasks specifica-tion in Sect. 5 also confirm this fact. Our experiments inSect. 6 also exhibit several case studies where the predictedinformation is either numeric or non-numeric values.

Concerning the second requirement, our procedure inSect. 4 and our experiments in Sect. 6 confirm the fact thatwe can have a mechanism for automatically building the cor-responding prediction model from the given specification inour language.

Finally, regarding the requirements 3, 4, and 5, our lan-guage formalism in Sect. 3 and our extensive showcasesin Sect. 5 exhibit the fact that our language fulfils theserequirements. Specifically, we are able to specify complexexpressions over sequence of events by also involving theevents data, arithmetic expressions as well as aggregate func-tions. Additionally, from our various showcases, we can alsosee that our language allows us to specify the target infor-mation to be predicted where we might also have to specifythe way to obtain a certain value and might involve somearithmetic expression.

8.3 Discussion on usability

The usability of the language can only be measured by out-comes of user studies which are beyond the scope of thiswork. Obviously, it is interesting to do this; therefore, weconsider doing a user study as one of our future direc-tions. Although this is one of the limitations of our currentwork, some insights regarding this aspect can be drawn fromprevious studies. Taking the success story from the workson domain-specific languages (DSLs) [39], by providinga language in which the development is driven by or tai-lored to a particular domain/area, DSL offers substantialgains in expressiveness and ease of use compared to gen-eral purpose language in their domain of application [39].In general, DSLs were developed because they can offerdomain-specificity in better ways. In this light, our languagehas a similar situation in the sense that its development ishighly driven by a particular area, namely predictive processmonitoring. Due to this fact, we expect that similar benefitsconcerning this aspect could be obtained.

Another aspect of usability concerns learnability. Accord-ing to [39], one way to design a DSL is to build it based onan existing language. A possible benefit of this approach isfamiliarity for the users. Due to this familiarity, it is expectedthat the users, who are familiar with the corresponding exist-ing language, could easily learn and use it. In this light, ourFOE language follows this approach. It is actually basedon a well-known logic-based language namely First-OrderLogic (FOL). Furthermore, choosing FOL as the basis of thelanguage also gives us another advantage since it is morewell known compared to other more advanced logic-basedlanguages, e.g., Linear Temporal Logic (LTL). This is thecase because typically FOL is a part of many foundationalcourses; hence, it is taught to a wider audience than othermore advanced logics. In general, since this language is alogic-based language, a user with pre-trained knowledge in

123


logic should be able to use the language. Looking at anotherperspective, the development of our language is also highlydriven by the typical structure ofXES event log. SinceXES isa typical standard format for event logs and widely known inthe area of process mining, we expect that this fact improvesthe familiarity for the users and eases the adoption/usage bythe users who are familiar with the XES standard (whichshould be the typical users in this area). A possible directionto improve the usability would be to study advanced visualtechniques and explore the possibility of having visual sup-port (e.g., graphical notations) for creating the specification.Having visual support is a way that has been observed in thearea of DSL as a way to improve usability [26,44]. This kindof approach also has been seen in the literature (cf. [47,48]).

According to [44], the effectiveness of communication ismeasured by the match between the intended message andthe received message (information transmitted). In this light,the presence of the formal semantics of our language pre-vents ambiguous interpretation that could cause a mismatchbetween the intended and the understoodmeaning. In the end,the presence of this language could be useful for BP analyststo precisely specify the desired prediction tasks, and this isimportant in order to have suitable prediction services. Thislanguage could also be an effective means for BP analysts tocommunicate the desired prediction tasks unambiguously.

8.4 Limitation and future work

This work focuses on the problem of predicting the futureinformation of a single running process based on the cur-rent information of that corresponding running process. Inpractice, there could be several processes running concur-rently. Hence, it is absolutely interesting to extend the workfurther so as to consider the prediction problems on concur-rently running processes. This extension would involve theextension of the language itself. For instance, the languageshould be able to specify some patterns over multiple run-ning processes. Additionally, it should be able to expressthe desired predicted information or the way to computethe desired predicted information, and it might involve theaggregation of information over multiple running processes.Consequently, themechanism for building the correspondingprediction model needs to be adjusted.

Our experiments (cf. Sect. 6) show a possible instantia-tion of our generic approach in creating prediction services.In this case we predict the future information of a runningprocess by only considering the information from a sin-gle running process. However, in practice, other processesthat are concurrently running might affect the execution ofother processes. For instance, if there are so many processesrunning together and there are not enough employees forhandling all processes simultaneously, some processesmightneed to wait. Hence, when we predict the remaining duration

of waiting events, the current workload information might bea factor that need to be considered and ideally these informa-tion should be incorporated in the prediction. One possibilityto overcome this limitation is to use the trace encoding func-tion that incorporates the information related to the processesthat are concurrently running. For instance, we can makean encoding function that extracts relevant information fromall processes that are concurrently running, and use themas the input features. Such information could be the num-ber of employees that are actively handling some processes,the number of available resources/employees, the number ofprocesses of a certain type that are currently running, etc.

This kind of machine learning-based technique performsthe prediction based on the observable information. Thus, ifthe information to be predicted depends on some unobserv-able factors, the quality of the predictionmight be decreasing.Therefore, in practice, all factors that highly influence theinformation to be predicted should be incorporated as muchas possible. Furthermore, the prediction model is only builtbased on the historical information about the previously run-ning processes and neglects the possibility of the existence ofthe domain knowledge (e.g., some organizational rules) thatmight influence the prediction. In some sense, it (implicitly)assumes that the domain knowledge is already incorporatedin those historical data that captures the processes executionin the past. Obviously, it is then interesting to develop fur-ther the technique so as to incorporate the existing domainknowledge in the creation of the prediction model with theaim of enhancing the prediction quality. Looking at anotherperspective, since the prediction model is only built basedon the historical data of the past processes execution, thisapproach is absolutely suitable for the situation in which the(explicit) process model is unavailable or hard to obtain.

As also observed by other works in this area (e.g., [69]),in practice, by predicting the future information of a runningprocess, we might affect the future of the process itself, andhence, wemight reduce the preciseness of the prediction. Forinstance, when it is predicted that a particular process wouldexhibit an unexpected behaviour, we might be eager to pre-vent it by closelywatching the process in order to prevent thatunexpected behaviour. In the end, that unexpected behaviourmight not be happened due to our preventive actions, andhence, the prediction is not happened.On theother hand, ifwepredict that a particular process will run normally, we mightput less attention than expected into that process, and hence,the unexpected behaviour might occur. Therefore, knowingthe (prediction of the) future might not always be good forthis case. This also indicates that a certain care need to bedone while using the predicted information.

123


9 Conclusion

Wehave introduced an approach for obtaining predictive pro-cess monitoring services based on the specification of thedesired prediction tasks. Specifically, we proposed a novelrule-based language for specifying the desired predictiontasks, and we devise a mechanism for automatically buildingthe corresponding predictionmodels based on the given spec-ification. Establishing such language is a non-trivial task. Thelanguage should be able to capture various prediction tasks,while at the same time allowing us to have a procedure forbuilding/deriving the corresponding prediction model. Ourlanguage is a logic-based language which is fully equippedwith a well-defined formal semantics. Therefore, it allows usto do formal reasoning over the specification, and to have amachine processable language that enables us to automatethe creation of the prediction model. The language allowsus to express complex properties involving data and arith-metic expressions. It also allows us to specify the way howto compute certain values. Notably, our language supportsseveral aggregate functions. A prototype that implementsour approach has been developed, and several experimentsusing real-life event logs confirmed the applicability of ourapproach. Remarkably, our experiments involve the usage ofa deep learning model. In particular, we use the deep feed-forward neural network.

Apart from those that are discussed in Sect. 8, the futurework includes the extension of the tool and the language. Onepossible extension would be to incorporate trace attributeaccessor that allows us to specify properties involving traceattribute values. As our FOE language is a logic-based lan-guage, there is a possibility to exploit existing logic-basedtools such as satisfiability modulo theories (SMT) solver [3]for performing some reasoning tasks related to the language.Experimenting with other supervised machine learning tech-niques would be the next step as well, for instance by usinganother deep learning approach (i.e., another type of neuralnetwork such as recurrent neural network) with the aim ofimproving the prediction quality.

Acknowledgements Open access funding provided by University ofInnsbruck and Medical University of Innsbruck. The authors thank TriKurniawanWijaya for various suggestions related to this work, andYas-min Khairina for the implementation of several prototype components.

Open Access This article is distributed under the terms of the CreativeCommons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution,and reproduction in any medium, provided you give appropriate creditto the original author(s) and the source, provide a link to the CreativeCommons license, and indicate if changes were made.

A Extended details on the formal semantics

The aggregate function max(numExp1,numExp2) com-putes the maximum value between the two values that areobtained by evaluating the specified two numeric expressionsnumExp1 and numExp2. It gives undefined value ⊥ if oneof them is evaluated to undefined value ⊥ (similarly for theaggregate function min(numExp1,numExp2) except that itcomputes the minimum value). Formally, the semantics ofthese functions is defined as follows:

(min(numExp1,numExp2))τ,kν =⎧

⎨

⎩

(numExp1)τ,kν if (numExp1)

τ,kν ≤ (numExp2)

τ,kν


τ,kν > (numExp2)

τ,kν

⊥ otherwise

(max(numExp1,numExp2))τ,kν =⎧

⎨

⎩


τ,kν ≥ (numExp2)

τ,kν


τ,kν < (numExp2)

τ,kν

⊥ otherwise

The aggregate function concat concatenates the valuesthat are obtained from the evaluation of the given non-numeric expression under the valid aggregation range (i.e.,we only consider the valuewithin the given aggregation rangein which the aggregation condition is satisfied). Moreover,the concatenation ignores undefined values and treats themas empty string. The formal semantics of the aggregate func-tion concat is provided in Fig. 3.

B More showcases

In the following, we present more showcases of predictiontask specification using our language.

B.1 Cost-related prediction

Suppose that each activity within a process has its own costand this information is stored in the attribute named cost. Thetask for predicting the total cost of a process can be specifiedas follows:

R19 = 〈curr < last �⇒sum(e[x]. cost; where x = 1 : last), 0〉,

where R19 maps each trace prefix τ k into the correspondingtotal cost that is computed by summing up the cost of allactivities. We can also specify the task for predicting themaximal cost within a process as follows:

R20 = 〈curr < last �⇒max(e[x]. cost; where x = 1 : last), 0〉.

123

http://creativecommons.org/licenses/by/4.0/

http://creativecommons.org/licenses/by/4.0/


Fig. 3 Formal Semantics of the aggregate function concat

In this case, R20 computes the maximal cost among the costof all activities within the corresponding process. Similarly,we can specify the task for predicting the average activitycost as follows:

R21 = 〈curr < last �⇒avg(e[x]. cost; where x = 1 : last), 0〉.

We could also create a more detailed specification. Forinstance, we want to predict the total cost of all validationactivities. This task can be specified as follows:

R22 = 〈curr < last �⇒ TotalValidationCost, 0〉.

where TotalValidationCost is as follows:

sum(e[x]. cost; where x = 1 : last;and e[x]. concept:name == “Validation”)

In a certain situation, the cost of an activity can be bro-ken down into several components such as human cost andmaterial cost. Thus, the total cost of each activity is actuallythe sum of the human and material costs. To take these com-ponents into account, the prediction task can be specified asfollows:

R23 = 〈curr < last �⇒ TotalCost, 0〉.

where TotalCost is as follows:

sum(e[x]. humanCost + e[x].materialCost;where x = 1 : last)

One might consider a process as expensive if its total costis greater than a certain amount (e.g., 550 Eur), otherwise itis normal. Based on this characteristic, we could specify atask for predicting whether a process would be expensive ornot as follows:

R24 = 〈TotalCost > 550 �⇒ “expensive”, “normal”〉

where TotalCost = sum(e[x]. cost; where x = 1 : last).

B.2 Predicting process performance

One could consider the process that runs longer than a cer-tain amount of time as slow, otherwise it is normal. Given a(partial) process execution information, we might be inter-ested to predict whether it will end up as a slow or a normalprocess. This prediction task can be specified as follows:

R25 = 〈Cond12 �⇒ “Slow”, “normal”〉.where

Cond12 = (e[last]. time:timestamp −e[1]. time:timestamp) > 18.000.000.

R25 states that if the total running time of a process is greaterthan 18.000.000 milliseconds (5 hours), then it is catego-rized as slow, otherwise it is normal. During the training,R25 maps each trace prefix τ k into the corresponding perfor-mance category (i.e., slow or normal). In this manner, we geta prediction model that is trained to predict whether a certain(partial) trace will most likely be slow or normal.

Notice that we can specify a more fine-grained character-istic of process performance. For instance, we can add onemore characteristic into R25 by saying that the processes thatspend less than 3 hours (10.800.000 milliseconds) are con-sidered as fast. This is specified by R26 as follows:

R26 = 〈Cond12 �⇒ “Slow”, Cond13 �⇒ “Fast”, “normal”〉

where

Cond13 = (e[last]. time:timestamp −e[1]. time:timestamp) < 10.800.000

One might consider that a process is performed efficientlyif there are only small amount of task handovers betweenresources. On the other hand, one might consider a process

123


is efficient if it involves only a certain number of differentresources. Suppose that the processes that have more than7 times of task handovers among the (human) resources areconsidered to be inefficient. We can then specify a task topredict whether a (partial) trace ismost likely to be inefficientor not as follows:

R27 = 〈Cond14 > 7 �⇒ “inefficient”, “normal”〉


count(e[x]. org:resource = e[x + 1]. org:resource;where x = 1 : last)

,

i.e., Cond14 counts howmany times the value of the attributeorg:resource is changing from a one time point to anothertime point by checking whether the value of the attributeorg:resource at a particular time point is different from thevalue of the attribute org:resource at the next time point. Now,suppose that the processes that involve more than 5 resourcesare considered to be inefficient. We can then specify a task topredict whether a (partial) trace ismost likely to be inefficientor not as follows:

R28 = 〈Cond15 > 5 �⇒ “inefficient”, “normal”〉

where Cond15 = countVal(org:resource; within 1 : last),i.e., it counts the number of different values of the attributeorg:resource. As before, using R27 and R28, we could thentrain a classifier to predict whether a process will most likelyperform inefficiently or normal.

B.3 Predicting future activities/events

The task for predicting the next activity/event can be specifiedas follows:

R29 = 〈curr < last �⇒ e[curr + 1]. concept:name, “”〉.

During the construction of the prediction model, R29 mapseach trace prefix τ k into its next activity name, becausee[curr + 1]. concept:name is evaluated to the name of thenext activity.

Similarly, we can specify the task for predicting the nextlifecycle as follows:

R30 = 〈curr < last �⇒ e[curr + 1]. lifecycle:transition, “”〉

In this case, sincee[curr+1]. lifecycle:transition is evaluatedto the lifecycle information of the next event, R30 maps eachtrace prefix τ k into its next lifecycle.

Instead of just predicting the information about the nextactivity, we might be interested in predicting more informa-tion such as the information about the next three activities.This task can be specified as follows:

R31 = 〈curr + 3 ≤ last �⇒ Next3Activities, RemEvents〉.

where

Next3Activities = concat(e[x]. concept:name;where x = curr + 1 : curr + 3)

RemEvents = concat(e[x]. concept:name;where x = curr + 1 : last)

During the construction of the prediction model, in the train-ing phase, R31 maps each trace prefix τ k into the informationabout the next three activities.

C Implementation

The implementation of our approach is visually illustratedin Fig. 4. Essentially, we have two main phases, namelythe preparation and the prediction phases. In the prepara-tion phase, we construct the prediction models based on thegiven event log, as well as based on: (i) the prediction tasksspecification, (ii) the desired encoding mechanisms, and (iii)the desired classification/regression models. Once the pre-diction models are built, in the second phase, we can use thegenerated models to perform the prediction task in order topredict the future information of the given partial trace.

As a proof of concept, we have implemented two ProMplug-ins. One plug-in is for creating the prediction modelsbased on the given specification, and another plug-in is forpredicting the future information of a partial trace by usingthe generated predictionmodels. More information about theimplementation can be found at http://bit.ly/sdprom2.

The use case diagramof our prototype is depicted in Fig. 5.

Build Prediction Model(s)

Desired EncodingMechanism

Desired Classification/Regression Models

Event Logs

Prediction Model(s) Perform Prediction

Prediction TaskSpecification

Partial Trace

Prediction Results

PredictionPhase

PreparationPhase

Fig. 4 Illustration of the approach and the implementation

123



Specify Prediction Task

User

Create PredictionModel

Predict FutureInformation

Choose theClassification/

Regression Model

Choose theEncoding

Mechanism

<<include>>

<<include>>

<<include>>

SDPROM

Fig. 5 Use case diagram of the prototype

References

1. Bagheri Hariri, B., Calvanese, D., De Giacomo, G., Deutsch, A.,Montali, M.: Verification of relational data-centric dynamic sys-temswith external services. In: The 32ndACMSIGACTSIGMODSIGAI Symposium on Principles of Database Systems (PODS), pp163–174 (2013)

2. Bagheri Hariri, B., Calvanese, D., Montali, M., Santoso, A., Solo-makhin,D.:Verification of semantically-enhanced artifact systems.In: Proceedings of the 11th International Joint Conference on Ser-viceOrientedComputing (ICSOC), LNCS, vol. 8274, pp. 600–607.Springer (2013). https://doi.org/10.1007/978-3-642-45005-1_51

3. Barrett, C.W., Sebastiani, R., Seshia, S.A., Tinelli, C.: Satisfiabilitymodulo theories. In: Biere, A., Heule, M., van Maaren, H. (eds.)Handbook of Satisfiability. IOS Press, Amsterdam (2009)

4. Basin, D., Klaedtke, F., Müller, S., Pfitzmann, B.: Runtime moni-toring of metric first-order temporal properties. In: IARCS AnnualConference on Foundations of Software Technology and Theo-retical Computer Science, Leibniz International Proceedings inInformatics (LIPIcs), vol. 2, pp 49–60 (2008)

5. Basin, D., Klaedtke, F.,Marinovic, S., Zalinescu, E.:Monitoring oftemporal first-order properties with aggregations. In: Runtime Ver-ification (RV) 2013, LNCS, vol. 8174, pp. 40–58. Springer (2013)

6. Basin, D., Klaedtke, F.,Marinovic, S., Zalinescu, E.:Monitoring oftemporal first-order properties with aggregations. Formal MethodsSyst. Des. 46(3), 262–285 (2015)

7. Basin,D.,Klaedtke, F.,Müller, S., Zalinescu, E.:Monitoringmetricfirst-order temporal properties. J. ACM 62(2), 15:1–15:45 (2015)

8. Bianculli, D., Ghezzi, C., San Pietro, P.: The tale of SOLOIST:a specification language for service compositions interactions. In:Formal Aspects of Component Software (FACS) 2012, LNCS, vol.7684, pp. 55–72. Springer (2013)

9. Breiman, L.: Random forests. Mach. Learn. 45(1), 5–32 (2001)10. Breiman, L., Friedman, J., Stone, C., Olshen, R.: Classification

and Regression Trees The Wadsworth and Brooks-Cole Statistics-probability Series. Taylor & Francis, Milton Park (1984)

11. Breuker, D., Matzner, M., Delfmann, P., Becker, J.: Comprehen-sible predictive models for business processes. MIS Q. 40(4),1009–1034 (2016)

12. Calvanese, D., Ísmail Ílkan Ceylan, Montali, M., Santoso, A.:Verification of context-sensitive knowledge and action bases. In:Proceedings of the 14th European Conference on Logics in Artifi-cial Intelligence (JELIA), LNCS, vol. 8761, pp. 514–528, Springer(2014). https://doi.org/10.1007/978-3-319-11558-0_36

13. Calvanese,D.,Montali,M., Santoso,A.:Verification of generalizedinconsistency-aware knowledge and action bases. In: Proceedingsof the 24th International Joint Conference on Artificial Intelligence(IJCAI), pp. 2847–2853. AAAI Press (2015)

14. Conforti, R., de Leoni, M., La Rosa, M., van der Aalst, W.M.P.:Supporting Risk-Informed Decisions During Business ProcessExecution, pp. 116–132. Springer, Berlin (2013)

15. Conforti, R., de Leoni, M., La Rosa, M., van der Aalst, W.M.,ter Hofstede, A.H.: A recommendation system for predicting risksacross multiple business process instances. Decis. Support Syst.69, 1–19 (2015)

16. DeMasellis, R., Maggi, F.M., Montali, M.: Monitoring data-awarebusiness constraints with finite state automata. In: Proceedings ofthe 2014 International Conference on Software and System Pro-cess, pp. 134–143. ACM (2014)

17. Di Francescomarino, C., Dumas, M., Federici, M., Ghidini, C.,Maggi, F.M., Rizzi, W.: Predictive business process monitoringframework with hyperparameter optimization. In: Proceedingsof the 28th International Conference on Advanced InformationSystems Engineering (CAiSE), LNCS, vol. 9694, pp. 361–376.Springer (2016)

18. Di Francescomarino, C., Dumas, M., Maggi, F.M., Teinemaa, I.:Clustering-based predictive process monitoring. IEEE Trans. Serv.Comput. PP(99), 1–18 (2016)

19. Di Francescomarino, C., Ghidini, C., Maggi, F.M., Petrucci, G.,Yeshchenko, A.: An eye into the future: leveraging a-priori knowl-edge in predictive business process monitoring. In: Proceedings ofthe 15th International Conference on Business Process Manage-ment (BPM), LNCS (2017)

20. Di Francescomarino, C., Ghidini, C., Maggi, F.M., Milani, F.: Pre-dictive process monitoring methods: Which one suits me best? In:Proceedings of the 16th International Conference on Business Pro-cess Management (BPM), pp. 462–479. Springer (2018)

21. Du, X., Liu, Y., Tiu, A.: Trace-length independent runtime mon-itoring of quantitative policies in LTL. In: Formal Methods (FM)2015, LNCS, vol. 9109, pp 231–247. Springer (2015)

22. Dumas, M., La Rosa, M., Mendling, J., Reijers, H.A.: Fundamen-tals of Business Process Management, 2nd edn. Springer, Berlin(2018)

23. Evermann, J., Rehse, J.R., Fettke, P.: A deep learning approachfor predicting process behaviour at runtime. In: BPM Workshops2016, pp. 327–338. Springer (2017)

24. Evermann, J., Rehse, J.R., Fettke, P.: Predicting process behaviourusing deep learning. Decis. Support Syst. 100, 129–140 (2017)

25. Folino, F., Guarascio, M., Pontieri, L.: Discovering context-awaremodels for predicting business process performances. In: On theMove toMeaningful Internet Systems: OTMConference 2012, pp.287–304. Springer (2012)

26. Frank, U.: Domain-Specific Modeling Languages: RequirementsAnalysis and Design Guidelines, pp. 133–157. Springer, Berlin(2013)

27. Freund, Y., Schapire, R.E.: A decision-theoretic generalization ofon-line learning and an application to boosting. J. Comput. Syst.Sci. 55(1), 119–139 (1997)

28. Friedman, J., Hastie, T., Tibshirani, R.: The Elements of StatisticalLearning. Springer, Berlin (2001)

29. Geurts, P., Ernst, D., Wehenkel, L.: Extremely randomized trees.Mach. Learn. 63(1), 3–42 (2006)

123

https://doi.org/10.1007/978-3-642-45005-1_51

https://doi.org/10.1007/978-3-319-11558-0_36


30. Goodfellow, I., Bengio, Y., Courville, A.: Deep Learning. MITPress, Cambridge (2016)

31. Han, J., Pei, J., Kamber, M.: Data Mining: Concepts and Tech-niques. Elsevier, Amsterdam (2011)

32. IEEE Comp Intelligence Society.: IEEE Standard for eXtensibleEvent Stream (XES) for achieving interoperability in event logsand event streams. IEEE Std 1849-2016 (2016)

33. Leontjeva, A., Conforti, R., Di Francescomarino, C., Dumas, M.,Maggi, F.M.: Complex symbolic sequence encodings for predictivemonitoring of business processes. In: Proceedings of the 13th Inter-national Conference on Business Process Management (BPM),LNCS, Springer (2015)

34. Maggi, F.M., Dumas, M., García-Bañuelos, L., Montali, M.: Dis-covering data-aware declarative process models from event logs.In: Proceedings of the 11th International Conference on BusinessProcess Management (BPM), pp. 81–96. Springer (2013)

35. Maggi, F.M., Di Francescomarino, C., Dumas, M., Ghidini, C.:Predictive monitoring of business processes. In: Proceedings of the26th International Conference on Advanced Information SystemsEngineering (CAiSE), LNCS, vol. 8484, pp. 457–472. Springer(2014)

36. Márquez-Chamorro, A.E., Resinas, M., Ruiz-Cortés, A.: Predic-tive monitoring of business processes: a survey. IEEE Trans. Serv,Comput. (2017)

37. Márquez-Chamorro, A.E., Resinas, M., Ruiz-Cortés, A., Toro, M.:Run-time prediction of business process indicators using evolu-tionary decision rules. Expert Syst. Appl. 87, 1–14 (2017)

38. Mehdiyev, N., Evermann, J., Fettke, P.: Amulti-stage deep learningapproach for business process event prediction. In: 2017 IEEE 19thConference on Business Informatics (CBI), vol. 01, pp. 119–128(2017)

39. Mernik, M., Heering, J., Sloane, A.M.: When and how to developdomain-specific languages. ACM Comput. Surv. 37(4), 316–344(2005)

40. Metzger, A., Föcker, F.: Predictive business process monitor-ing considering reliability estimates. In: Proceedings of the 29thInternational Conference on Advanced Information Systems Engi-neering (CAiSE), pp 445–460. Springer (2017)

41. Metzger, A., Franklin, R., Engel, Y.: Predictive monitoring of het-erogeneous service-oriented business networks: the transport andlogistics case. In: Annual SRII Global Conference (2012)

42. Metzger, A., Leitner, P., Ivanovic, D., Schmieders, E., Franklin,R., Carro, M., Dustdar, S., Pohl, K.: Comparing and combiningpredictive business process monitoring techniques. IEEE Trans.Syst. Man Cybern. Syst. 45(2), 276–290 (2015)

43. Mohri, M., Rostamizadeh, A., Talwalkar, A.: Foundations ofMachine Learning. MIT Press, Cambridge (2012)

44. Moody, D.: The “physics” of notations: toward a scientific basis forconstructing visual notations in software engineering. IEEE Trans.Softw. Eng. 35(6), 756–779 (2009)

45. ObjectManagement Group.: DecisionModel andNotation (DMN)1.0. http://www.omg.org/spec/DMN/1.0/ (2015)

46. Pedregosa, F., Varoquaux, G., Gramfort, A., Michel, V., Thirion,B., Grisel, O., Blondel,M., Prettenhofer, P.,Weiss, R., Dubourg, V.,Vanderplas, J., Passos,A., Cournapeau,D., Brucher,M., Perrot,M.,Duchesnay, E.: Scikit-learn: machine learning in Python. J. Mach.Learn. Res. 12, 2825–2830 (2011)

47. Pesic, M., van der Aalst, W.M.P.: A declarative approach for flex-ible business processes management. In: BPM Workshops 2006,pp. 169–180. Springer (2006)

48. Pesic, M., Schonenberg, H., van der Aalst, W.M.P.: DECLARE:full support for loosely-structured processes. In: 11th IEEE Inter-national Enterprise Distributed Object Computing Conference(EDOC 2007), pp. 287–287 (2007)

49. Pika, A., van der Aalst, W.M.P., Fidge, C.J., ter Hofstede, A.H.M.,Wynn, M.T.: Predicting deadline transgressions using event logs.In: BPM Workshops 2012, LNBIP, Springer (2012)

50. Pika, A., van der Aalst, W., Wynn, M., Fidge, C., ter Hofstede, A.:Evaluating and predicting overall process risk using event logs. Inf.Sci. 352–353, 98–120 (2016)

51. Pnueli, A.: The temporal logic of programs. In: Proceedings of the18th Annual Symposium on the Foundations of Computer Science(FOCS), pp. 46–57 (1977)

52. Polato, M., Sperduti, A., Burattin, A., de Leoni, M.: Data-awareremaining time prediction of business process instances. In: 2014International Joint Conference on Neural Networks (IJCNN)(2014)

53. Polato, M., Sperduti, A., Burattin, A., Leoni, Md: Time and activ-ity sequence prediction of business process instances. Computing100(9), 1005–1031 (2018)

54. Rogge-Solti, A., Weske, M.: Prediction of remaining service exe-cution time using stochastic petri nets with arbitrary firing delays.In: Proceedings of the 11th International Joint Conference on Ser-viceOrientedComputing (ICSOC), LNCS, vol. 8274, pp. 389–403.Springer (2013)

55. Rogge-Solti, A., Weske, M.: Prediction of business process dura-tions using non-markovian stochastic petri nets. Inf. Syst. 54, 1–14(2015)

56. Santoso, A.: Verification of data-aware business processes in thepresence of ontologies. Ph.D. thesis, Free University of Bozen-Bolzano, TechnischeUniversität Dresden. http://nbn-resolving.de/urn:nbn:de:bsz:14-qucosa-213372 (2016)

57. Santoso, A.: Specification-driven multi-perspective predictivebusiness process monitoring. In: Enterprise, Business-Process andInformation Systems Modeling, BPMDS 2018, EMMSAD 2018,LNBIP, vol. 318, pp. 97–113. Springer (2018) https://doi.org/10.1007/978-3-319-91704-7_7

58. Senderovich, A., Weidlich, M., Gal, A., Mandelbaum, A.: Queuemining predicting delays in service processes. In: Proceedings ofthe 26th International Conference on Advanced Information Sys-tems Engineering (CAiSE), LNCS, vol. 8484, pp. 42–57. Springer(2014)

59. Senderovich, A., Weidlich, M., Gal, A., Mandelbaum, A.: Queuemining for delay prediction in multi-class service processes. Inf.Syst. 53, 278–295 (2015)

60. Senderovich, A., Di Francescomarino, C., Ghidini, C., Jorbina,K., Maggi, F. M.: Intra and inter-case features in predictive pro-cess monitoring: a tale of two dimensions. In: Proceedings of the15th International Conference on Business Process Management(BPM), pp. 306–323. Springer, Cham (2017)

61. Smullyan, R.M.: First Order Logic. Springer, Berlin (1968)62. Steeman, W.: BPI Challenge (2013). https://doi.org/10.4121/uuid:

a7ce5c55-03a7-4583-b855-98b86e1a2b0763. Tax, N., Verenich, I., La Rosa, M., Dumas, M.: Predictive business

process monitoring with LSTM neural networks. In: Proceedingsof the 29th International Conference on Advanced InformationSystems Engineering (CAiSE), LNCS, vol. 10253, pp. 477–492.Springer (2017)

64. Theano Development Team.: Theano: A Python Framework forFastComputation ofMathematical Expressions. arXiv:1605.02688(2016)

65. vanderAalst,W.:Re-engineeringknock-out processes.Decis. Sup-port Syst. 30(4), 451–468 (2001)

66. van der Aalst, W., et al.: Process mining manifesto. In: BPMWork-shops 2012, LNBIP, vol. 99, pp. 169–194. Springer (2012)

67. van der Aalst, W.M.P.: Process Mining-Data Science in Action,2nd edn. Springer, Berlin (2016)

68. van der Aalst, W.M.P., Pesic, M., Song, M.: Beyond process min-ing: from the past to present and future. In: Proceedings of the 22nd

123

http://www.omg.org/spec/DMN/1.0/

http://nbn-resolving.de/urn:nbn:de:bsz:14-qucosa-213372

http://nbn-resolving.de/urn:nbn:de:bsz:14-qucosa-213372

https://doi.org/10.1007/978-3-319-91704-7_7

https://doi.org/10.1007/978-3-319-91704-7_7

https://doi.org/10.4121/uuid:a7ce5c55-03a7-4583-b855-98b86e1a2b07

https://doi.org/10.4121/uuid:a7ce5c55-03a7-4583-b855-98b86e1a2b07

http://arxiv.org/abs/1605.02688


international conference on Advanced Information Systems Engi-neering (CAiSE), LNCS, vol. 6051, pp. 38–52. Springer (2010)

69. van derAalst,W.M.P., Schonenberg,M., Song,M.: Timepredictionbased on process mining. Inf. Syst. 36(2), 450–475 (2011)

70. Van Dongen, B.: BPI Challenge (2012). https://doi.org/10.4121/uuid:3926db30-f712-4394-aebc-75976070e91f

71. Van Dongen, B.: BPI Challenge (2015). https://doi.org/10.4121/uuid:ed445cdd-27d5-4d77-a1f7-59fe7360cfbe

72. Verenich, I., Dumas, M., La Rosa, M., Maggi, F.M., Di Francesco-marino, C.: Complex symbolic sequence clustering and multipleclassifiers for predictive process monitoring. In: BPM Workshops2015, LNBIP, vol. 256, pp. 218–229. Springer (2015)

73. Verenich, I., Dumas, M., La Rosa, M., Maggi, F.M., Di Francesco-marino,C.:Minimizing overprocessingwaste in business processesvia predictive activity ordering. In: Proceedings of the 28th Interna-tional Conference on Advanced Information Systems Engineering(CAiSE), pp. 186–202. Springer (2016)

Publisher’s Note Springer Nature remains neutral with regard to juris-dictional claims in published maps and institutional affiliations.

Ario Santoso received his bach-elor degree in computer sciencefrom University of Indonesia in2008. In 2011, he finished hismaster study within the EuropeanMaster program in ComputationalLogic (EMCL), and he receivedhis M.Sc. degree from TU Dres-den as well as his Laurea magis-trale in Informatica from FreeUniversity of Bozen-Bolzano. Heobtained his joint Ph.D. degreefrom both Faculty of ComputerScience, Free University of Bozen-Bolzano, and Faculty of Computer

Science, TU Dresden, in 2016. He was a postdoctoral researcherat Free University of Bozen-Bolzano before joining the Depart-ment of Computer Science, University of Innsbruck, as a postdoc-toral researcher in 2017. His research interest lies in the intersectionbetween data and process management, as well as artificial intelli-gence (specifically, logic-based knowledge representation and reason-ing, as well as machine learning). He has served as a reviewer ofseveral international journals such as ACM Transactions on DatabaseSystems (TODS), Journal of Artificial Intelligence Research (JAIR),and Expert Systems with Applications. He has also served as areviewer of several international conferences such as IJCAI, ECAI,and BPM. For more information, visit his website at http://bit.ly/ariosantoso.

Michael Felderer is a professorat the Department of ComputerScience at the University of Inns-bruck, Austria, and a guest pro-fessor at the Department of Soft-ware Engineering at the BlekingeInstitute of Technology, Sweden.His fields of expertise and inter-est include software quality, soft-ware and security processes, data-driven engineering, software ana-lytics and measurement, model-based software engineering andempirical research methodology insoftware and security engineering.

Michael Felderer holds a habilitation degree from the University ofInnsbruck, co-authored more than 130 publications, and received 10best paper awards. His research has a strong empirical focus alsousing methods of data science and is directed towards developmentand evaluation of efficient and effective methods to improve qual-ity and value of industrial software systems and processes in closecollaboration with companies. Michael Felderer is an internationallyrecognized member of the software engineering research communityand supports it as an editorial board member of several journals (IST,IET Software, STTT), organizer of conferences (e.g., General Chair ofPROFES 2017, Program Co-Chair of SEAA 2017, Industry Co-Chairof ESEC/FSE 2019), and regular PC member of premier conferences.For more information, visit his website at mfelderer.at.

123

https://doi.org/10.4121/uuid:3926db30-f712-4394-aebc-75976070e91f

https://doi.org/10.4121/uuid:3926db30-f712-4394-aebc-75976070e91f

https://doi.org/10.4121/uuid:ed445cdd-27d5-4d77-a1f7-59fe7360cfbe

https://doi.org/10.4121/uuid:ed445cdd-27d5-4d77-a1f7-59fe7360cfbe

http://bit.ly/ariosantoso

http://bit.ly/ariosantoso

Specification-driven predictive business process monitoringducted in order to deal with various...

Documents

Transcript of Specification-driven predictive business process monitoringducted in order to deal with various...