Specification-driven predictive business process monitoring

We follow the usual notion of event logs as in process mining [67]. Essentially, an event log captures historical information of business process executions. Within an event log, an execution of a business process instance (a case) is represented as a trace. In the following, we may use the terms trace and case interchangeably. Each trace has several events, and each event in a trace captures the information about a particular event/activity that happens during the process execution. Events are characterized by various attributes, e.g., timestamp (the time when the event occurred).

We now proceed to formally define the notion of event logs as well as their components. Let \({\mathcal {E}} \) be the event universe (i.e., the set of all event identifiers), and \(\mathcal {{A}} \) be the set of attribute names. For any event \(e \in {\mathcal {E}} \), and attribute name \(n \in \mathcal {{A}} \), \(\#_{\text {{n}}}(e)\) denotes the value of attribute n of \(e \). For example, \(\#_{\text {{timestamp}}}(e)\) denotes the timestamp of the event \(e \). If an event \(e \) does not have an attribute named n, then \(\#_{\text {{n}}}(e) = \bot \) (where \(\bot \) is undefined value). A finite sequence over \({\mathcal {E}} \)of length n is a mapping \(\sigma : \{1, \ldots , n\} \rightarrow {\mathcal {E}} \), and we represent such a sequence as a tuple of elements of \({\mathcal {E}} \), i.e., \(\sigma = \langle e _1, e _2, \ldots , e _n\rangle \) where \(e _i = \sigma (i)\) for \(i \in \{1, \ldots , n\}\). The set of all finite sequences over \({\mathcal {E}} \) is denoted by \({\mathcal {E}} ^*\). The length of a sequence \(\sigma \) is denoted by \(|{\sigma }|\).

A trace \(\tau \) is a finite sequence over \({\mathcal {E}} \) such that each event \(e \in {\mathcal {E}} \) occurs at most once in \(\tau \), i.e., \(\tau \in {\mathcal {E}} ^{*}\) and for \(1~\le ~i~<~j~\le ~|{\tau }|\), we have \(\tau (i) \ne \tau (j)\), where \(\tau (i)\) refers to the event of the trace \(\tau \)at the index i. Let \(\tau = \langle e_1, e_2, \ldots , e_n\rangle \) be a trace, \(\tau ^{k} = \langle e_1, e_2, \ldots , e_{k}\rangle \) denotes the k-length trace prefix of \(\tau \) (for \(1~\le ~k~<~n\)).

Finally, an event log \(L \) is a set of traces such that each event occurs at most once in the entire log, i.e., for each \(\tau _1, \tau _2 \in L \) such that \(\tau _1 \ne \tau _2\), we have that \(\tau _1 \cap \tau _2 = \emptyset \), where \(\tau _1 \cap \tau _2 = \{e \in {\mathcal {E}} ~\mid ~\exists i, j \in \mathbb {Z}^+ \text { . } \tau _1(i) = \tau _2(j) = e \}\).

An IEEE standard for representing event logs, called XES (eXtensible Event Stream), has been introduced in [32]. The standard defines the XML format for organizing the structure of traces, events, and attributes in event logs. It also introduces some extensions that define some attributes with pre-defined meaning such as:Event logs that obey this IEEE standard for event logs are often called XES event logs.

In machine learning, a classification and regression model can be seen as a function \(f: \vec {X} \rightarrow Y\) that takes some input features/variables \(\vec {x} \in \vec {X}\) and predicts the corresponding target value/output \(y \in Y\). The key difference is that the output range of the classification task is a finite number of discrete categories (qualitative outputs), while the output range of the regression task is continuous values (quantitative outputs) [28, 31]. Both of them are supervised machine learning techniques where the models are trained with labelled data. That is, the inputs for the training are pairs of input variables \(\vec {x}\) and (expected) target value y. This way, the models learn how to map certain inputs \(\vec {x}\) into the expected target value y.

An analytic rule \(R \) is interpreted as a mapping that maps each (partial) trace into a value that is obtained by evaluating the target expression in which the corresponding condition is satisfied by the corresponding trace. Let \(\tau \) be a (partial) trace, such mapping \(R \) can be illustrated as follows:where \(eval(\mathsf {DefaultTarget})\) and \(eval(\mathsf {Target}_i)\) consecutively denote the results of evaluating the target expression \(\mathsf {DefaultTarget}\) and \(\mathsf {Target}_i\), for \(i \in \{1,\ldots , n\}\). (The formal definition of this evaluation operation is given later.)

We will see later that a target expression specifies either the desired prediction result or expresses the way to obtain the desired prediction result from a trace. Thus, an analytic rule \(R \) can also be seen as a means to map (partial) traces into either the desired prediction results, or to obtain the expected prediction results of (partial) traces.

To specify condition expressions in analytic rules, we introduce a language called First-Order Event Expression (FOE). Roughly speaking, an FOE formula is a First-Order Logic (FOL) formula [61] where the atoms are expressions over some event attribute values and some comparison operators, e.g., \(==\), \(\ne \), >, \(\le \). The quantification in FOE is restricted to the indices of events (so as to quantify the time points). The idea of condition expressions is to capture a certain property of (partial) traces. To give some intuition, before we formally define the language in Sect. 3.4, consider the ping-pong behaviour that can be specified as follows:where (i) \(\text {\texttt {e}}[i+1]\mathbf{. }\,{\text {{org:group}}}\) is an expression for getting the org:group attribute value of the event at index \(i+1\) (similarly for \(\text {\texttt {e}}[i]\mathbf{. }\,{\text {{org:resource}}}\), \(\text {\texttt {e}}[i+1]\mathbf{. }\,{\text {{org:resource}}}\), and \(\text {\texttt {e}}[i]\mathbf{. }\,{\text {{org:group}}}\)), (ii) \({\mathsf {curr}}\) refers to the current time point, and (iii) \({\mathsf {last}}\) refers to the last time point.

The formula \(\mathsf {Cond}_{1}\) basically says that there exists a time point i that is greater than the current time point (i.e., in the future), in which the resource (the person in charge) is different from the resource at the time point \( i+1 \)(i.e., the next time point), their groups are the same, and the next time point is still not later than the last time point. As for the target expression, some simple examples would be some strings such as “ping-pong” and “not ping-pong”. Based on these, we can create an example of an analytic rule \(R _{1}\) as follows:where \(\mathsf {Cond}_{1}\) is as above. In this case, \(R _{1}\) specifies a task for predicting the ping-pong behaviour. In the prediction model creation phase, we will create a classifier that classifies (partial) traces based on whether they satisfy \(\mathsf {Cond}_{1}\) or not (i.e., a trace will be classified into “ping-pong” if it satisfies \(\mathsf {Cond}_{1}\), otherwise it will be classified into “not ping-pong”). During the prediction phase, such classifier can be used to predict whether a given (partial) trace will lead to ping-pong behaviour or not.

The target expression can be more complex than merely a string. For instance, it can be an expression that involves arithmetic operations over numeric values such as¹where \(\text {\texttt {e}}[{\mathsf {last}}]\mathbf{. }\,{\text {{time:timestamp}}}\) refers to the timestamp of the last event and \(\text {\texttt {e}}[{\mathsf {curr}}]\mathbf{. }\,{\text {{time:timestamp}}}\) refers to the timestamp of the current event. Essentially, the expression \(\mathsf {Target}_{\text {remainingTime}}\) computes the time difference between the timestamp of the last event and the current event (i.e., remaining processing time). Then, we can create an analytic rule:which specifies a task for predicting the remaining processing time, because \(R _{2}\) maps each (partial) trace into its remaining processing time. In this case, during the prediction model creation phase, we will create a regression model for predicting the remaining processing time of a given (partial) trace. Section 5 provides more examples of prediction tasks specification using our language.

Driven by various typical prediction tasks that are studied in the area of predictive process monitoring (see [20, 36] for an extensive overview), in the following, we elaborate several requirements for our language as well as the motivation for each requirement. These requirements guide the development 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 the first requirement of our language as follows: One of our goals is to have a mechanism for automatically processing the prediction task specification so as to build the corresponding prediction model. Consequently, our language should fulfil the following requirement: When it comes to predicting the outcome of a process, the existence of an unexpected behaviour, as well as the satisfaction of business constraints, we need to be able to precisely specify the desired outcomes, the corresponding unexpected behaviour, and the corresponding business constraint. As can be seen from the example in Sect. 3.1, these kinds of tasks often require us to express complex properties involving events data (attribute values). Additionally, we might also need to be able to universally or existentially quantify different event time points (e.g., saying that there exist a time point where a certain condition holds) and to compare different event attribute values at different time points (e.g., saying that the person in charge at time point i is different from the person in charge at time point \(i+1\)). As a consequence, this gives us the following requirement: In Sect. 1, we have seen that we might even need to specify a business constraint that requires that the length of customer order processing to be less than 3 hours. Obviously, this requires us to specify an arithmetic expression involving the data. On the other hand, we might also need to specify a constraint saying that the total cost of all validation activities should be less than 100 Eur. In order to be able to specify this constraint, we need to be able to aggregate (sum up) the cost of each validation activity, and only to sum up those validation activities. Thus, we need to be able to aggregate some particular attribute values. All of these give us the following requirement: In the example of predicting the remaining processing time in Sect. 3.1, we also need to be able to specify the target information to be predicted. This often requires us to specify the way to obtain a certain value. For instance, to obtain the remaining processing time, we need to take the difference between the timestamp of the last event and the current event. Hence, we need to be able to specify that the remaining processing time is the difference between the timestamp of the last event and the current event. This gives us the following requirement:

This section is devoted to introduce several components that are needed to define the language for specifying condition and target expressions in Sect. 3.4.

As we have seen in Sect. 3.1, we often need to refer to a particular index of an event within a trace. Recall the expression \(\text {\texttt {e}}[i\!~\!+\!~\!1]\mathbf{. }\,{\text {{org:group}}}\) that refers to the \(\text {org:group}\) attribute value of the event at the index \(i\!~\!+\!~\!1\), and also the expression \(\text {\texttt {e}}[{\mathsf {last}}]\mathbf{. }\,{\text {{time:timestamp}}}\) that refers to the timestamp of the last event. The former requires us to refer to the event at the index \(i\!~\!+\!~\!1\), while the latter requires us to refer to the last event in the trace. To capture this, we introduce the notion of index expression \(\mathsf {idx} \) defined as follows:where (i) i is an index variable. (ii) \({\textit{pint}} \) is a positive integer (i.e., \({\textit{pint}} \in \mathbb {Z}^+\)). (iii) \({\mathsf {last}}\) and \({\mathsf {curr}}\) are special indices in which the former refers to the index of the last event in a trace, and the latter refers to the index of the current event (i.e., last event of the trace prefix under consideration). For instance, given a k-length trace prefix \(\tau ^{k}\) of the trace \(\tau \), \({\mathsf {curr}}\) is equal to k (or \(|{\tau ^{k}}|\)), and \({\mathsf {last}}\) is equal to \(|{\tau }|\). (iv) \(\mathsf {idx} + \mathsf {idx} \) and \(\mathsf {idx}- \mathsf {idx} \) are the usual arithmetic addition and subtraction operations over indices.

The semantics of index expression is defined over traces and considered trace prefix length. Since an index expression can be a variable, given a trace \(\tau \) and a considered trace prefix length k, we first introduce a variable valuation \(\nu \), i.e., a mapping from index variables into \(\mathbb {Z}^+\). We assign meaning to index expression by associating with \(\tau \), k, and \(\nu \) an interpretation function \((\cdot )^{\tau ,k}_{\nu }\) which maps an index expression into \(\mathbb {Z}^+\). Formally, \((\cdot )^{\tau ,k}_{\nu }\) is inductively defined as follows:The definition above says that the interpretation function \((\cdot )^{\tau ,k}_{\nu }\) interprets index expressions as follows: (i) Each variable is interpreted based on how the variable valuation \(\nu \) maps the corresponding variable into a positive integer in \(\mathbb {Z}^+\); (ii) each positive integer is interpreted as itself, e.g., \((2603)^{\tau ,k}_{\nu } = 2603\); (iii) \({\mathsf {curr}}\) is interpreted into k; (iv) \({\mathsf {last}}\) is interpreted into \(|{\tau }|\); and (v) the arithmetic addition/subtraction operators are interpreted as usual.

To access the value of an event attribute, we introduce so-called event attribute accessor, which is an expression of the formwhere \({\textit{attName}}\) is an attribute name and \(\mathsf {idx} \) is an index expression. To define the semantics of event attribute accessor, we extend the definition of our interpretation function \((\cdot )^{\tau ,k}_{\nu }\) such that it interprets an event attribute accessor expression into the attribute value of the corresponding event at the given index. Formally, \((\cdot )^{\tau ,k}_{\nu }\) is defined as follows:Note that the above definition also says that if the event attribute accessor refers to an index that is beyond the valid event indices in the corresponding trace, then we will get undefined value (i.e., \(\bot \)).

As an example of event attribute accessor, the expression \(\text {\texttt {e}}[i]\mathbf{. }\,{\text {{org:resource}}}\) refers to the value of the attribute \(\text {org:resource}\) of the event at the position i.

The value of an event attribute within a trace can be either numeric (e.g., 26, 3.86) or non-numeric (e.g., “sendOrder”), and we might want to specify properties that involve arithmetic operations over numeric values. Thus, we introduce the notion of numeric expression and non-numeric expression as follows:where (i) \(\mathsf {true}\) and \(\mathsf {false}\) are the usual boolean values, (ii) \(\mathsf {String}\) is the usual string (i.e., a sequence of characters), (iii) \(\mathsf {number}\) is a real number, (iv) \(\text {\texttt {e}}[\mathsf {idx} ]\mathbf{. }\,{\text {{NonNumericAttribute}}}\) is an event attribute accessor for accessing an attribute with non-numeric values, and \(\text {\texttt {e}}[\mathsf {idx} ]\mathbf{. }\,{\text {{NumericAttribute}}}\) is an event attribute accessor for accessing an attribute with numeric values, (v) \(\mathsf {numExp} _1 + \mathsf {numExp} _2\) and \(\mathsf {numExp} _1 - \mathsf {numExp} _2\) are the usual arithmetic operations over numeric expressions.

To give the semantics for numeric expression and non-numeric expression, we extend the definition of our interpretation function \((\cdot )^{\tau ,k}_{\nu }\) by interpreting \(\mathsf {true}\), \(\mathsf {false}\), \(\mathsf {String}\), and \(\mathsf {number}\) as themselves, e.g.,and by interpreting the arithmetic operations as usual, e.g.,Formally, we extend our interpretation function as follows:Note that the value of an event attribute might be undefined, i.e., it is equal to \(\bot \). In this case, we define that the arithmetic operations involving \(\bot \) give \(\bot \), e.g., \(26~+~\bot ~=~\bot \).

We now define the notion of event expression as a comparison between either numeric expressions or non-numeric expressions. Formally, it is defined as follows:where (i) \(\mathsf {numExp} \) is a numeric expression; (ii) \(\mathsf {nonNumExp} \) is a non-numeric expression; (iii) the operators \(==\) and \(\ne \) are the usual logical comparison operators, namely equality and inequality; (iv) the operators <, >, \(\le \), and \(\ge \) are the usual arithmetic comparison operators, namely less than, greater than, less than or equal, and greater than or equal.

We interpret each logical/arithmetic comparison operator (i.e., \(==\), \(\ne \), <, >, etc) in the event expressions as usual. For instance, the expression \(26 \ge 3\) is interpreted as \(\mathsf {true}\), while the expression “receivedOrder” \(==\) “sendOrder” is interpreted as \(\mathsf {false}\). Additionally, any comparison involving undefined value (\(\bot \)) is interpreted as false. It is easy to see how to extend the formal definition of our interpretation function \((\cdot )^{\tau ,k}_{\nu }\) towards interpreting event expressions; therefore, we omit the details.

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

An FOE formula is a First-Order Logic (FOL) [61] formula where the atoms are event expressions and the quantification is ranging over event indices. Syntactically, FOE is defined as follows:where (i) \(\mathsf {eventExp}\) is an event expression; (ii) \(\lnot \varphi \) is negated FOE formula; (iii) \(\forall i. \varphi \) is an FOE formula where the variable i is universally quantified; (iv) \(\exists i. \varphi \) is an FOE formula where the variable i is existentially quantified; (v) \(\varphi _1 \wedge \varphi _2\) is a conjunction of FOE formulas; (vi) \(\varphi _1 \vee \varphi _2\) is a disjunction of FOE formulas; (vii) \(\varphi _1 \rightarrow \varphi _2\) is an FOE implication formula saying that \(\varphi _1\) implies \(\varphi _2\); (viii) The notion of free and bound variables is as usual in FOL, except that the variables inside aggregate functions, i.e., aggregation variables, are not considered as free variables; (ix) the aggregation variables cannot be existentially/universally quantified.

The semantics of FOE constructs is based on the usual FOL semantics. Formally, we extend the definition of our interpretation function \((\cdot )^{\tau ,k}_{\nu }\) as follows²:As before, \(\nu [i \mapsto c]\) substitutes each variable i with c, while the other variables are substituted the same way as \(\nu \) is defined. When \(\varphi \) is a closed formula, its truth value does not depend on the valuation of the variables, and we denote the interpretation of \(\varphi \) simply by \((\varphi )^{\tau ,k}_{}\). We also say that the trace \(\tau \) and the prefix length k satisfy \(\varphi \), written \(\tau ,k \models \varphi \), if \((\varphi )^{\tau ,k}_{} = \mathsf {true}\). With a little abuse of notation, sometimes we also say that the k-length trace prefix \(\tau ^{k}\)of the trace \(\tau \)satisfies \(\varphi \), written \(\tau ^{k} \models \varphi \), if \(\tau ,k \models \varphi \).

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

Notice that here we opt for FOL-style syntax for providing the mechanism to refer to a certain event attribute at a particular time point as well as to compare the event attribute values at two different time points. Another possible alternative for expressing properties that involve time points would be to adopt the LTL-style syntax [51] by using the temporal operators. For instance, we could roughly express the following property:which says that, at every time points, it is always be the case that the value of the attribute ‘org:resource’ is not equal to ’Bob’, aswhere \(\mathbf G \) is the usual LTL temporal operator that is typically called ‘Global’. However, when we want to compare the values of two attributes at two different time points, e.g.,we cannot easily do it using the usual LTL-style syntax, and the expression might become less intuitive since we cannot easily refer to a particular time point (by explicitly saying the corresponding time points). Similarly, we also cannot easily specify an arithmetic expression that involves event attributes at two different time points, e.g.,Therefore, in order to have a more intuitive language, we opt for FOL-style syntax.

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

We can now formalize the semantics of analytic rules as illustrated in Sect. 3.1. Formally, given a trace \(\tau \), a considered prefix length k, and an analytic rule \(R \) of the form\(R \) maps \(\tau \) and k into a value obtained from evaluating the corresponding target expression as follows:where \((\mathsf {Target}_i)^{\tau ,k}_{}\) is the application of our interpretation function \((\cdot )^{\tau ,k}_{}\) to the target expression \(\mathsf {Target}_i\) in order to evaluate the expression and get the value. Checking whether the given trace \(\tau \) and the given prefix length k satisfy \(\mathsf {Cond}_i\), i.e., \(\tau ,k \models \mathsf {Cond}_i\), can be done as explained in Sect. 3.4.1. We also require an analytic rule to be well defined, i.e., given a trace \(\tau \), a prefix length k, and an analytic rule \(R \), we say that \(R \)is well defined for \(\tau \) and k if \(R \) maps \(\tau \) and k into exactly one target value, i.e., for every condition expressions \(\mathsf {Cond}_i\) and \(\mathsf {Cond}_j\) in which \(\tau ,k~\models ~\mathsf {Cond}_i\) and \(\tau ,k~\models ~\mathsf {Cond}_j\), we have that \((\mathsf {Target}_i)^{\tau ,k}_{}~=~(\mathsf {Target}_j)^{\tau ,k}_{}\). This notion of well-definedness can be easily generalized to event logs as follows: Given an event log \(L \) and an analytic rule \(R \), we say that \(R \) is well defined for \(L \) if for every possible trace \(\tau \) in \(L \) and every possible prefix length k, we have that \(R \) is well defined for \(\tau \) and k. Note that such condition can be easily checked for the given event log \(L \) and an analytic rule \(R \) since the event log is finite. This notion of well defined is required in order to guarantee that the given analytic rule \(R \) behaves as a function with respect to the given event log \(L \), i.e., \(R \) maps every pair of trace \(\tau \) and prefix length k into a unique value.

Compared to enforcing that each condition in analytic rules must not be overlapped, our notion of well defined gives us more flexibility in making a specification using our language while also guaranteeing reasonable behaviour. For instance, one can specify several characteristics of ping-pong behaviour in a more convenient way by specifying several conditional-target expressions, i.e.,(where each condition expression \(\mathsf {Cond}_i\) captures a particular characteristic of a ping-pong behaviour), instead of using disjunctions of these several condition expressions, i.e.,which could end up into a very long specification of a condition expression.

We can specify the task for predicting unexpected behaviour by first expressing the characteristics of the unexpected behaviour.

Ping-pong Behaviour. The condition expression \(\mathsf {Cond}_{1}\) (in Sect. 3.1) expresses a possible characteristic of ping-pong behaviour. Another possible characterization of ping-pong behaviour is shown below:In other word, \(\mathsf {Cond}_{2}\) characterizes the condition where “an officer 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 of the org:resource value in the next event, but then it changes back into the original value in the next two events, while the values of org:group remain the same.

We can then create an analytic rule to specify the task for predicting ping-pong behaviour as follows:where \(\mathsf {Cond}_{1}\) is the same as specified in Sect. 3.1. During the construction of the prediction model, in the training phase, \(R _{3}\) maps each trace prefix \(\tau ^{k}\) that satisfies either \(\mathsf {Cond}_{1}\) or \(\mathsf {Cond}_{2}\) into the target value “ping-pong”, and those prefixes that neither satisfy \(\mathsf {Cond}_{1}\) nor \(\mathsf {Cond}_{2}\) into “not ping-pong”. After training the model based on this rule, we get a classifier that is trained for distinguishing between (partial) traces that most likely and unlikely lead to ping-pong behaviour. This example also exhibits the ability of our language to specify a behaviour that has multiple characteristics.

Abnormal Activity Duration. The following expression specifies the existence of abnormal waiting duration by stating that there exists a waiting activity in which the duration is more than 2 hours (7.200.000 milliseconds):As before, we can then specify an analytic rule for predicting whether a (partial) trace is likely to have an abnormal waiting duration or not as follows:Applying the approach for constructing the prediction model in Sect. 4, we obtain a classifier that is trained to predict whether a (partial) trace is most likely or unlikely to have an abnormal waiting duration.

Using FOE, we can easily specify numerous expressive SLA conditions as well as business constraints. Furthermore, using the approach presented in Sect. 4, we can create the corresponding prediction model, which predicts the compliance of the corresponding SLA/business constraints.

Time-related SLA. Let \(\mathsf {Cond}_{4}\) be the FOE formula in Example 6. Roughly speaking, \(\mathsf {Cond}_{4}\) expresses an SLA stating that each order that is created will be eventually delivered within 3 hours. We can then specify an analytic rule for predicting the compliance of this SLA as follows:Using \(R _{5}\), our procedure for constructing the prediction model in Sect. 4 generates a classifier that is trained to predict whether a (partial) trace is likely or unlikely to comply with the given SLA.

Separation of Duties (SoD). We could also specify a constraint concerning Separation of Duties (SoD). For instance, we require that the person who assembles the product is different from the person who checks the product (i.e., quality assurance). This can be expressed as follows:Intuitively, \(\mathsf {Cond}_{5}\) states that for every two activities, if they are assembling and checking activities, then the resources who are in charge of those activities must be different. Similar to previous examples, we can specify an analytic rule for predicting 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 not a trace is likely to fulfil this constraint.

Constraint on Activity Duration. Another example would be a constraint on the activity duration, e.g., a requirement which states that each activity must be finished within 2 hours. This can be expressed as follows:\(\mathsf {Cond}_{6}\) basically says that the time difference between two activities is always less than 2 hours (7.200.000 milliseconds). An analytic rule to predict the compliance of this SLA can be specified as follows:Notice that we can express the same specification in a different way, for instancewhereEssentially, \(\mathsf {Cond}_{7}\) expresses a specification on the existence of abnormal activity duration. It states that there exists an activity in which the time difference between that activity and the next activity is greater than 7.200.000 milliseconds (2 hours). Using either \(R _{7}\) or \(R _{8}\), our procedure for building the prediction model (cf. Algorithm 1) gives us a classifier that is trained to distinguish between the partial traces that most likely will and will not satisfy this activity duration constraint.

We could even specify a more fine-grained constraint by focusing into a particular activity. For instance, the following expression specifies that each validation activity must be done within 2 hours (7.200.000 milliseconds):\(\mathsf {Cond}_{8}\) basically says that for each validation activity, the time difference between that activity and its next activity is always less than 2 hours (7.200.000 milliseconds). Similar to the previous examples, it is easy to see that we could specify an analytic rule for predicting the compliance of this SLA and create a prediction model that is trained to predict whether a (partial) trace is likely or unlikely fulfilling this SLA.

In Sect. 3.1, we have seen how we can specify the task for predicting the remaining processing time (by specifying a target expression that computes the time difference between the timestamp of the last and the current events). In the following, we provide another examples on predicting time-related information.

Predicting Delay. Delay can be defined as a condition when the actual processing time is longer than the expected processing time. Suppose we have the information about the expected processing time, e.g., provided by an attribute “\(\text {expectedDuration}\)” of the first event, we can specify an analytic rule for predicting the occurrence of delay as follows:where \(\mathsf {Cond}_{9}\) is specified as follows:\(\mathsf {Cond}_{9}\) states that the difference between the last event timestamp and the first event timestamp (i.e., the processing time) is greater than the expected duration (provided by the value of the event attribute “expectedDuration”). While training the classification model, \(R _{9}\) maps each trace prefix \(\tau ^{k}\) into either “Delay” or “Normal” depending on whether the processing time of the whole trace \(\tau \) is greater than the expected processing time or not.

Predicting the Overhead of Running Time. The overhead of running time is the amount of time that exceeds the expected running time. If the actual running time does not go beyond the expected running time, then the overhead is 0. Suppose that the expected running time is 3 hours (10.800.000 milliseconds), the task for predicting the overhead of running time can then be specified as follows:where \(\textsf {Overhead} = \textsf {TotalRunTime} - 10.800.000\), andIn this case, \(R _{10}\) computes the difference between the actual total running time and the expected total running time. Moreover, it outputs 0 if the actual total running time is less than the expected total running time, since it takes the maximum value between the computed time difference and 0. Applying our procedure for creating the prediction model, we obtain a regression 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 between the timestamp of that event and its succeeding event. The task for predicting the total duration of all remaining “waiting” events can be specified as follows:where \(\textsf {RemWaitingDur}\) is defined as the sum of the duration of all remaining waiting events, formally as follows:As before, based on this rule, we can create a regression model that predicts the total duration of all remaining waiting events.

Predicting Average Activity Duration. We can specify the way to compute the average of activity duration as follows:where the activity duration is defined as the time difference between the timestamp of that activity and its next activity. We can then specify an analytic rule that expresses the task for predicting the average activity duration as follows:Similar to previous examples, applying our procedure for creating the prediction model, we get a regression model that computes the approximation of the average activity duration of a process.

Knowing the information about the amount of work to be done (i.e., workload) would be beneficial. Predicting the activity frequency is one of the ways to get an overview of workload. The following task specifies how to predict the number of the remaining activities that are necessary to be performed:In this case, \(R _{13}\) counts the number of remaining activities. We could also provide a more fine-grained specification by focusing on a certain activity. For instance, in the following we specify the task for predicting the number of the remaining validation activities that need to be done:where \(\textsf {NumOfRemValidation}\) is specified as follows:\(\textsf {NumOfRemValidation}\) counts the occurrence of validation activities between the current event and the last event (the occurrence of validation activity is reflected by the fact that the value of the attribute \(\hbox {concept:name}\) is equal to \(\text {``validation''}\)). Applying our procedure for creating the prediction model over \(R _{13}\) and \(R _{14}\), consecutively we get regression models that predict the number of remaining activities as well as the number of the remaining validation activities.

We could also classify a process into complex or normal based on the frequency of a certain activity. For instance, we could consider a process that requires more than 25 validation activities as complex (otherwise it is normal). The following analytic rule specifies this task:where \(\mathsf {Cond}_{10}\) is specified as follows:Based on \(R _{15}\), we could train a model to classify whether a (partial) trace is likely to be a complex or a normal process.

Human resources could be a crucial factor in the process execution. Knowing the number of different resources that are needed for handling a process could be beneficial. The following analytic rule specifies the task for predicting the number of different resources that are required:During the training phase, since

\({\mathbf {\mathsf{{{countVal}}}}} (\text {org:resource};~{\mathbf {\mathsf{{{{within}}}}}}~1:{\mathsf {last}})\)

is evaluated to the number of different values of the attribute \(\text {org:resource}\) within the corresponding trace, \(R _{16}\) maps each trace prefix \(\tau ^{k}\) into the number of different resources.

To predict the number of task handovers among resources, we can specify the following prediction task:where \(\textsf {NumHandovers}\) is defined as follows:i.e., \(\textsf {NumHandovers}\) counts the number of changes on the value of the attribute \(\text {org:resource}\) and the changes of resources reflect the task handovers among resources. Thus, in this case, \(R _{17}\) maps each trace prefix \(\tau ^{k}\) into the number of task handovers.

A process can be considered as labour intensive if it involves at least a certain number of different resources, e.g., three different number of resources. This kind of task can be specified as follows:where \(\mathsf {Cond}_{11}\) is as follows:Essentially, \(\mathsf {Cond}_{11}\) states that there are at least three different events in which the values of the attribute \(\text {org:resource}\) in those events are different.

Value-added analysis in BPM aims at identifying unnecessary steps within a process with the purpose of eliminating those steps [22]. The steps within a process can be classified into either value-added, business value-added, or non-value added. Value-added steps are the steps that produce/add values to the customer or to the final outcome/product of the process. Business value-added steps are those steps that might not directly add value to the customer but they might be necessary or useful for the business. Non-value-added steps are those that are neither value-added nor business value-added. Based on this analysis, typically we would like to retain those value-added steps, and eliminate (or reduce) those non-value-added steps. These non-value-added steps are often also associated with wastes. An example of waste is overprocessing waste. An overprocessing waste occurs when an activity is performed unnecessarily with respect to the outcome of a process (i.e., it is performed in a way that does not add value to the final outcome/product of the process). It includes tasks that are performed but later found to be unnecessary. In this light, the work by [73] proposes an approach for minimizing the overprocessing waste by employing prediction techniques.

Using our language, we can characterize prediction tasks that could assist in minimizing overprocessing waste. For instance, consider the process of handing personal loan applications. Suppose that there are several checking activities that need to be performed on each application, and these checks can be performed in any order (each check is independent of each other). Failure in any of these checks would make the application rejected and the process stops immediately. Only cases that successfully pass all checks are accepted. This kind of process is often called a knockout process [65]. For instance, let these checking activities be (i) Applicant’s Identity Check (IDC); (ii) Loan Worthiness Assessment (LWA); and (iii) Applicant’s Documents Verification (DV). In this scenario, if we first perform the Identity Check activity and then the Documents Verification activity, but the Document Verification gives negative outcome (i.e., the application is rejected), then the efforts that we have spent on performing the Identity Check activity would be a waste. Thus, it might be desirable to perform the Document Verification step first so that we could reject the application immediately before spending any efforts on any other activities.

In the situation above, it might be desirable to predict the checking activity that most likely would lead to a negative outcome for a certain case of a loan application. By doing this, we can prioritize that activity and reduce the waste of efforts that we spend on unnecessary activities. The analytic rule below specifies the prediction task that predicts the activity that most likely would lead to the negative outcome (i.e., the rejection of the application).whereAs observed by [65], another aspect that can be considered in prioritizing the activities in this kind of process is the effort that needs to be spent on each activity. This effort could be either in terms of the processing time that is needed to perform the activity, the cost that needs to be spent, or the amount of resources that needs to be allocated. An activity is expensive if it requires a lot of efforts to perform (e.g., an activity that requires a large amount of time). By knowing this information, we could give a priority to the activity that is less expensive, and leave those expensive activities to the last so that they are only performed when they are really necessary. For each checking activity, we can specify the corresponding prediction task that predicts the required effort for performing that activity. For instance, we can specify the task for predicting the duration of the identity checking (IDC) activity as follows:where \(\textsf {DurationIDC}\) is defined as follows:Similarly, we can specify the tasks for predicting the duration of the Loan Worthiness Assessment (LWA) activity and the duration of the Document Verification (DV) activity as follows:where \(\textsf {DurationLWA}\) and \(\textsf {DurationDV}\) are defined as follows:As we have seen, all information from all of these simple predictions could, in some sense, be combined/used in order to help to minimize the unnecessary steps in a process, which is one of the goals of value-added analysis.

The event log from BPIC 2013⁷ [62] contains the data from the Volvo IT incident management system called VINST. It stores information concerning the incidents handling process. For each incident, a solution should be found as quickly as possible so as to bring back the service with minimum interruption to the business. It contains 7554 traces (process instances) and 65533 events. There are also several attributes in each event containing various information such as the problem status, the support team (group) that is involved in handling the problem, the person who works on the problem, etc.

In BPIC 2013, ping-pong behaviour is one of the interesting problems to be analyzed. Ideally, an incident should be solved quickly without involving too many support teams. To specify the tasks for predicting whether a process would probably exhibit a ping-pong behaviour, we first identify and express the possible characteristics of ping-pong behaviour as follows:Roughly speaking, \(\mathsf {Cond}_{\text {E1}}\) says that there is a change in the support team while the problem is not being “Queued”. \(\mathsf {Cond}_{\text {E2}}\) and \(\mathsf {Cond}_{\text {E3}}\) state that there is a change in the person who handles the problem, but then at some point it changes back into the original person. \(\mathsf {Cond}_{\text {E4}}\) and \(\mathsf {Cond}_{\text {E5}}\) say that there is a change in the support team (group) who handles the problem, but then at some point it changes back into the original support team. \(\mathsf {Cond}_{\text {E6}}\) states that the process of handling the incident involves at least three different groups.

We then specify three different analytic rules below in order to specify three different tasks for predicting ping-pong behaviour based on various characteristics of this unexpected behaviour.In this case, \(R _{\text {E1}}\) specifies the task for predicting ping-pong behaviour based on the characteristic provided by \(\mathsf {Cond}_{\text {E1}}\) (similarly for \(R _{\text {E2}}\) and \(R _{\text {E3}}\)). These analytic rules can be fed into our tool in order to obtain the prediction model, and for these cases we create classification models.

In BPIC 2013 event log, an incident can have several statuses. One of them is waiting. In this experiment, we predict the remaining duration of all waiting-related events by specifying the following analytic rule:where \(\textsf {RemWaitingTime}\) is as follows:i.e., \(\textsf {RemWaitingTime}\) is the sum of all event duration in which the status is related to waiting (e.g., Awaiting Assignment, Wait, Wait-User, etc). Similarly, we predict the remaining duration of all (exactly) waiting events by specifying the following:where \(\textsf {RemWaitDur}\) is as follows:i.e., \(\textsf {RemWaitDur}\) is the sum of all event duration in which the status is “wait”. Both \(R _{\text {E4}}\) and \(R _{\text {E5}}\) can be fed into our tool, and in this case we generate regression models.

For all of these tasks, we consider two different trace encodings. First, we use the trace encoding that incorporates several available event attributes, namely concept:name, org:resource, org:group, lifecycle:transition, organization involved, impact, product, resource country, organization country, org:role. Second, we use the trace encoding that only incorporates the event names, i.e., the values of the attribute concept:name. Intuitively, the first encoding considers more information than the second encoding. Thus, the prediction models that are obtained by using the first encoding use more input information for doing the prediction. The evaluation on the generated prediction models from all prediction tasks specified above is reported in Tables 1 and 2.

The event log for BPIC 2012⁸ [70] comes from a Dutch financial institute. It stores the information concerning the process of handling either personal loan or overdraft application. It contains 13.087 traces (process instances) and 262.200 events. Generally, the process of handling an application is as follows: Once an application is submitted, some checks are performed. After that, the application is augmented with necessary additional information that is obtained by contacting the client by phone. An offer will be send to the client, if the applicant is eligible. After this offer is received back, it is assessed. The customer will be contacted again if there is a missing information. After that, a final assessment is performed. In this experiment, we consider two prediction task as follows:Both \(R _{\text {E6}}\) and \(R _{\text {E7}}\) can be fed into our tool. For \(R _{\text {E6}}\), we generate a regression model, while for \(R _{\text {E7}}\), we generate a classification model. Different from the BPIC 2013 and BPIC 2015 event logs, there are not so many event attributes in this log. For all of these tasks, we consider two different trace encodings. First, we use the trace encoding that incorporates several available event attributes, namely concept:name and lifecycle:transition. Second, we use the trace encoding that only incorporates the event names, i.e., the values of the attribute concept:name. Thus, intuitively the first encoding considers more information than the second encoding. The evaluation on the generated prediction models from the prediction tasks specified above is shown in Tables 3 and 4.

In BPIC 2015⁹ [71], 5 event logs from 5 Dutch Municipalities are provided. They contain the data of the processes for 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. There are several information available such as the activity name and the resource/person that carried out a certain task/activity. The statistic about the log that we consider is as follows: It has 1409 traces (process instances) and 59681 events.

For this event log, we consider several tasks related to predicting workload-related information (i.e., related to the amount of work/activities need to be done). First, we deal with the task for predicting whether a process of handling an application is complex or not based on the number of the remaining different activities that need to be done. Specifically, we consider a process is complex (or need more attention) if there are still more than 25 different activities need to be done. This task can be specified as follows:where \(\textsf {NumDifRemAct}\) is specified as follows:i.e., \(\textsf {NumDifRemAct}\) counts the number of different values of the attribute ‘activityNameEN’ from the current time point until the end of the process. As the next workload-related prediction task, we specify the task for predicting the number of remaining events/activities as follows:where \(\textsf {RemAct} = {\mathbf {\mathsf{{{count}}}}} (\mathsf {true};~{{{\mathbf {\mathsf{{where}}}}}}~x={\mathsf {curr}}:{\mathsf {last}})\), i.e., \(\textsf {RemAct}\) counts the number of events/activities from the current time point until the end of the process.

Both \(R _{\text {E8}}\) and \(R _{\text {E9}}\) can be fed into our tool. For the former, we generate a classification model, and for the latter, we generate a regression model. For all of these tasks, we consider two different trace encodings. First, we use the trace encoding that incorporates several available event attributes, namely monitoringResource, org:resource, activityNameNL, activityNameEN, question, concept:name. Second, we use the trace encoding that only incorporates the event names, i.e., the values of the attribute concept:name. As before, the first encoding considers more information than the second encoding. The evaluation on the generated prediction models from the prediction tasks specified above is shown in Tables 5 and 6.

In total, our experiments involve 9 different prediction tasks over 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 our language in capturing and specifying the desired prediction tasks that are based on the event logs coming from real-life situation. These experiments also exhibit the applicability of our approach in automatically constructing reliable prediction models based on the given specification. This is supported by the following facts: First, for all prediction tasks that we have considered, by considering different input features and machine learning models, we are able to obtain prediction models that beat the baseline. Moreover, for all prediction tasks that predict categorical values, in our experiments we are always able to get a prediction model that has AUC value greater than 0.5. Recall that AUC = 0.5 indicates the worst classifier that is not better than a random guess. Thus, since we have AUC > 0.5, the prediction models that we generate certainly take into account the given input and predict 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 high AUC values which are ranging between 0.8 and 0.9 (see Tables 1, 5). This score is very close to the AUC value for the best predictor (recall that AUC = 1 indicates the best classifier).

As can be seen from the experiments, the choice of the input features and the machine learning models influence the quality of the prediction model. The result of our experiments also shows that there is no single machine learning model that always outperforms other models on every task. Since our approach does not rely on a particular machine learning model, it justifies that we can simply plug in different supervised machine learning models in order to get different/better performance. In fact, in our experiments, by considering different models we could get different/better prediction quality. Concerning the input features, for each task in our experiments, we intentionally consider two different input encodings. The first one includes many attributes (hence it incorporates many information), and the second one includes only a certain attribute (i.e., it incorporates less information). In general, our common sense would expect that the more information, the better the prediction quality would be. This is simply because we thought that, by having more information, we have a more holistic view over the situation. Although many of our experiment results show this fact, there are several cases where considering less features could give us a better result, e.g., the RMSE score in the experiment with several models on the tasks \(R _{\text {E5}}\), and the scores of several metrics in the experiment \(R _{\text {E8}}\) show this fact (see Tables 2, 5). In fact, this aligns with the typical observation in machine learning. Irrelevant features could decrease the prediction performance because they might introduce noise in the prediction. Although in the learning process a good model should (or will try to) give a very low weight into irrelevant features, the absence of these unrelated features might improve the quality of the prediction. Additionally, in some situation, too many features might cause overfitting, i.e., the model fits the training data very well, but it fails to generalize well while doing prediction with new input data.

Based on the experience from these experiments, time constraint would also be a crucial factor in choosing the model when we would like to apply this approach in practice. Some models require a lot of tuning in order to achieve a good performance (e.g., neural network), while other models do not need many adjustment and able to achieve relatively good performance (e.g., Extra Trees, Random Forest).

Looking at another perspective, our experiments complement various studies in the area of predictive process monitoring in several ways. First, instead of using machine learning models that are typically used in many studies within this area such as Random Forest and Decision Tree (cf. [17, 18, 35, 72]), we also consider other machine learning models that, to the best of our knowledge, are not typically used. For instance, we use Extra Trees, AdaBoost, and Voting Classifier. Thus, we provide a fresh insight on the performance of these machine learning models in predictive process monitoring by using them in various different prediction tasks (e.g., predicting (fine-grained) time-related information, unexpected behaviour). Although this work is not aimed at comparing various machine learning models, as we see from the experiments, in several cases, Extra Trees exhibits similar performance (in terms of accuracy) as Random Forest. There are also some cases where it outperforms the Random Forest (e.g., see the experiment with the task \(R _{\text {E9}}\) in Table 6). In the experiment with the task \(R _{\text {E7}}\), AdaBoost outperforms all other models. Regarding the type of the prediction tasks, we also look into the tasks that are not yet highly explored in the literature within the area of predictive process monitoring. For instance, while there are numerous works on predicting the remaining processing time, to the best of our knowledge, there is no literature exploring a more fine-grained task such as the prediction of the remaining duration of a particular type of event (e.g., predicting the duration of all remaining waiting events). We also consider several workload-related prediction tasks, which is rarely explored in the area of predictive process monitoring.

Concerning the deep learning approach, there have been several studies that explore the usage of deep neural network for predictive process monitoring (cf. [19, 23, 24, 38, 63]). However, they focus on predicting the name of the future activities/events, the next timestamp, and the remaining processing time. In this light, our experiments contribute new insights on exhibiting the usage of deep learning approach in dealing with different prediction tasks other than just those tasks. Although the deep neural network does not always give the best result in all tasks in our experiments, there are several interesting cases where it shows a very good performance. Specifically, in the experiments with the tasks \(R _{\text {E4}}\) and \(R _{\text {E5}}\) (cf. Table 2), where all other models cannot beat the RMSE score of the baseline, the deep neural network comes to the rescue and be the only model that could beat the RMSE score of our baseline.

To sum up, concerning the three questions regarding this experiment that are described in the beginning of this section, the first two questions are positively answered by our experiment. In our experiments of applying our approach over three different real-life event logs and nine different prediction tasks, we have successfully obtained (reliable) prediction models and positively demonstrate the applicability of our approach. Regarding the third question, our experiments show that the choice of the machine learning model and the information that is incorporated in the trace encoding would influence the quality of the prediction.

Concerning RQ1, i.e., “How can a specification-driven mechanism for building prediction models for predictive process monitoring look like?”, as introduced in this work, our specification-driven approach for building prediction models for predictive process monitoring essentially consists of several steps: (i) First, we have to specify the desired prediction tasks by using the specification language that we have introduced in this work; (ii) second, we create the corresponding prediction models based on the given specification by using the approach that is explained in Sect. 4. (iii) Finally, once the prediction models are created, we can use the constructed prediction models for predicting the future information of a running process. Notice that this approach requires a mechanism to express various desired prediction tasks and also a mechanism to process the given specification so as to build the corresponding prediction models. In this work, we provide all of these and we have also applied this approach into some case studies based on real-life data (cf. Sect. 6).

Regarding RQ2, i.e., “How can an expressive specification language that allows us to express various desired prediction tasks, and at the same time enables us to automatically create the corresponding prediction model from the given specification, look like? Additionally, can that language allow us to specify complex expressions involving data, arithmetic operations and aggregate functions?”, as explained in Sect. 3, the specification of a prediction task can be expressed by using an analytic rule, which is introduced in this work. Essentially, an analytic rule consists of several conditional-target expressions and it allows us to specify how we want to map each partial business processes execution information into the expected predicted information. As can be seen in Sects. 4 and 6, a specification provided in this language can be used to train a classification/regression model that can be used as the prediction model. Additionally, as a part of analytic rules, we introduce an FOL-based language called FOE. As can be seen from Sects. 3 and 5, FOE allows us to specify complex expression involving data, arithmetic operations and aggregate functions.

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

We now elaborate why our language fulfils all requirements in Sect. 3.2. For the first requirement, since the target expression in the analytic rules can be either numeric or non-numeric expressions, it is easy to see that the first requirement is fulfilled. Various examples of prediction tasks specification in Sect. 5 also confirm this fact. Our experiments in Sect. 6 also exhibit several case studies where the predicted information is either numeric or non-numeric values.

Concerning the second requirement, our procedure in Sect. 4 and our experiments in Sect. 6 confirm the fact that we can have a mechanism for automatically building the corresponding prediction model from the given specification in our language.

Finally, regarding the requirements 3, 4, and 5, our language formalism in Sect. 3 and our extensive showcases in Sect. 5 exhibit the fact that our language fulfils these requirements. Specifically, we are able to specify complex expressions over sequence of events by also involving the events data, arithmetic expressions as well as aggregate functions. Additionally, from our various showcases, we can also see that our language allows us to specify the target information to be predicted where we might also have to specify the way to obtain a certain value and might involve some arithmetic expression.

The usability of the language can only be measured by outcomes of user studies which are beyond the scope of this work. Obviously, it is interesting to do this; therefore, we consider doing a user study as one of our future directions. Although this is one of the limitations of our current work, some insights regarding this aspect can be drawn from previous studies. Taking the success story from the works on domain-specific languages (DSLs) [39], by providing a language in which the development is driven by or tailored to a particular domain/area, DSL offers substantial gains in expressiveness and ease of use compared to general purpose language in their domain of application [39]. In general, DSLs were developed because they can offer domain-specificity in better ways. In this light, our language has a similar situation in the sense that its development is highly driven by a particular area, namely predictive process monitoring. Due to this fact, we expect that similar benefits concerning this aspect could be obtained.

Another aspect of usability concerns learnability. According to [39], one way to design a DSL is to build it based on an existing language. A possible benefit of this approach is familiarity for the users. Due to this familiarity, it is expected that the users, who are familiar with the corresponding existing language, could easily learn and use it. In this light, our FOE language follows this approach. It is actually based on a well-known logic-based language namely First-Order Logic (FOL). Furthermore, choosing FOL as the basis of the language also gives us another advantage since it is more well known compared to other more advanced logic-based languages, e.g., Linear Temporal Logic (LTL). This is the case because typically FOL is a part of many foundational courses; hence, it is taught to a wider audience than other more advanced logics. In general, since this language is a logic-based language, a user with pre-trained knowledge in logic should be able to use the language. Looking at another perspective, the development of our language is also highly driven by the typical structure of XES event log. Since XES is a typical standard format for event logs and widely known in the area of process mining, we expect that this fact improves the familiarity for the users and eases the adoption/usage by the users who are familiar with the XES standard (which should be the typical users in this area). A possible direction to improve the usability would be to study advanced visual techniques and explore the possibility of having visual support (e.g., graphical notations) for creating the specification. Having visual support is a way that has been observed in the area of DSL as a way to improve usability [26, 44]. This kind of approach also has been seen in the literature (cf. [47, 48]).

According to [44], the effectiveness of communication is measured by the match between the intended message and the received message (information transmitted). In this light, the presence of the formal semantics of our language prevents ambiguous interpretation that could cause a mismatch between the intended and the understood meaning. In the end, the presence of this language could be useful for BP analysts to precisely specify the desired prediction tasks, and this is important in order to have suitable prediction services. This language could also be an effective means for BP analysts to communicate the desired prediction tasks unambiguously.

This work focuses on the problem of predicting the future information of a single running process based on the current information of that corresponding running process. In practice, there could be several processes running concurrently. Hence, it is absolutely interesting to extend the work further so as to consider the prediction problems on concurrently running processes. This extension would involve the extension of the language itself. For instance, the language should be able to specify some patterns over multiple running processes. Additionally, it should be able to express the desired predicted information or the way to compute the desired predicted information, and it might involve the aggregation of information over multiple running processes. Consequently, the mechanism for building the corresponding prediction model needs to be adjusted.

Our experiments (cf. Sect. 6) show a possible instantiation of our generic approach in creating prediction services. In this case we predict the future information of a running process by only considering the information from a single running process. However, in practice, other processes that are concurrently running might affect the execution of other processes. For instance, if there are so many processes running together and there are not enough employees for handling all processes simultaneously, some processes might need to wait. Hence, when we predict the remaining duration of waiting events, the current workload information might be a factor that need to be considered and ideally these information should be incorporated in the prediction. One possibility to overcome this limitation is to use the trace encoding function that incorporates the information related to the processes that are concurrently running. For instance, we can make an encoding function that extracts relevant information from all processes that are concurrently running, and use them as the input features. Such information could be the number of employees that are actively handling some processes, the number of available resources/employees, the number of processes of a certain type that are currently running, etc.

This kind of machine learning-based technique performs the prediction based on the observable information. Thus, if the information to be predicted depends on some unobservable factors, the quality of the prediction might be decreasing. Therefore, in practice, all factors that highly influence the information to be predicted should be incorporated as much as possible. Furthermore, the prediction model is only built based on the historical information about the previously running processes and neglects the possibility of the existence of the domain knowledge (e.g., some organizational rules) that might influence the prediction. In some sense, it (implicitly) assumes that the domain knowledge is already incorporated in those historical data that captures the processes execution in the past. Obviously, it is then interesting to develop further the technique so as to incorporate the existing domain knowledge in the creation of the prediction model with the aim of enhancing the prediction quality. Looking at another perspective, since the prediction model is only built based on the historical data of the past processes execution, this approach 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 running process, we might affect the future of the process itself, and hence, we might reduce the preciseness of the prediction. For instance, when it is predicted that a particular process would exhibit an unexpected behaviour, we might be eager to prevent it by closely watching the process in order to prevent that unexpected behaviour. In the end, that unexpected behaviour might not be happened due to our preventive actions, and hence, the prediction is not happened. On the other hand, if we predict that a particular process will run normally, we might put less attention than expected into that process, and hence, the unexpected behaviour might occur. Therefore, knowing the (prediction of the) future might not always be good for this case. This also indicates that a certain care need to be done while using the predicted information.