Process Discovery Techniques Recommendation Framework

Abstract

In a competitive environment, organizations need to continuously understand, analyze and improve the behavior of processes to maintain their position in the market. Process mining is a set of techniques that allows organizations to have an X-ray view of their processes by extracting process related knowledge from the information recorded in today’s process aware information systems such as ‘Enterprise Resource Planning’ systems, ‘Business Process Management’ systems, ‘Supply Chain Management’ systems, etc. One of the major categories of process mining techniques is the process of discovery. This later allows for automatically constructing process models just from the information stored in the system representing the real behavior of the process discovered. Many process discovery algorithms have been proposed today which made users and businesses, in front of many techniques, unable to choose or decide the appropriate mining algorithm for their business processes. Moreover, existing evaluation and recommendation frameworks have several important drawbacks. This paper proposes a new framework for recommending the most suitable process discovery technique to a given process taking into consideration the limitations of existing frameworks.

1. Introduction

Process mining is a recent set of techniques that provide a strong bridge between business intelligence (BI) and business process management (BPM) by combining process models and event data, forming a novel form of process-driven analytics. Moreover, process mining enables and strengthens various business process improvement (BPI) approaches such as TQM, Six-sigma, CPI, and others, where processes are diagnosed to explore possible improvements [1].

Modern information systems, including workflow management systems (WFM), enterprise resource planning (ERP) systems, customer relationship management (CRM) systems, supply chain management (SCM) systems, and business-to-business (B2B) systems, store business-related events in event logs [2]. These event logs typically contain information about executed activities within the enterprise (i.e., process instances), the time of activity execution, the people, machines, or systems involved, and other relevant data. Process mining extracts knowledge from these event logs to automatically build a representation of the current execution of business processes within an enterprise. The aim is to identify incorrect executions, bottlenecks, and other problems that hinder the organization from achieving its strategic goals and vision [3].

Process mining utilizes this event data to extract process-related information, and three major classes of process mining techniques can be employed for different purposes, as illustrated in Figure 1: process discovery, conformance checking, and process enhancement or performance analysis [4]. Process discovery, considered the most important process mining technique, takes an event log as input and automatically constructs a process model. Conformance checking compares an existing process model with the event log of the same process model to investigate whether the organization’s actual operations conform to the defined process model. Process enhancement aims to improve or extend the existing process model based on information obtained from the discovered process model or from the event log. In this thesis, our focus is on the control-flow perspective of process discovery, which entails constructing process models.

1.1. Event Log

Table 1. An example of an event log used for process mining.

Case Id	Event Id	Activity	Timestamp	Resource	….
Q521-QZR	N0060	Purchase Request	5/15/2022 16:35	Hind	….
	N0070	Purchase Approval	5/15/2022 16:40	Safae	….
	N0080	Approval Verification	5/16/2022 16:40	Soukaina	….
	N0090	Purchase Finalization	5/16/2022 17:42	Younes	….
	N0100	Purchase Order	5/16/2022 17:30	Moui	….
	N0110	Purchase Reception and verification	6/13/2022 10:55	Mohammed	….
Q543-289	N0060	Purchase Request	5/15/2022 10:38	Hind	….
	N0070	Purchase Approval	5/15/2022 11:41	Safae	….
	N0080	Approval Verification	5/15/2022 12:42	Soukaina	….
	N0060	Purchase Request	5/15/2022 13:42	Hind	….
	N0080	Approval Verification	5/15/2022 15:42	Soukaina	….
	N0090	Purchase Finalization	5/15/2022 16:43	Younes	….
	N0100	Purchase Order	5/15/2022 16:45	Moui	….
	N0110	Purchase Reception and verification	6/15/2022 11:45	Mohammed	….

provides an example of an event log for a purchasing process, which is utilized for process mining. Each row in the table represents an individual event, while each column represents an attribute associated with that event. Events are linked to specific cases, and in Table 1, events are grouped by case and arranged chronologically. The first recorded event corresponds to case Q521-QZR, indicating the execution of the Purchase Request activity performed by the employee named Hind on 15 May 2022. Additional attributes, such as entered data, costs, etc., can also be utilized for process mining. It is essential for each event to have a unique identifier and be associated with a case. Furthermore, events should be sorted, typically using timestamps to establish a chronological order. The timestamps displayed in Table 1 represent the start time of the corresponding activity’s execution. Timestamps indicating the completion or pause of an activity’s execution can also be recorded and utilized for process mining.

This event log contains information about three cases (i.e., workflow instances). The log demonstrates that for cases 1 and 2, the tasks Request, Approve, Verify, Finalize, Order, and Receive and Verify have been executed. Each case begins with the execution of the Purchase Request activity and concludes with the execution of Receive and Verify.

The event data presented in Table 1 contains typical information found in an event log. In process mining, the first class of analysis, known as process discovery, can utilize the case ID and event ID from Table 1 to create an accurate process model that represents the purchasing process described in this example. This model is depicted in Figure 2, constructed using the information provided in Table 1. The process model shown in Figure 2 is represented with Petri Net, a process modeling language [5].

Conformance checking techniques involve comparing the process model derived from the event data in Table 1 with an existing or predefined model. This comparison helps identify inconsistencies, deviations, and other issues that may arise. Additionally, attributes like timestamps associated with the events can be used in process enhancement to investigate the performance of the process.

1.2. Process Discovery Techniques Overview

Several process discovery algorithms have been developed and applied successfully. One of the big differences between existing discovery algorithms is the ability to discover the complex constructs of a process model. These complex constructs are short loops, invisible tasks, duplicate tasks, and non-free choice constructs. One of the major process discovery techniques is the $\mathsf{\alpha }-$algorithm [6]. This algorithm produces a workflow net based on the causal relationships observed between tasks, but without short loops, invisible tasks, non-free choice constructs, and duplicate tasks. Therefore, several extensions have been presented so far to tackle these limitations. The Alpha + algorithm was first introduced to extend the Alpha algorithm to short loop mining [7], while Alpha ++ was developed to extend the Alpha algorithm to non-free choice constructs [8], Alpha # was developed to mine invisible tasks [9,10], and Alpha $ was developed to handle invisible tasks involved in non-free choice constructs [11]. However, none of these extensions can detect all types of characteristics that can exist in an event log. The Heuristics Miner [12] derives ordering relations based on their frequencies and returns a net. The Heuristics Miner algorithm is robust for invisible tasks but cannot handle duplicate tasks and non-free choice constructs. The Inductive Miner returns a process tree and guarantees sound models that other algorithms cannot guarantee [13]. It is capable of mining invisible tasks but cannot discover duplicate tasks or non-free choice constructs. The Region-based algorithm can mine non-free choice constructs but cannot handle invisible tasks and duplicate tasks [14]. The Genetic Mining algorithm is the only existing algorithm that can deal with most of the common constructs. Nevertheless, it requires many parameters and does not provide the correct output in a restricted time.

2. Literature Review

Several papers have developed frameworks to evaluate or recommend process discovery techniques. The authors in [15] have written an important and well-founded article on building a benchmark framework for process mining algorithms. They introduced two methodologies to evaluate process discovery techniques. The first strategy is based on evaluation using metrics, and the second one is a machine learning strategy. In [16], the authors extended this work by empirically evaluating process discovery techniques using artificial and real-life datasets, as well as different similarity measures. Although this framework allows users and businesses to select the most suitable process mining algorithm for a given event log, empirical evaluation can be time-consuming. It is only after performing experiments on all existing mining algorithms that the best algorithm can be determined. Notably, remarkable work was presented in [17], where the issue of spending a long time on experiments to select the appropriate mining algorithm was considered. Their proposed framework is based on a learning step and a recommendation step. In the first phase, a regression model is built based on features extracted from high-quality selected reference models and the similarities between the reference models and the mined models. Using this regression model, along with features extracted from other models, similarities between reference models and mined models are predicted without the need for experiments. While the results obtained by applying this framework are accurate and attractive, there is a weakness in this concept. The presented methodology heavily relies on reference models, which are usually not available in the practical world. In [18], the authors developed a framework and a tool for recommending control flow algorithms. Based on features extracted from event logs and prediction models built from experiments, top-K control-flow miners are recommended. Although this work takes event logs as input instead of reference models, addressing the limitation mentioned in [17], the study can be criticized for requiring experiments to build prediction models before recommending top-K mining algorithms, making it time-consuming once again. The proposed systems would have been more interesting if the authors had based their framework on event logs and had reduced the number of experiments required to decide the mining algorithm suitable for a given event log. [19] proposed an approach to recommend a process discovery algorithm based solely on the classification of event logs, but they only conceptualized the idea. In [20], a classification-based framework was proposed to evaluate the quality of process discovery algorithms. The starting point of this framework is the generation of random samples of process models artificially from a specified population of processes. For each model, a training log with fitting traces and a test log with both fitting and non-fitting traces are generated. The quality of process discovery algorithms is assessed based on their capability to correctly classify a trace representing real process behavior as fitting and a trace representing non-related behavior to the process as non-fitting. However, similar to other methodologies, it is an empirical framework. Users need to conduct experiments on all existing discovery techniques before they can decide the best algorithm based on quality performance.

3. Process Discovery Recommendation Framework

Existing evaluation and recommendation frameworks allow users to choose the best algorithm to a given process by comparing the performance of existing discovery algorithms empirically. While in fact, recommending a process discovery technique for a given process log based on empirical assessment is time and resource consuming. From a business perspective, practically one cannot perform experiments on all algorithms each time to decide the most suitable algorithm at the end. In addition, some recommendation frameworks are based on reference models. There is a strong possibility that reference models are not available in the practical world.

The development of a recommendation framework for process discovery algorithms is strongly needed due to the abundance of process discovery algorithms and due to the fact that each algorithm has different characteristics and ability, and specific limitations. One of the big differences between existing discovery algorithms is the ability to discover the standards and complex constructs of a process model which are short loops, invisible tasks, non-free choice constructs, non-free choice involved in invisible tasks, and duplicate tasks. There is currently no algorithm that can handle all of these structures in a restricted time. For instance, the Inductive Miner algorithm [13] is robust for invisible tasks, but it cannot handle duplicate tasks and non-free choice constructs. Another example is the Region-based algorithm [14], which is capable of mining some non-free choice constructs but cannot handle invisible and duplicate tasks. The other algorithms have similar problems. Each algorithm has an advantage in mining specific structures but at the same time there is a restriction in mining other constructs.

In our previous work [21], we proposed a conceptual idea for a new framework that recommends or selects a suitable mining algorithm for a given event log. In this paper, we provide detailed explanations of the idea and its evaluation. The framework involves extracting process model constructs from the event log without actually discovering a model. Essentially, it investigates the log for short loops, invisible tasks, non-free choice constructs, non-free choice involved in invisible tasks, and duplicate tasks. By utilizing a knowledge database containing information about the capability of each algorithm in discovering these structures, one can determine the candidate techniques suitable for the given event log. The knowledge database can be constructed using existing comparison and evaluation frameworks that assess the ability of process discovery algorithms in mining the aforementioned constructs.

In the proposed framework, no reference model or empirical evaluation is required to recommend a process discovery technique. If the constructs extraction stage results in numerous candidate algorithms, other metrics from the knowledge database, such as mining time and soundness, gathered from research papers, will be used to reduce the candidate algorithms. For example, if the structures extracted from the event logs reveal the presence of duplicate tasks, algorithms like the Alpha algorithm and Inductive Miner will be eliminated due to their inability to discover duplicate tasks. Both the Alpha* algorithm and Genetic Miner can handle duplicate tasks and are considered as candidates. However, based on the mining time metric in the knowledge database, the Genetic algorithm takes significantly longer compared to the Alpha* algorithm to discover a model from an event log with duplicate tasks. Therefore, the recommended discovery algorithm for mining such event logs, without any empirical evaluation, is the Alpha* algorithm.

The overall framework is illustrated in Figure 3.

3.1. Constructs

The most relevant constructs typically discovered by process discovery algorithms are sequence, exclusive choice, inclusive choice, parallelism, loops, invisible tasks, non-free choice, and duplicate tasks.

• Sequence: Certain process activities need to be sequentially executed.
• Exclusive choice: Certain process parts of the process are mutually exclusive. In several notations, this is known as XOR split/join.
• Parallelism: Certain branches are “parallel”, indicating that the activities of a first part of the model are executed simultaneously with the activities of a second part of the model. In several notations, this is known as AND split/join.
• Inclusive choice: a choice needs to be made on which part(s) of the process that follow need to be performed, when reaching given points of the process. Inclusive choice is different from exclusive choice because multiple parts can be executed in parallel and different from the parallelism construct since not every part that follows the reached point needs to be executed. In several notations, this is known as OR split/join.
• Loop: The execution of certain parts of the process can be sequentially repeated multiple times.
• Invisible tasks: Certain transitions are incorporated into the model for a process-routing purpose. For instance, combined with exclusive choices, invisible tasks allow the execution of some parts of the process to be skipped.
• Duplicate activities: Certain activities share the same name but placed in two or more nodes in the process model.
• Non-free choice: when the choice of one or multiple branches is influenced by a choice that occurred before.

We classify these constructs into standard constructs, which can be discovered by all existing process discovery algorithms, and complex constructs, which cannot be mined by all algorithms. Our focus in this work is on the complex constructs, as the ability of each algorithm differs in terms of mining these constructs. We are not concerned with the standard constructs.

3.2. Complex Construct Detection

In this section, we will present the equations used to detect short loops, invisible tasks, non-free choice, and non-free choice involved in invisible tasks in a given event log. The equations for detecting these complex constructs are based on the extensions of the alpha miner. Compared to other algorithms, the extensions of the alpha miner, namely alpha++, alpha$, and alpha#, address each construct separately. These extensions handle various constructs such as short loops, all types of invisible tasks, and non-free choice constructs.

3.2.1. Basic Ordering Relations

In the $\mathsf{\alpha }$ algorithm, which serves as the foundation for the $\mathsf{\alpha }-$extensions algorithms, six fundamental relations were defined: ${>}_{\mathrm{L}}$, ${∆}_{\mathrm{L}}$, ${◊}_{\mathrm{L}}$, ${\to }_{\mathrm{L}}$, ${\Vert }_{\mathrm{L}}$, and ${\ne }_{\mathrm{L}}$. Therefore, we briefly explain each of these relations:

• Relation ${>}_{\mathrm{L}}$: This relation signifies that two activities can be executed successively, one after the other. It indicates a direct succession between the activities.
• Relation ${∆}_{\mathrm{L}}$: This relation represents a loop with a length-two structure, such as “aba.” It is also used to differentiate between length-2-loops and parallel routing.
• Relation ${◊}_{\mathrm{L}}$: This relation indicates a two-way loop with a length of two. It means that two activities have the ${∆}_{\mathrm{L}}$ relation between them, for example, “aba” or “bab.”
• Relation ${\to }_{\mathrm{L}}$: This relation denotes a direct causal relationship between two activities, indicating that one activity is a direct cause or prerequisite for the other.
• Relation ‖_L: The ‖_L relation signifies that activities can be executed concurrently, meaning they can happen simultaneously or in parallel. For instance, “ab” or “ba” can be executed concurrently.
• Relation ${\ne }_{\mathrm{L}}$: This relation implies that two activities should never directly follow each other. There should always be other activities or conditions between them.

These defined relations in the $\mathsf{\alpha }$ algorithm are used to describe different types of relationships and structures within a process model. They play a crucial role in understanding and analyzing the behavior and dependencies of activities in a given process.

Definition 1. 

(Basic Ordering relations). Let $A$ be $a$ set of activities, $L$ be an event $log over A$, $a$ and $b$ be two activities in $A$, the relation defined in $\alpha$ and ${\alpha }^{+}$algorithms as follows:

$$a{>}_{L}b \iff \exists \sigma =t_1{t}_2\dots t_n\in L, i\in 1,\dots ,n-1: t_i=a\wedge t_{i+1}=b,$$

(1)

$$a{ ∆}_L b \iff \exists \sigma =t_1{t}_2\dots t_n\in L, i\in 1,\dots ,n-2: t_i=t_{i+2}=a\wedge t_{i+1}=b,$$

(2)

$$a{ ◊}_L b \iff \left(a{ ∆}_L b\right) \vee \left(b{ ∆}_L a\right),$$

(3)

$$a{\to }_{L}b \iff \left(\left(a{>}_{L}b\right)\wedge \left(b{\ngtr }_{L}a\right)\right)\vee \left(a{ ◊}_L b\right),$$

(4)

$$a {\Vert }_{L}b \iff \left(a{>}_{L}b\right)\wedge \left(b{>}_{L}a\right)\wedge \left(b{◊ }_{L}a\right), and$$

(5)

$$a{\ne }_{L}b \iff \left(\left(a{\ngtr }_{L}b\right)\wedge \left(b{\ngtr }_{L}a\right).\right)$$

(6)

3.2.2. Short Loops Detection

The relation that can detect loops of length two is defined in the basic ordering relations in Definition 1 as ${∆}_{\mathrm{L}}$. The relation that can detect loops of length-one loop is defined using the relation of direct succession as follows:

$$a{>}_{L}a \iff \exists \sigma =t_1{t}_2\dots t_n\in L, i\in 1,\dots ,n-1: t_i=a \wedge { t}_{i+1}=a$$

(7)

Several constructs and sound models cannot correctly be discovered with the existence of a loop of length-one. Therefore, most of the algorithms focus on the pre- and post-processing steps of process mining as a solution to tackle length-one loops. Similarly, our framework starts by investigating the existence of a loop of length-one in the event log using the direct succession relation ${>}_{\mathrm{L}}$. Once it is detected, the framework records the existence of loop of length-one, removes it from the event log and then investigates the rest of the constructs in the new event log defined in Definition 2.

Definition 2. 

(loop-1-length free event log). Let $A$ be a set of activities, $L$ be an event $log over A,$ $a$ be an activity from $A$, and $L1L$ be the set of loops of length-one, and the new $event log A’$ free of loop-1-length is defined as follows:

$$A_{log}=\{a\in A{|\exists }_{\mathsf{\sigma }\in \mathrm{L}}[t\in \sigma ]\},$$

(8)

$$L1L = \{a\in A|{\exists }_{\sigma =t_1{t}_2\dots t_n\in L; i\in \mathrm{2,3},..,n}{ a=t}_i\wedge a=t_{i+1} \vee { a=t}_{i-1}\wedge a=t_i,$$

(9)

$$A^{\prime }=A_{log}\backslash L1L.$$

(10)

3.2.3. Invisible Tasks Detection

${\mathsf{\alpha }}^{\#}$ algorithm introduced the mendacious dependency ${⇝}_{\mathrm{L}}$ to reflect invisible tasks of type SKIP, REDO, and SWITCH. The relation ${⇝}_{\mathrm{L}}$ can be used to detect the existence of invisible tasks in the event log and to discover them in a process model. The mendacious dependency ${⇝}_{\mathrm{L}}$ defined in ${\mathsf{\alpha }}^{\#}$ algorithm is defined in Definition 3.

Definition 3. 

(mendacious dependency associated with invisible tasks). Let $A$ be a set of activities, $L$ be an event log over $A$, and $a$, $b$be two activities from $A$. The mendacious dependency associated with invisible tasks is defined as follows:

$$a{⇝}_{L}b \iff \left(\mathrm{a}{\to }_{L}b\right) \wedge \exists x,y\in A: \left(\mathrm{a}{\to }_{L}x\right) \wedge \left(\mathrm{y}{\to }_{L}b\right) \wedge \left(y{\ngtr }_{L}x\right) \wedge (x{\nparallel }_{L}b)\wedge \left(a{\nparallel }_{L}y\right)$$

(11)

This relation is capable of detecting invisible tasks of type Short-Skip, Long-Skip, Short-Redo, and Long-Redo. The basic idea for detecting these types is illustrated in figure Task $t$ in Figure 4 which represents one such invisible task. We have identified four types of invisible tasks: Short-Skip, Long-Skip, Short-Redo, and Long-Redo:

• Short-Skip: Task $t$ is of Short-Skip type if tasks $x$ and $y$ are equal. In a sequential workflow, this type of invisible task can be detected by the relation ${⇝}_{\mathrm{L}}$.
• Long-Skip: Task $t$ is of Long-Skip type if $x$ reaches $y$. Again, in a sequential workflow, this type of invisible task can be detected by the relation ${⇝}_{\mathrm{L}}$.
• Short-Redo: Task $t$ is of Short-Redo type if tasks $a$ and $b$ are equivalent. In a sequential workflow, this type of invisible task can be detected by the relation ${⇝}_{\mathrm{L}}$.
• Long-Redo: Task $t$ is of Long-Redo type if $b$ reaches $a$. Once again, in a sequential workflow, this type of invisible task can be detected by the relation ${⇝}_{\mathrm{L}}.$
• Switch: If none of the above conditions are met, task $\mathrm{t}$ is considered a Switch type.

However, the relation ${⇝}_{\mathrm{L}}$ is incapable of detecting these types of invisible tasks when they are executed in parallel with other tasks. To address this limitation, the ${\mathsf{\alpha }}^{\mathrm{\$}}$ algorithm introduced new definitions to detect invisible tasks of types Short-Skip, Long-Skip, Short-Redo, and Long-Redo even when they are executed concurrently with other tasks. The algorithm improved the detection of these invisible tasks by considering their interactions and dependencies in parallel workflows.

${\mathsf{\alpha }}^{\mathrm{\$}}$ algorithm introduced the Between-set to be used to improve the mendacious dependency. The Between-set is defined in Definition 4 and refers to the tasks occurring between two tasks. If the two tasks are the endpoints of a concurrent construct, the Between-Set is the set of tasks in the parallel branches. For instance, in Figure 5, $\mathrm{B}\mathrm{e}\mathrm{t}\mathrm{w}\mathrm{e}\mathrm{e}\mathrm{n}(\mathrm{L},\mathrm{a},\mathrm{b})=\{\mathrm{x},\mathrm{y},\mathrm{c}\}.$

Definition 4. 

(Between-Set). Let $A$ be a set of activities, $L$ be an event$log over A$, $a$ and $b$ be two activities from $A, \sigma$ be a trace that belongs to$L$, and the Between-Set of $a,b$, i.e., $Between\left(L, a,b\right)$, is defined as follows:

$$Between\left(\sigma , a,b\right)=\left\{{\sigma }_k\right|{\exists }_{1\le i<j\le m}\left({\sigma }_i=a\wedge {\sigma }_j=b\right)\wedge i<k<j\wedge {\nexists }_{i<l<j}\left({\sigma }_l=a\vee {\sigma }_l=b\right))\},$$

(12)

$$⌐Between\left(\sigma , a,b\right)=\left\{{\sigma }_k|1\le k\le m\right\} \setminus Between\left(\sigma , a,b\right), and$$

(13)

$$Between\left(L, a,b\right)={\cup }_{\sigma \in L}Between(\sigma , a,b)\setminus {\cup }_{\sigma \in L} ⌐Between\left(\sigma , a,b\right).$$

(14)

The mendacious dependency ${⇝}_{\mathrm{L}}$ is improved as ${\hookrightarrow }_{\mathrm{L}}$ and defined in Definition 5. the improved mendacious dependency ${\hookrightarrow }_{\mathrm{L}}$ is capable of detecting the types of invisibles tasks when they are involved in a concurrent construct. The basic idea of ${\hookrightarrow }_{\mathrm{L}}$ is illustrated in Figure 5. Task $\mathrm{t}$ in Figure 5 represents an invisible task in a parallel branch. Similar to Figure 4, if the two tasks $\mathrm{x}$ and $\mathrm{y}$ are equal, $\mathrm{t}$ is of Short-Skip type. If $\mathrm{x}$ reaches $\mathrm{y}$, $\mathrm{t}$ is of Long-Skip type. If the two tasks $\mathrm{a}$ and $\mathrm{b}$ are equivalent, $\mathrm{t}$ is of Short-Redo type. If $\mathrm{b}$ reaches $\mathrm{a}$, $\mathrm{t}$ is of type Long-redo type. Otherwise, $\mathrm{t}$ is of type Switch.

Definition 5. 

(Mendacious dependencies associated with invisible tasks in parallel). Let $A$ be a set of activities, $L$ be an event $log over A$, $a$ and $b$ be two activities from $A$, $\sigma$ be a trace that belongs to $L$, and the mendacious dependency $a{\hookrightarrow }_{L}b$ associated with invisible tasks involved in a parallel construct is defined as follows:

$$\begin{gathered} a{\ge }_{L}b \iff {\exists }_{\mathit{x},\mathit{y}\in \mathit{A}}Between \left(L,x,y\right)\subset Between \left(L,a,b\right) \wedge \forall m \\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\in \left(Between\left(L, a,b\right)\setminus \left(Between\left(L,x,y\right)\cup \left\{x,y\right\}\right)\right) \forall n \\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\in Between \left(L,x,y\right){:\left(m {\Vert }_L n\right) \wedge \exists }_{\sigma \in L} Between \left(\sigma , a,b\right) \subseteq \left(Between\left(L, a,b\right)\setminus \left\{x,y\right\}\right), \end{gathered}$$

(15)

$$a{\rightrightarrows }_{L}b\iff \left(\left(a{\ge }_{L}b\right)\wedge \left(b{\ngeqq }_{L}a\right)\right)\vee (a{◊}_{L}b),and$$

(16)

$$a{\hookrightarrow }_{L}b\iff \exists x,y\in A:\left(\mathrm{a}{\to }_{L}x\right) \wedge \left(\mathrm{y}{\to }_{L}b\right)\wedge \left(x{\nparallel }_{L}b\right)\wedge \left(y{\nparallel }_{L}a\right)\wedge \left(a{\rightrightarrows }_{L}b\right)\wedge \left(y{\ngeqq }_{L}x\right).$$

(17)

The mendacious dependency ${⇝}_{\mathrm{L}}$ can detect invisible tasks of types Skip, Redo, and Switch involved in a sequential constructs using one relation. The dependency ${⇝}_{\mathrm{L}}$ can be seen as a combined relation that can detect invisible tasks of type Short-Skip, Long-Skip, Short-Redo, and Long-Redo involved in a sequential construct. Similarly, the improved one ${\hookrightarrow }_{\mathrm{L}}$ can discover invisible tasks of types Skip, Redo, and Switch involved in a parallel construct using one relation. The dependency ${\hookrightarrow }_{\mathrm{L}}$ can be seen as a combined relation that can detect invisible tasks of types Short-Skip, Long-Skip, Short-Redo, and Long-Redo involved in a parallel construct. In fact, there are process discovery algorithms which can detect certain types of invisible tasks while they cannot detect the other types. For instance, the ETM algorithm [22] is capable of discovering invisible tasks of types Short-Skip and Long-Skip involved in a sequential construct whereas it is incapable of discovering those of types Short-Redo and long redo in sequence, and Short-Skip and Long-Skip in parallel and switch. Similarly, the Heuristic Miner [12] is proven to be able to detect invisible tasks. However, it cannot detect those of types Short-Redo in a sequence construct and Short-Skip in a parallel construct. Hence, even if the Heuristic Miner is proven to discover invisible tasks, if the existence of invisible task of type Short-Skip in a parallel construct is detected in the log, the Heuristic Miner will not be recommended. The dependencies ${⇝}_{\mathrm{L}}$ and ${\hookrightarrow }_{\mathrm{L}}$ do not detect the types of invisible tasks separately. Therefore, we need to define a relation for each type of invisible task.

In our framework, we define a relation for each type of invisible task by splitting the two relations ${⇝}_{\mathrm{L}}$ and ${\hookrightarrow }_{\mathrm{L}}$ and based on the information that if the two tasks $\mathrm{x}$ and $\mathrm{y}$ are equal, $\mathrm{t}$ is of the Short-Skip type. If $\mathrm{x}$ reaches $\mathrm{y}$, $\mathrm{t}$ is of the Long-Skip type. If the two tasks $\mathrm{a}$ and $\mathrm{b}$ are equivalent, $\mathrm{t}$ is of the Short-Redo type. If $\mathrm{b}$ reaches $\mathrm{a}$, $\mathrm{t}$ is of the Long-redo type. Otherwise, $\mathrm{t}$ is of the Switch type. The relations detecting invisible tasks of types Short-Skip, Long-Skip, Short-Redo, and Long-Redo in a sequential construct is defined in Definition 7, Definition 8, Definition 9, and Definition 10, respectively. The relations detecting those involved in a parallel construct are defined in Definition 11, Definition 12, Definition 13, and Definition 14, respectively.

Before that we define two relations that will be used in the new definitions for detecting each type of invisible task separately. These two relations are ${\gg }_{\mathrm{L}}$ and ${⊱}_{\mathrm{L}}$. They were introduced in the ${\mathsf{\alpha }}^{++}$ algorithm. Relation ${\gg }_{\mathrm{L}}$ represents the case where one task can only be indirectly followed by another task, while relation ${⊱}_{\mathrm{L}}$ refers to the situation when one task can be followed by another task either directly or indirectly. $\mathrm{A}{\gg }_{\mathrm{L}}\mathrm{b}$ means that task $\mathrm{b}$ is reachable from task $\mathrm{a}$ indirectly, and $\mathrm{a}{⊱}_{\mathrm{L}}\mathrm{b}$ indicates that task $\mathrm{b}$ is reachable from task $\mathrm{a}$ directly or indirectly. Relations ${\gg }_{\mathrm{L}}$ and ${⊱}_{\mathrm{L}}$ are defined in Definition 6.

Definition 6. 

(Reachable dependencies). Let $A$ be a set of tasks, $L$ be an event log over $A$, $a, b$ two tasks from $A$, and the dependency $a {\gg }_{L}b$ reflects the indirect reachable dependency between the two tasks $a$ and $b. a{⊱}_{L}b$ reflects the indirect or direct reachable dependency between the two tasks $a$ and $b$. These two relations are defined as follows:

$$a{\gg }_{L}b \iff \exists \sigma =t_1{t}_2\dots t_n\wedge i,j\in 1,\dots ,n:i<j\wedge t_i=a\wedge t_j=b \wedge \forall k\in \left[i+1,\dots ,j-1\right]: t_k\ne a\wedge t_k\ne b$$

(18)

$$a{⊱}_{L}b \iff \left(a{\to }_{L}b\right)\vee (a{\gg }_{L}b)$$

(19)

Definition 7. 

(Short-Skip in sequence). Let $A$ be a set of tasks, $L$ be an event log over $A$, $a, b$ two tasks from $A$, and the dependency ${a⇢}_L^{sss}b$ reflects the mendacious dependency associated with invisible tasks of type Short-Skip in Sequence and is defined as follows:

$${a⇢}_L^{sss}b \iff (a{\to }_{L}b )\wedge \exists x\in A: (a{\to }_{L}x)\wedge (x{\to }_{L}b)\wedge (x{\nparallel }_{w}b)\wedge (a{\nparallel }_{w}x)\wedge (x{\ngtr }_{L}x).$$

(20)

Definition 8. 

(Short-Redo in sequence). Let $A$ be a set of tasks, $L$be an event log over $A$, and $x$, $y$ two tasks from $A$. The dependency ${x⇢}_L^{srs}y$ represents the mendacious dependency associated with invisible tasks of type Short Redo in Sequence and is defined as follows:

$$\mathrm{y}{⇢}_L^{srs}\mathrm{x}\iff \left(y{\ngtr }_{L}x\right)\wedge \exists a\in T: \left(\mathrm{a}{\to }_{L}x\right)\wedge \left(\mathrm{y}{\to }_{L}a\right)\wedge \left(x{\nparallel }_{L}a\right)\wedge \left(a{\nparallel }_{L}y\right)\wedge \left(a{>}_{L}a\right).$$

(21)

Definition 9. 

(Long-Skip in sequence). Let $A$ be a set of tasks, $L$ be an event log over $A, and a, b$ two activities from $A$. The dependency ${a⇢}_L^{lss}b$ reflects the mendacious dependency associated with invisible tasks of type long Skip in Sequence and is defined as follows:

$$\mathrm{a}{⇢}_L^{lss}\mathrm{b}\iff \left(\mathrm{a}{\to }_{L}b\right) \wedge \exists x,y\in A: \left(\mathrm{a}{\to }_{L}x\right) \wedge \left(\mathrm{y}{\to }_{L}b\right) \wedge \left(y{\ngtr }_{L}x\right) \wedge (x{\nparallel }_{L}b)\wedge \left(a{\nparallel }_{L}y\right)\wedge \left(x{⊱}_{L}y\right).$$

(22)

Definition 10. 

(long redo in sequence). Let $A$ be a set of tasks, L be an event log over $A, and x, y$ two activities from $A$. The dependency ${x⇢}_L^{srs}y$ which represents the mendacious dependency associated with invisible tasks of type long Redo in Sequence is defined as follows:

$$\mathrm{y}{⇢}_L^{lrs}\mathrm{x}\iff \exists a,b\in A: \left(\mathrm{a}{\to }_{L}x\right) \wedge \left(\mathrm{y}{\to }_{L}b\right)\wedge \left(x{\nparallel }_{L}b\right)\wedge \left(y{\nparallel }_{L}a\right) \wedge (b{⊱}_{L}a)\wedge (a{>}_{L}b).$$

(23)

Definition 11. 

(Short-Skip in parallel). Let $A$ be a set of tasks, $L$ be an event log over $A$, and $a$, $b$ two activities from $A$. The dependency ${x⇢}_L^{ssp}y$ which represents the mendacious dependency associated with invisible tasks of type Short-Skip in Parallel is defined as follows:

$$\begin{gathered} a{\ge }_L^{sh}b\iff \exists x\in Between\left(L, a,b\right)\wedge \forall m\in (Between\left(L, a,b\right)\setminus \left\{x\right\}):\left(m {\Vert }_{L}x\right) {\wedge \exists }_{\sigma \in L}Between\left(\sigma , a,b\right)\subseteq \\ \left(Between\left(L, a,b\right)\setminus \left\{x\right\}\right), \end{gathered}$$

(24)

$$a{\rightrightarrows }_L^{sh}b\iff \left(\left(a{\ge }_L^{sh}b\right)\wedge \left(b{\ngeqq }_L^{sh}a\right)\right)\vee (a{◊}_{L}b),$$

(25)

$${a⇢}_L^{ssp}b\iff \exists x,y\in A:\left(\mathrm{a}{\to }_{L}x\right) \wedge \left(\mathrm{y}{\to }_{L}b\right)\wedge \left(x{\nparallel }_{L}b\right)\wedge \left(y{\nparallel }_{L}a\right)\wedge (a{\rightrightarrows }_L^{sh}b)$$

(26)

.

Definition 12. 

(Short-Redo in parallel). Let $A$ be a set of tasks, $L$ be an event log over $A, and x, y$ two activities from $A$. The dependency ${x⇢}_L^{srp}y$ which represents the mendacious dependency associated with invisible tasks of type Short-Redo in Parallel is defined as follows:

$${y⇢}_L^{srp}x\iff \exists a\in A:\left(\mathrm{a}{\to }_{L}x\right) \wedge \left(\mathrm{y}{\to }_{L}a\right)\wedge \left(a{\nparallel }_{L}x\right)\wedge \left(y{\nparallel }_{L}a\right)\wedge \left(y{\rightrightarrows }_L^{sh}x\right) \wedge (a{>}_{L}a)$$

(27)

.

Definition 13. 

(long skip in parallel). Let $A$ be a set of tasks, $L$ be an event log over $A, and a, b$ two activities from $A$. The dependency ${x⇢}_L^{lsp}y$ which represents the mendacious dependency associated with invisible tasks of type Long-Skip in Parallel is defined as follows:

$$\begin{gathered} a{\ge }_L^{lg}b \iff {\exists }_{x,y\in A}Between \left(L,x,y\right)\subset Between \left(L,a,b\right) \wedge \forall m\in \left(Between\left(L, a,b\right)\setminus \left(Between\left(L,x,y\right)\cup \\ \left\{x,y\right\}\right)\right) \forall n\in Between \left(L,x,y\right){:\left(m {\Vert }_L n\right) \wedge \exists }_{\sigma \in L} Between \left(\sigma , a,b\right) \subseteq \left(Between\left(L, a,b\right)\setminus \left\{x,y\right\}\right), \end{gathered}$$

(28)

$$a{\rightrightarrows }_L^{lg}b\iff \left(\left(a{\ge }_L^{lg}b\right)\wedge \left(b{\ngeqq }_L^{lg}a\right)\right)\vee (a{◊}_{L}b),$$

(29)

$${a⇢}_L^{lsp}b\iff \exists x,y\in A:\left(\mathrm{a}{\to }_{L}x\right) \wedge \left(\mathrm{y}{\to }_{L}b\right)\wedge \left(x{\nparallel }_{L}b\right)\wedge \left(y{\nparallel }_{L}a\right)\wedge \left(a{\rightrightarrows }_L^{lg}b\right)\wedge \left(y{\ngeqq }_{L}x\right)\wedge (x{⊱}_{L}y)$$

(30)

.

Definition 14. 

(long redo in parallel). Let $A$ be a set of tasks, $L$ be an event log over $A, and a, b$two activities from$A$. The dependency ${x⇢}_L^{lrp}y$ which represents the mendacious dependency associated with invisible tasks of type Long-Redo in Parallel is defined as follows:

$${y⇢}_L^{lrp}x\iff \exists a,b\in A:\left(\mathrm{a}{\to }_{L}x\right) \wedge \left(\mathrm{y}{\to }_{L}b\right)\wedge \left(x{\nparallel }_{L}b\right)\wedge \left(y{\nparallel }_{L}a\right)\wedge \left(y{\rightrightarrows }_L^{lg}x\right)\wedge \left(b{\ngeqq }_{L}a\right)\wedge (b{⊱}_{L}a)$$

(31)

.

3.2.4. Non-Free Choice Constructs

Definition 15 in the framework defines the transformed implicit ordering relations for detecting non-free choice constructs based solely on the information in the event log. These transformed relations are derived from the three implicit dependencies introduced in the ${\mathsf{\alpha }}^{++}$ algorithm, which were originally based on the place’s component of a workflow net. To clarify, the ${\mathsf{\alpha }}^{++}$algorithm initially proposed the three implicit dependencies to detect five types of non-free choice constructs, as depicted in Figure 6. However, since the framework focuses on utilizing only the event log for non-free choice detection, we have converted the conditions on places in the original algorithm to conditions on transitions. It is worth mentioning that for a more comprehensive understanding of the implicit dependencies defined in the ${\mathsf{\alpha }}^{++}$algorithm, refer to [23], which provides additional details.

Before that we introduce two relations ${⊲}_{\mathrm{L}}$ and ${⊳}_{\mathrm{L}}$ defined in the ${\mathsf{\alpha }}^{++}$ algorithm and which will be used in the definition of implicit dependencies. Moreover, we introduce a new relation, the ${⧏}_{\mathrm{L}}$, which we will use too in defining the implicit dependencies.

• ${⊲}_{\mathrm{L}}$ (XOR-Split): This relation represents an exclusive OR (XOR) splitting of a process flow. It indicates that at a specific point in the process, there are multiple possible outgoing transitions, but only one of them can be taken. ${⊳}_{\mathrm{L}}$ (XOR-Join): This relation corresponds to an exclusive OR (XOR) joining of a process flow. It indicates that there are multiple incoming transitions to a specific point in the process, but only one of them is enabled and must be followed.
• ${⧏}_{\mathrm{L}}$ (AND-Split): This relation represents an AND-split in the process flow. It indicates that at a particular point in the process, multiple outgoing transitions can be taken simultaneously.

These relations ${⊲}_{\mathrm{L}}$, ${⊳}_{\mathrm{L}}$, and ${⧏}_{\mathrm{L}}$, are defined in Definition 15 of the ${\mathsf{\alpha }}^{++}$algorithm. They are used in the subsequent definitions of implicit dependencies for detecting non-free choice constructs within the framework.

Definition 15. 

(XOR-Split, XOR-Join and AND-split). Let $A$ be a set of tasks,$L$ be an event log over $A$, $and a$, $b$ two activities from $A$.

$$a{⊲}_{L}b \iff \left(a{\ne }_{L}b\right)\wedge \exists c\in A:\left(c {\to }_{L}a\right)\wedge \left(c {\to }_L b\right),$$

(32)

$$a{⊳}_{L}b \iff \left(a{\ne }_{L}b\right)\wedge \exists c\in A:\left(a{\to }_{L}c\right)\wedge \left(b {\to }_L c\right),$$

(33)

$$a{⧏}_{L }\iff \exists x, y\in A:\left(a {\to }_L x\right)\wedge \left(a {\to }_L y\right) \wedge (x {\Vert }_{L}y)$$

(34)

.

Definition 16. 

(Implicit ordering relations). Let $A$ be a set of tasks, $L$ be an event log over $A, and a, b$two activities from $A$. The implicit dependencies ${\to }_{L^1}$, ${\to }_{L^2}$, and ${\to }_{L^3}$ which detect non-free choice constructs are defined as follows:

$$a{\to }_{L^1}b \iff \left(a{\ngtr }_{L}b\right)\wedge \exists c\in A:\left(a{>}_{L}c\right)\wedge \left(c{⊲}_{L}b\right) \wedge \nexists t\in A:\left(t{>}_{L}a\right)\wedge \left(\left( t{>}_{L}a\right) \vee \left(t {\Vert }_{L}a\right)\right),$$

(35)

$$\begin{gathered} a{\to }_{L^{21}}b \iff \left(a{\gg }_{L}b\right)\wedge a{⧏}_L \wedge \exists b^{\prime }\in A:\left(b{⊲}_L{b}^{\prime }\right)\wedge \nexists t\in A:a{>}_{L}t \wedge \left(t{⊱}_{L}b or t {\Vert }_{L}b\right)\wedge \exists t^{\prime } \\ \in A:a{>}_L{t}^{\prime }\wedge \left(t^{\prime {⊱}_L}b \vee t^{\prime }{\Vert }_{L}b\right), \end{gathered}$$

(36)

$$\begin{gathered} a{\to }_{L^{22}}b \iff \left(a{\gg }_{L}b\right)\wedge b{⧐}_L \wedge \exists {a\prime }^{\prime }\in A:\left(a{⊳}_{L}a\prime \right)\wedge \nexists t \\ \in A:t{>}_{L}b\wedge \left(a{⊱}_{L}t or a {\Vert }_{L}t\right)\wedge \exists t^{\prime }\in A:t^{\prime {>}_L}b \wedge \left(a^{\prime {⊱}_L}{t}^{\prime }\vee a^{\prime }{\Vert }_L{t}^{\prime }\right), \end{gathered}$$

(37)

$$a{\to }_{L^2}b \iff a{\to }_{L^{21}}b \vee a{\to }_{L^{22}}b , and$$

(38)

$$a{\to }_{L^3}b \iff \left(a{⊲}_{L}a\prime \right)\wedge \left(b{⊳}_L{b}^{\prime }\right)\wedge \left(a{\gg }_{L}b\right)\wedge \left(a{\neg \gg }_L{b}^{\prime }\right).$$

(39)

First of all, relation ${\to }_{{\mathrm{L}}^1}$ detects the implicit dependencies illustrated in Figure 6b,g from an event log. These dependencies are identified by analyzing the event log and are related to specific patterns or relationships among the activities recorded in the log. Secondly, relation ${\to }_{{\mathrm{L}}^2}$ detects the implicit dependencies shown in Figure 6c–f. By examining the event log data, these dependencies can be uncovered, revealing correlations or interdependencies between different activities or events. Finally, relation ${\to }_{{\mathrm{L}}^3}$ detects the implicit dependencies similar to Figure 6a. Through an analysis of the event log, similar patterns or relationships among activities can be identified, indicating the existence of these dependencies.

By leveraging these three relations, your framework aims to identify and discover various implicit dependencies within the event log, aligning with the specific scenarios and patterns represented in Figure 6.

3.2.5. Invisible Tasks Involved in a Non-Free Choice Construct Detection

There are cases where invisible tasks are involved in a non-free choice construct. An example is illustrated in Figure 7. Tasks t1 and t2 are invisible tasks designed to skip the execution of tasks B and E. t2 together with E, p2, p3, and p4 form a non-free choice construct indicating that if the invisible task t1 is executed, t2 will be later executed and E will not be performed, and if B is executed, E will be executed later and not t2. To detect the involvement of invisible tasks in a non-free choice construct, the reachable dependencies between the two invisible tasks t1 and t2 need to be detected in this example. For this, the ${\mathsf{\alpha }}^{\mathrm{\$}}$ algorithm introduced the notion of conditional reachable dependency (CRD) which requires artificially adding a starting task (i.e., $\perp$) and an ending task (i.e., $\mathrm{\top }$). The conditional reachable dependency is defined in Definition 17. The relation $\mathrm{a}{\gg }_{\mathrm{L}}\mathrm{b}$ which indicates that $\mathrm{a}$ is indirectly followed by $\mathrm{b}$ is used in this definition. Definition 17 introduced three types of CRDs: pre-CRD (i.e., ${⊱}_{\mathrm{L},\mathrm{p}\mathrm{r}\mathrm{e}=\mathrm{x}}$), post-CRD (i.e., ${⊱}_{\mathrm{L},\mathrm{p}\mathrm{o}\mathrm{s}\mathrm{t}=\mathrm{y}}$), and both-CRD (i.e., ${⊱}_{\mathrm{L},\mathrm{p}\mathrm{r}\mathrm{e}=\mathrm{x},\mathrm{p}\mathrm{o}\mathrm{s}\mathrm{t}=\mathrm{y}}$). $\mathrm{a}{⊱}_{\mathrm{L},\mathrm{p}\mathrm{r}\mathrm{e}=\mathrm{x},\mathrm{p}\mathrm{o}\mathrm{s}\mathrm{t}=\mathrm{y}}\mathrm{b}$ indicates that there is a trace where $\mathrm{a}{\gg }_{\mathrm{L}}\mathrm{b}$ holds and $x$ is executed directly before $a$ and $\mathrm{y}$ is performed directly after $\mathrm{b}$.

Definition 17. 

(Conditional reachable dependency). Let $A$ be a set of activities, $L$ be an event log over $A$; $\perp$ and $\top$ are starting activity and ending activity artificially added to each trace in the event log such that for $a$ trace $\sigma$ with length $n$, ${\sigma }_0=\perp$ and ${\sigma }_{n+1}=\top$, $a, b$ two activities from $A,$ and $x, y$ two activities from $A\cup \left\{\perp \right\}\cup \{\top \}$. Conditional reachable dependencies are defined as follows:

$$\mathrm{a}{⊱}_{L, pre=x}b \iff \left(\mathrm{a}{\to }_{L}b\right) \vee ({\exists }_{\sigma \in L\wedge 1\le i\le \left|\sigma \right|}{ \sigma }_i=a \wedge { \sigma }_{i-1}=x \wedge \left(a{\gg }_{\sigma }b\right)),$$

(40)

$$\mathrm{a}{⊱}_{L, post=y}b \iff \left(\mathrm{a}{\to }_{L}b\right) \vee ({\exists }_{\sigma \in L\wedge 1\le j\le \left|\sigma \right|}{ \sigma }_j=b \wedge { \sigma }_{j+1}=y \wedge \left(a{\gg }_{\sigma }b\right)),$$

(41)

$$\mathrm{a}{⊱}_{L, pre=x,post=y}b \iff \left(\mathrm{a}{\to }_{L}b\right) \vee ({\exists }_{\sigma \in L\wedge 1\le i,j\le \left|\sigma \right|} { \sigma }_i=a \wedge { \sigma }_j=b \wedge { \sigma }_{j+1}=y \wedge { \sigma }_{i-1}=x \wedge \left(a{\gg }_{\sigma }b\right)).$$

(42)

$\mathrm{T}\mathrm{h}\mathrm{e} {\mathsf{\alpha }}^{\mathrm{\$}}$ algorithm defined the reachable dependency related to invisible tasks based on conditional reachable dependency. For two invisible tasks $\mathrm{x}$ and $\mathrm{y}$, $\mathrm{x}{⊱}_{\mathrm{L}}\mathrm{y}$ holds if there exist four tasks $a_1$, ${\mathrm{a}}_2$, ${\mathrm{b}}_1,$ and ${\mathrm{b}}_2$ such that ${\mathrm{a}}_1{\to }_L\mathrm{x}$, $\mathrm{x}{\to }_{\mathrm{L}}{\mathrm{b}}_1$, ${\mathrm{a}}_2{\to }_{\mathrm{L}}\mathrm{y}$, $\mathrm{y}{\to }_{\mathrm{L}}{\mathrm{b}}_2$, and ${\mathrm{b}}_1{⊱}_{\mathrm{L},\mathrm{p}\mathrm{r}\mathrm{e}={\mathrm{a}}_1,\mathrm{p}\mathrm{o}\mathrm{s}\mathrm{t}={\mathrm{b}}_2}{\mathrm{a}}_2$. $\mathrm{x}{⊱}_{\mathrm{L}}\mathrm{m}$ holds if there exist two tasks $\mathrm{a}$ and $\mathrm{b}$ such that $\mathrm{a}{\to }_{\mathrm{L}}\mathrm{x}$, $\mathrm{x}{\to }_{\mathrm{L}}\mathrm{b}$, and $\mathrm{b}{⊱}_{\mathrm{L},\mathrm{p}\mathrm{r}\mathrm{e}=\mathrm{a}}\mathrm{m}.\mathrm{m}{⊱}_{\mathrm{L}}\mathrm{x}$ is similar to $\mathrm{x}{⊱}_{\mathrm{L}}\mathrm{m}.$ The reachable dependencies related to invisible tasks involved in a non-free choice construct are defined in Definition 18.

Definition 18. 

(Reachable dependencies related to invisible tasks with non-free choice). Let $A$ be a set of activities, $L$ be an event log over $A$, m be an activity from $A, and x,y$ be two invisible tasks. The reachable dependencies related to invisible tasks in a non-free choice are defined as follows:

$$x{⊱}_{L}m \iff {\exists }_{\left(a=\perp \vee a\in L\right) \wedge b\in L} \left(a{\to }_{L}x\right) \wedge \left(x{\to }_{L}b\right) \wedge b{⊱}_{L, pre=a}m$$

(43)

$$m{⊱}_{L}x \iff {\exists }_{ a\in L \wedge (b\in L \vee b=\top )} \left(a{\to }_{L}x\right) \wedge \left(x{\to }_{L}b\right) \wedge m{⊱}_{L, pre=b}a$$

(44)

$$\begin{gathered} x{⊱}_{L}y \iff {\exists }_{\left(a_1=\perp \vee a_1\in L\right) \wedge b_1\in L \wedge a_2\in L \wedge { (b}_2\in L \vee b_2=\top )} \left(a_1{\to }_{L}x\right) \wedge \left(x{\to }_L{b}_1\right)\wedge \left(a_2{\to }_{L}y\right)\wedge \left(y{\to }_L{b}_2\right)\wedge \\ {b}_1{⊱}_{L, pre=a_1,post=b_2}{a}_2 \end{gathered}$$

(45)

.

However, the reachable dependency defined in the ${\mathsf{\alpha }}^{\mathrm{\$}}$ algorithm to detect the involvement of invisible tasks in a non-free choice construct actually does not differentiate between non-free choice and a free choice. For instance, $\mathrm{t}1{⊱}_{\mathrm{L}}\mathrm{t}2$ of the event log of the WF-net shown in Figure 7 where there is a reachable dependency between $\mathrm{t}1$ and $\mathrm{t}2$ holds, and $\mathrm{t}1{⊱}_{\mathrm{L}}\mathrm{t}2$ of the event log of the WF-net shown in Figure 8 where there is not a reachable dependency between $\mathrm{t}1$ and $\mathrm{t}2$ also holds. In the given log example of Figure 8, it is stated that $\mathrm{t}1{⊱}_{\mathrm{L}}\mathrm{t}2$ holds, indicating an XOR-split between tasks $\mathrm{t}1$ and $\mathrm{t}2$. Additionally, $\mathrm{t}1{⊱}_{\mathrm{L}}\mathrm{E}$ also holds, implying an XOR-split between task t1 and some other task E. However, to properly detect a reachable dependency between $\mathrm{t}1$ and $\mathrm{t}2$, it should not be the case that $\mathrm{t}1{⊱}_{\mathrm{L}}\mathrm{E}$ holds. Based on this, we improved the reachable dependency related to invisible tasks in Definition 19. This improvement addresses the issue of invisible tasks $\mathrm{t}1$ and $\mathrm{t}2$ being involved in an XOR-split ($\mathrm{t}1{⊱}_{\mathrm{L}}\mathrm{t}2$) while $\mathrm{t}1$ is also XOR-split with another task E ($\mathrm{t}1{⊱}_{\mathrm{L}}\mathrm{E}$). The improved definition takes into account this constraint and ensures that the presence of $\mathrm{t}1{⊱}_{\mathrm{L}}\mathrm{E}$ does not interfere with detecting the reachable dependency between $\mathrm{t}1$ and $\mathrm{t}2$. The provided example in Figure 8 depicts a sound WF-net with invisible tasks $\mathrm{t}1$ and$\mathrm{t}2$ that are not involved in a free choice construct. The set of traces L = {<A, B, C, D, E, F>, <A, C, D, F>, <A, B, C, D, F>, <A, C, D, E, F>} represents the traces observed in the event log for this WF-net.

Definition 19. 

(Improved reachable dependency related to invisible tasks). Let $A$ be a set of activities, $L$ be an event log over $A$, m be an activity from$A, x,y$ be two invisible tasks, and the improved reachable dependencies related to invisible tasks in a non-free choice are defined as follows:

$$x{⊱}_{L}m \iff {\exists }_{\left(a=\perp \vee a\in L\right) \wedge b\in L} \left(a{\to }_{L}x\right) \wedge \left(x{\to }_{L}b\right) \wedge b{⊱}_{L, pre=a}m \wedge {\nexists }_{n\in \sigma } b{⊱}_{L, pre=a}n ,$$

(46)

$$m{⊱}_{L}x \iff {\exists }_{ a\in L \wedge (b\in L \vee b=\top )} \left(a{\to }_{L}x\right) \wedge \left(x{\to }_{L}b\right) \wedge m{⊱}_{L, pre=b}a \wedge {\nexists }_{n\in \sigma } m{⊱}_{L, pre=n}a ,$$

(47)

$$\begin{gathered} x{⊱}_{L}y \iff {\exists }_{\left(a_1=\perp \vee a_1\in L\right) \wedge b_1\in L \wedge a_2\in L \wedge { (b}_2\in L \vee b_2=\top )} \left(a_1{\to }_{L}x\right) \wedge \left(x{\to }_L{b}_1\right)\wedge \left(a_2{\to }_{L}y\right)\wedge \left(y{\to }_L{b}_2\right)\wedge \\ {b}_1{⊱}_{L, pre=a_1,post=b_2}{a}_2 {\wedge \nexists }_{n\in L} b_1{⊱}_{L, pre=a_1,post=b_n}{a}_2 \end{gathered}$$

(48)

.

3.3. Knowledge Data Base Construction

All existing process discovery algorithms have no problem in correctly discovering the standard (sequence, choice, and parallel) constructs. The difference between the algorithms appears in the mining of complex constructs. The knowledge database will contain the information on the ability of each algorithm in mining the complex constructs. The process discovery techniques that are included in the knowledge database are the $\mathsf{\alpha }$ algorithm, the ${\mathsf{\alpha }}^{+}$ algorithm, the ${\mathsf{\alpha }}^{++}$ algorithm, the ${\mathsf{\alpha }}^{\#}$ algorithm, Inductive Miner (IM), Heuristics Miner (HM), ILP [24], ETM [22], Region Miner (RM), Transition System (TS) [25], DWS [26], and Genetic Miner (GM). There are other algorithms but they are not implemented in ProM. Only the information of those implemented in ProM is included in the knowledge database. However, any newly developed algorithm and implemented in ProM can be included in the knowledge database. The knowledge database includes the information on the capability of any of these algorithms in discovering in detail the complex constructs: Short loops of length one (${\mathrm{L}}_{1\mathrm{p}}$ for short), Short loops of length two (${\mathrm{L}}_{2\mathrm{p}}$), invisible tasks of type Short-Skip in sequence (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$), invisible tasks of type Short-Skip in parallel (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$), invisible tasks of type Short-Redo in sequence (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$), invisible tasks of type Short-Redo in parallel (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$), invisible tasks of type Long-Skip in sequence (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$), invisible tasks of type Long-Skip in parallel (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$), invisible tasks of type Long-Redo in sequence (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$), invisible tasks of type Long-Redo in parallel (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$), non-free choice construct (NFC), and invisible tasks involved in a non-free choice construct (IvT-NFC).

3.3.1. Algorithms Classification Based on Their Ability in Mining Complex Constructs

There are plenty of empirical studies on the capability of process discovery techniques in mining complex constructs. However, most studies focus on a small number of algorithms or on the most frequently used ones. Moreover, they do not evaluate the ability of algorithms in discovering all types of complex constructs. Therefore, we generated event logs containing all types of aforementioned complex constructs. We imported the event logs with the ProM tool and ran the plugin of each of the aforementioned algorithms.

$\mathrm{T}\mathrm{h}\mathrm{e}\mathsf{\alpha }$ algorithm and the ${\mathsf{\alpha }}^{+}$ algorithm were not evaluated because we know before that the $\mathsf{\alpha }$ algorithm cannot discover the complex constructs and the ${\mathsf{\alpha }}^{+}$ algorithm can discover from complex constructs only the two types of short loops (${\mathrm{L}}_{1\mathrm{p}}$ and ${\mathrm{L}}_{2\mathrm{p}}$). We ran experiments on the rest of algorithms. The results show that the ${\mathsf{\alpha }}^{++}$ algorithm can correctly discover the two types of short loops and the three types of non-free choice constructs while it is incapable of discovering all types of invisible tasks and IvT-NFC. The ${\mathsf{\alpha }}^{\#}$ algorithm is capable of mining ${\mathrm{L}}_{1\mathrm{p}}$, ${\mathrm{L}}_{2\mathrm{p}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$ whereas it is unable of discovering ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, $\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{W}$, $\mathrm{N}\mathrm{F}\mathrm{C}$, and $\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{N}\mathrm{F}\mathrm{C}$. The Inductive Miner can correctly discover the two types of short loops and seven types of invisible tasks. However, the latter cannot detect one type of invisible tasks which are of type Switch and type Short-Redo in parallel, non-free choice constructs and invisible tasks involved in a non-free choice construct. The Heuristic Miner is capable of mining invisible tasks of types ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, $\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{W}$, a similar behaviour to short loops of type ${\mathrm{L}}_{2\mathrm{p}}$, but it cannot discover short loops of type ${\mathrm{L}}_{1\mathrm{p}}$, invisible tasks of types ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, non-free choice constructs, and invisible tasks involved in a non-free choice construct. The Integer linear programming miner (ILP) can mine the two types of short loops, whereas it cannot discover all types of invisible tasks, non-free choice constructs, and invisible tasks involved in a non-free choice construct. The Evolutionary Tree Miner (ETM) is capable of discovering short loops of types ${\mathrm{L}}_{1\mathrm{p}}$, invisible tasks of types ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$ while it is incapable of mining short loops of type ${\mathrm{L}}_{2\mathrm{p}}$, invisible tasks of types ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, $\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{W}$, non-free choice constructs, and invisible tasks involved in a non-free choice construct. Region miner (RM) is able of deriving short loops of type ${\mathrm{L}}_{2\mathrm{p}}$, invisible tasks of type with similar behavior to ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, while it cannot discover short loops of type ${\mathrm{L}}_{1\mathrm{p}}$, the rest of invisible tasks, non-free choice constructs, and $\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{N}\mathrm{F}\mathrm{C}.$ The transition system (TS) can derive short loops of type ${\mathrm{L}}_{2\mathrm{p}}$ and similar behaviour to ${\mathrm{L}}_{1\mathrm{p}}$, invisible tasks of type ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, similar behavior to ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, and similar behavior to ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$. However, this technique cannot discover ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, non-free choice constructs, and invisible tasks involved in a non-free choice structure. The Disjunctive Workflow Schema (DWS) algorithm can mine short loops of type and invisible tasks of types ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, and $\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{W}$. Nevertheless, it cannot derive short loops of types ${\mathrm{L}}_{1\mathrm{p}}$, all invisible tasks that are involved in a parallel construct, non-free choice constructs, and invisible tasks involved in a non-free choice construct. Finally, Genetic Miner (GM) can discover all constructs except invisible tasks of type ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, non-free choice constructs, and $\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{N}\mathrm{F}\mathrm{C}$. The abilities of these algorithms in mining complex constructs are summarized in

Table 2. Comparison of the ability of current algorithms in mining standard and complex constructs.

	${\mathit{\alpha }}^{++}$	${\mathit{\alpha }}^{\#}$	IM	HM	ILP	ETM	RM	TS	DWS	GM
${\mathrm{L}}_{1\mathrm{p}}$	Yes	Yes	Sb	No	Yes	Yes	No	Sb	No	Yes
${\mathrm{L}}_{2\mathrm{p}}$	Yes	Yes	Yes	Sb	Yes	No	Yes	Yes	Yes	Yes
${\mathrm{I}\mathrm{v}\mathrm{T}}_{{\mathrm{S}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}}$	Sb	Yes	Yes	No	No	No	No	Sb	Yes	No
${\mathrm{I}\mathrm{v}\mathrm{T}}_{{\mathrm{L}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}}$	No	Yes	Yes	Yes	No	No	Sb	No	Yes	Yes
${\mathrm{I}\mathrm{v}\mathrm{T}}_{{\mathrm{S}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}}$	No	No	No	No	No	No	No	No	No	No
${\mathrm{I}\mathrm{v}\mathrm{T}}_{{\mathrm{L}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}}$	No	No	Yes	No	No	No	No	No	No	Yes
${\mathrm{I}\mathrm{v}\mathrm{T}}_{{\mathrm{S}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}}$	No	Yes	Yes	Yes	No	Yes	No	Yes	Yes	Yes
${\mathrm{I}\mathrm{v}\mathrm{T}}_{{\mathrm{S}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}}$	No	No	Yes	No	No	No	No	Sb	No	No
${\mathrm{I}\mathrm{v}\mathrm{T}}_{{\mathrm{L}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}}$	No	Yes	Yes	Yes	No	Yes	No	No	Yes	Yes
${\mathrm{I}\mathrm{v}\mathrm{T}}_{{\mathrm{L}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}}$	No	No	Yes	Yes	No	No	No	No	No	Yes
${\mathrm{I}\mathrm{v}\mathrm{T}}_{\mathrm{S}\mathrm{W}}$	No	Yes	No	Yes	No	No	No	No	Yes	Yes
NFC	Yes	No	No	No	No	No	No	No	No	Yes
${IvT}_{in-NFC}$	No	No	No	No	No	No	No	No	No	No

.

There is no discovery algorithm capable of discovering invisible tasks of type Short- Redo in parallel and invisible tasks involved in non-free choice constructs. Only the ${\mathsf{\alpha }}^{\mathrm{\$}}$ algorithm can discover these two types of invisible tasks. However, this algorithm is not implemented in ProM. Therefore, we exclude the detection of invisible tasks of types $\mathrm{I}\mathrm{v}\mathrm{T}-{\mathrm{S}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$ and $\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{N}\mathrm{F}\mathrm{C}$.

3.3.2. Mining Time Based Classification of Discovery Algorithms

Process model discovery time may differ from algorithm to algorithm. Most existing algorithms may take milliseconds to a few minutes, based on the size of the event logs, to discover a process model. However, there are some algorithms which can take a long time to derive a process model such as Genetic Miner. This latter takes a long time in mining a process model even with a small event log and for big event log, it may run forever. Therefore, the genetic algorithm might be the last candidate process discovery algorithm to recommend. The Evolutionary tree miner and Integer linear programing algorithms also take too much time to discover a model. Genetic Miner takes more time than ETM and ETM takes more time than the ILP algorithm, and these three algorithms take time compared to the rest of algorithms.

3.3.3. Algorithms Classification Based on Their Ability in Discovering Sound Models

There are process discovery algorithms that are not guaranteed to discover sound models. $\mathsf{\alpha }$ algorithm series and heuristic miner might produce process models that are not sound. They may contain problems such as deadlocks, livelocks, etc. The inductive miner and ILP miner can guarantee soundness of discovered models [20]. A process model that is not sound cannot replay traces until the end.

4. Recommendation Framework Implementation and Evaluation

This section discusses the experimental evaluation of the framework proposed for recommending business process discovery algorithms. First, we discuss the implementation in ProM, followed by an explanation of the method used for evaluation. Then in Section 4.3, we describe an evaluation based on 40 artificial examples. In Section 4.4, we discuss an evaluation based on 5 more realistic event logs.

4.1. Implementation in ProM

The framework consists of two parts. The first part is the detection of complex constructs from a given event log. The second part consists of recommending, based on the knowledge database, the algorithm capable of handling the constructs detected from the event log in the first part. The first part (i.e., the major part) which consists of detecting the complex characteristics (i.e., invisible tasks, non-free choice, loops) has been implemented in ProM. ProM is an extensible framework that provides a comprehensive set of plugins for the discovery, conformance checking and analysis of process models from event logs and can be downloaded from http://www.processmining.org (accessed on 3 January 2023). ProM takes an event log as input in the standard XES format and uses process mining plugins for different purposes. Knowledge in the database on the ability of algorithms in mining the complex constructs can be changed and updated with the conducted research on enhancing the ability of existing algorithms in handling complex constructs. Figure 9 shows a screenshot of the plugin for detecting the status of complex constructs from a given event log.

The plugin works as follows. Once the event log in question is imported in ProM, the plugin “Event Log Characteristics Detection for Recommending Process Discovery Algorithms” is selected and run. The output is a table which indicates whether the complex constructs (i.e., Short loops of length one (${\mathrm{L}}_{1\mathrm{p}}$ for short), Short loops of length two (${\mathrm{L}}_{2\mathrm{p}}$), invisible tasks of type Short-Skip in sequence (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$), invisible tasks of type Short-Skip in parallel (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$), invisible tasks of type Short-Redo in sequence (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$), invisible tasks of type Short-Redo in parallel (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$), invisible tasks of type Long-Skip in sequence (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$), invisible tasks of type Long-Skip in parallel (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$), invisible tasks of type Long-Redo in sequence (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$), invisible tasks of type Long-Redo in parallel (${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$), non-free choice construct (NFC), and invisible tasks involved in a non-free choice construct (IvT-NFC)) exist or not in the event log by showing “YES” if they exist and “NO” if not. Then, based on the result obtained in the table and knowledge database, candidate algorithms are recommended. A screenshot of an example of obtained results is depicted in Figure 10.

4.2. Evaluation Framework

The framework has been evaluated using 40 artificial event logs and 5 real-life event logs. The 40 artificial event logs contain randomly the 11 characteristics ${\mathrm{L}}_{1\mathrm{p}}$, ${\mathrm{L}}_{2\mathrm{p}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, and $\mathrm{N}\mathrm{F}\mathrm{C}$. The characteristics existing in the logs were detected and candidate algorithms were recommended based on the detected characteristics and based on the knowledge database containing information on the ability of the ${\mathsf{\alpha }}^{+}$ algorithm, the ${\mathsf{\alpha }}^{++}$ algorithm, the ${\mathsf{\alpha }}^{\#}$ algorithm, Inductive Miner (IM), Heuristics Miner (HM), Integer Linear Programming algorithm (ILP), Evolutionary Tree Miner (ETM), Region Miner (RM), Transition System (TS), and DWS on mining the complex constructs. If more than one algorithm is recommended, a recommendation based on time classification and soundness classification is conducted. Then, the final recommended algorithm is used to discover a process model from the event log in question. After that, for artificial event logs, the process model discovered with the final recommended algorithm is compared with the reference model of these event logs. In the practical world, reference models are usually not available. Therefore, for real life data, the model discovered with the recommended algorithm is replayed by the event log to investigate whether the event log is in conformance with the discovered process model. An illustration of the evaluation method is depicted in Figure 11. The comparison of the discovered model with the original model and the event log is conducted using conformance checking metrics. We used three types of metrics: behavioral similarity (${\mathrm{B}}_{\mathrm{P}} \mathrm{a}\mathrm{n}\mathrm{d} {\mathrm{B}}_{\mathrm{R}}$), to evaluate how similar the discovered model and the original model behaved in terms of precision and recall; structural similarity ${(\mathrm{S}}_{\mathrm{P}} \mathrm{a}\mathrm{n}\mathrm{d} {\mathrm{S}}_{\mathrm{R}}$), to assess how structurally similar the discovered model and the original model were in terms of precision and recall; and ETC precision to identify whether the process model is precise to the observed behavior (i.e., the event log). ETC precision is used when the reference model is unavailable. Behavioral and structural similarity metrics are used in the case of evaluation using artificial data and the ETC precision metric is used in the case of evaluation using real-life data.

To identify similarity between two process models, an original model and a discovered model, the behavioral and structural similarity between them must be considered [2]. The behavioral similarity metrics measure the similarity in behavior between two models in terms of precision and recall [3]. These metrics investigate the event log to quantify how similar the behavior of the discovered model is to that of its original model. This is completed by replaying each trace against the two models and calculating how many activities are enabled in each model at the occurrence of every event in the trace. The more enabled activities the two models have in common, the higher the similarity is between them.

Definition 20. 

(Behavioral precision and recall) [15]. Some parameters are defined as follows:

σ: a trace in an event log.

L(σ): the number of occurrences of σ in an event log.

$N_o$and$N_d$: the respective Petri nets for the original and the discovered models.

$C_o$and$C_d$: the respective causality relations for$N_o$and$N_d$.

The behavioral precision and recall are defined as:

$$B_p\left({L, C}_o,C_d\right)=(\sum (\frac{L\left(\sigma \right)}{\left|\sigma \right|}\times {\sum }_{i=0}^{\left|\sigma \right|-1}\frac{Enabled \left(C_o, \sigma , i\right)\left|\cap Enabled \left(C_d, \sigma , i\right)\right|}{\left|Enabled \left(C_d, \sigma , i\right)\right|} )/{\sum }_{\sigma \in L}L(\sigma )$$

(49)

$$B_R\left({L, C}_o,C_d\right)=(\sum (\frac{L\left(\sigma \right)}{\left|\sigma \right|}\times {\sum }_{i=0}^{\left|\sigma \right|-1}\frac{Enabled \left(C_o, \sigma , i\right)\left|\cap Enabled \left(C_d, \sigma , i\right)\right|}{\left|Enabled \left(C_o, \sigma , i\right)\right|} )/{\sum }_{\sigma \in L}L(\sigma )$$

(50)

where, $\mathrm{E}\mathrm{n}\mathrm{a}\mathrm{b}\mathrm{l}\mathrm{e}\mathrm{d}\left({\mathrm{C}}_{\mathrm{o}},\mathsf{\sigma },\mathrm{i}\right)$ is the set of enabled activities when parsing the next event (or task) after position $\mathrm{i}$ in trace $\mathsf{\sigma }$ [15]. The value of both behavioral precision and recall metrics lies in the [0, 1] range. A value close to 1 indicates a very high degree of similarity between the two models. The behavioral precision reflects how much of the behavior of the discovered model is also in the original model. The behavioral recall reflects how much of the behavior of the original model also occurs in the discovered model.

For structural similarity, the structural precision and recall metrics [15] are used. The structural recall reflects the number of correct causality relations present in the discovered model as a fraction of the total number of causality relations in the original model. The structural precision reflects the fraction of correct causality relations present in the discovered model.

Definition 21. 

(Structural precision and recall) [15]. Let $N_o=(P_o, T_o, F_o )$ and $N_d=(P_d, T_d, F_d)$ be respective Petri nets for the original and discovered models. Let $C_o$ and $C_d$ be the respective causality relations for $N_o$ and $N_d$. The structural precision and structural recall are defined as:

$${\mathrm{S}}_{\mathrm{p}}\left({\mathrm{N}}_{\mathrm{o}},{\mathrm{N}}_{\mathrm{d}}\right)=\frac{|{\mathrm{C}}_{\mathrm{o}}\cap {\mathrm{C}}_{\mathrm{d}}|}{{\mathrm{C}}_{\mathrm{d}}}$$

(51)

$${\mathrm{S}}_{\mathrm{R}}\left({\mathrm{N}}_{\mathrm{o}},{\mathrm{N}}_{\mathrm{d}}\right)=\frac{|{\mathrm{C}}_{\mathrm{o}}\cap {\mathrm{C}}_{\mathrm{d}}|}{{\mathrm{C}}_{\mathrm{o}}}$$

(52)

Both structural precision and recall are in the range [0, 1]. A value close to 1 means they are very similar structurally.

4.3. Evaluation Using Artificial Event Logs

We evaluated our approach using 40 artificial examples and compared the results of the proposed framework with empirical evaluation. The corresponding complete logs were manually generated. In this set of 40 models, the maximum number of activities in a process model is less than 15, and the number of cases in each event log is less than 30. The 40 reference models randomly include the following characteristics: ${\mathrm{L}}_{1\mathrm{p}}$, ${\mathrm{L}}_{2\mathrm{p}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{s}\mathrm{e}\mathrm{q}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{S}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{S}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, ${\mathrm{I}\mathrm{v}\mathrm{T}-\mathrm{L}\mathrm{R}}_{\mathrm{p}\mathrm{a}\mathrm{r}}$, and $\mathrm{N}\mathrm{F}\mathrm{C}$. For this analysis, we used visual inspection to compare the mined model with the reference model, as well as the previously mentioned conformance metrics: ${\mathrm{B}}_{\mathrm{r}}$ (behavioral recall), ${\mathrm{B}}_{\mathrm{p}}$ (behavioral precision), ${\mathrm{S}}_{\mathrm{r}}$ (structural recall), and ${\mathrm{S}}_{\mathrm{p}}$ (structural precision). By visually comparing the reference models and the models discovered by the recommended algorithm, we found that 95% of the process models (38 out of 40 models) were similar to the reference models.

In addition to visual inspection, we computed conformance metrics to test the behavioral and structural similarities between the original models and the models discovered by the recommended algorithms. The results are illustrated in Figure 12. As can be seen, the results obtained from the conformance metrics are consistent with the results from visual inspection. The 38 process models are similar to the original models, with values equal to or close to 1. Only two discovered models are dissimilar to the reference models. These models were discovered from the event logs L29 and L38.

For L29, the structural similarity metrics deviate slightly from a value of 1, but the behavioral similarity metrics are close to 1. Upon examining the original model, it was found to contain a loop of length one, while in the discovered model, there is an invisible task of type Short-Redo in sequence. Although these structures are different, they exhibit similar behavior, which justifies the deviation in the structural similarity metrics.

For L38, the original model contains two invisible tasks involved in a non-free choice construct. However, in the discovered model, the two invisible tasks are correctly discovered, but the implicit dependency between them, reflecting the non-free choice construct, is not discovered. This is expected since none of the existing algorithms implemented in ProM are capable of discovering invisible tasks involved in a non-free choice construct.

4.4. Evaluation Based on Real-Life Event Logs

The evaluation using artificial event logs demonstrates the power of the proposed framework in recommending a process discovery algorithm suitable for a given event log by detecting complex constructs within it. To showcase the applicability of our framework, we conducted evaluations using five real-life event logs obtained from the Process Mining Manifesto database and the Shipbuilding Processing Plan Management System of a heavy manufacturing company. Firstly, we identified existing constructs from the event logs and recommended suitable algorithms using the constructed knowledge database. The obtained results are presented in

Table 3. Recommended algorithm for each event log.

Event Logs	L1	L2	L3	L4	L5
cases	97	110	663	1676	31,509
events	361	3770	19,658	129,428	1,202,267
tasks	8	21	18	38	66
Recommended algorithm	Alpha++	IM/ILP	IM	IM/DWS	ILP

. Subsequently, we applied different process discovery algorithms to each event log to discover process models. To evaluate the discovered models, we utilized the “Check Conformance using ETConformance” plugin in ProM, which provides information on the precision of the mined model compared to the corresponding event log. The precision metric, referred to as ETC precision, is displayed in

Table 4. The ETC precision values of discovered models.

	HM	Alpha++	IM	Alpha#	ILP	DWS
L1	0.7973	1.0	0.8	0.8	0.8	0.69
L2	0.3811	0.6665	0.6665	0.6665	0.7	0.6665
L3	-	-	0.945	0.4423	0.361	0.3
L4	0.4	0.03	0.8709	0.02	-	0.89
L5	0.681	-	0.89	-	0.91	0.45

Note: (-) the value could not be computed.

. Additionally, we compared the precision metric results for each discovered model by algorithm and event log, comparing them with the recommended algorithm in Table 3. The process models were discovered using the Inductive Miner (IM), Heuristics Miner (HM), Alpha++, Alpha#, Integer Linear Programming Miner (ILP), Evolutionary Tree Miner (ETM), DWS algorithm, Genetic Miner, and Region Miner. Table 4 only shows IM, HM, ILP, DWA, Alpha#, and Alpha++ algorithms, as the others were excluded due to exceeding the running time limit of five minutes.”

As can be seen in Table 3, Alpha++ was recommended to be a suitable process discovery algorithm for the event log L1 due to the detection of a non-free choice construct in the event log L1 and due to the fact that the numbers of events, cases, and tasks are not that big. In Table 4, the precision value of the model discovered by the Alpha++ algorithm is the highest among the others (equal to 1). The precisions values of the models mined by IM, HM, ILP, Alpha#, DWS is lower. This is logical since those algorithms are incapable of handling non-free choice constructs. For log L2, no complex construct was detected. Thus, any one of the five algorithms can be recommended. However, since Alpha algorithms and Heuristic Miner do not guarantee sound models with big event logs, we recommended IM, ILP, and DWS. The values of precision of IM and DWS are similar and the precision value of ILP is slightly higher. For log L3, the invisible task of type Short-Skip in sequence was detected. Therefore, the IM algorithm was recommended. In Table 4, the precision value of IM was the highest. The results obtained for logs L4 and L5 are similar to the previous ones. Based on the obtained results, we can conclude that the recommendation framework is working well.

5. Conclusions

In today’s competitive business environment, organizations must continuously understand, analyze, and improve their processes to stay ahead in the market. Process mining offers a set of techniques that provide organizations with an in-depth understanding of their processes. It extracts valuable process-related knowledge from the vast amount of data recorded in modern process-aware information systems like Enterprise Resource Planning (ERP) systems, Business Process Management (BPM) systems, Supply Chain Management (SCM) systems, and more. Among the various categories of process mining techniques, process discovery plays a significant role. It enables the automatic construction of process models based on the information stored in the system, reflecting the real behavior of the processes. Numerous process discovery algorithms have been proposed, which has led to a situation where users and businesses face challenges in selecting the most suitable mining algorithm for their specific business processes. Additionally, existing evaluation and recommendation frameworks for process discovery techniques have their limitations and drawbacks. In our study, we have introduced a framework that recommends the appropriate process discovery algorithm for a given event log. Our methodology focuses on detecting complex control flow patterns present in the event log without the need to discover any process model. Instead, we utilize a knowledge database that contains information about the performance of existing algorithms in mining these complex constructs. This information takes into account factors such as computation time and the ability of the model to accurately discover sound models.

The detection of complex control flow constructs is based on the relations introduced in Alpha algorithms (${\mathsf{\alpha }}^{++}$, ${\mathsf{\alpha }}^{\#}$, ${\mathsf{\alpha }}^{\mathrm{\$}}$). However, in our work, we have enhanced and adapted these relations to detect complex constructs directly from event logs, without the necessity of discovering a process model. We have implemented our proposed framework in ProM and provided a detailed description of its implementation. Furthermore, we have discussed the methodology and metrics employed for the evaluation process. The framework has been evaluated using both artificial and real-life data. The results obtained demonstrate that the recommended algorithms are indeed accurate. However, it is worth noting that the evaluation of our framework was conducted with a limited number of real-life event logs. To further strengthen our findings, future work will involve incorporating a larger and more diverse set of real-life data. In summary, our proposed framework offers a method for recommending process discovery algorithms based on the detection of complex control flow constructs directly from event logs, eliminating the need for process model discovery. The framework’s implementation in ProM, evaluation using artificial and real-life data, and the correct recommendations obtained from the results indicate its potential utility. As we move forward, we aim to enhance the framework by incorporating more extensive real-life data to improve its robustness and effectiveness.