In process discovery methods that build workflow nets (WF-nets), computing activity concurrency is essential to achieve the construction of a suitable model. The condition || ← + the concurrency relation between two activities is surpassed when the event log is incomplete. This paper presents a technique for deducing additional concurrency relations between activities from incomplete event logs. The proposed technique is based on the detection of repetitive patterns within the traces in the event log; using these patterns, new logs in which the traces do not have repeated activities are derived. Afterward, a set of partial order structures is built from these event logs and then concurrency relations are straightforwardly obtained. Finally, we use a heuristic to determine concurrent relations between activities belonging to diferent repetitive patterns. The technique performs as a concurrency oracle; it has been implemented and tested on artificial event logs generated by WF-nets with diverse structures. Experiments show that the proposed oracle extracts more concurrent relations than other methods.
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
García-Bañuelos proposed reloading all Process Mining operations as operations between Prime
Event Structures, labeled partial orders, assembled through their common prefixes, preserving
conflicts. In [
This trend has generated the need to extract concurrency relations directly from the event
log since the usual way of transforming an event log into a set of partial orders (see [
The most used oracle, called -oracle, is derived from the concurrency relationship of the
-algorithm [
If the event log contains information about the life cycle of activities, the life-cycle oracle can
be implemented [
The efectiveness of a concurrency oracle strongly depends on the completeness of the event log. Unfortunately, real-life event logs may be non-complete, as was pointed out in the challengers of the Process Mining Manifesto [12].
Only a few concurrency relationships can be extracted from an incomplete event log. This situation creates some problems. For example, the discovered models will lack generalizability; that is, they will not be able to generate unrecorded behavior or will generate very little. That is especially true for region-based methods because they assume that only the recorded behavior should be in the process model.
Furthermore, discovery methods based on region theory ultimately consist of solving an Integer Linear Programming problem, where the size of the problem is a function of the size of the partial order relation. When transforming a set of traces (linearly ordered sets) into a set of partial orders, the size of the relation is reduced since the partial order relation does not include relations between concurrent activities, while these are included in the traces. Therefore, the fewer concurrency relations we know, the more elements the partial order relations will have. The latter translates into a longer execution time.
This paper presents a novel Concurrency Oracle that deals with incomplete event logs. This method obtains a set of pairs of concurrent activities, including some that were not explicitly recorded. Our proposal is based on detecting cyclic components of the process and projecting the event log on their activities, obtaining new ”event logs” in which all the activities present in these logs are in the same cycle. These new event logs are transformed in a specific way so that activities do not appear more than once in each trace. Once we have such a set of traces without repeated activities, we can find the concurrency relationships using an algorithm from the early days of Process Mining. Experimental tests using artificial event logs showed a good performance in finding unrecorded concurrent relations. However, in some cases, fake concurrences are determined.
This section contains the notions and notation used in the proposal. Concurrency oracles are independent of the process modeling notation. However, we use Petri nets for the running examples, as is customary in the Process Mining literature. Therefore, we began this section by presenting basic definitions of Petri nets. Later, formal definitions of concepts related to Process Mining are presented. Moreover, we recall an algorithm to build a directed acyclic graph from an event log.
marked Petri net. ( , )
′
∈ {0, +1, −1} ||×| | otherwise.
An ordinary Petri net structure is a triple = ( , , ) where is a finite set of places, is a finite set of transitions such that ∩ = ∅ is a set of direct arcs, called the flow relation. A a Petri net structure and 0 ∈ ( ) marked Petri net is a pair ( , 0), where = ( , , ) is is a multi-set over denoting the marking of the net. The elements of multisets will be written between square brackets.
Places in a Petri net structure are drawn as circles, while transitions are drawn as rectangles. The marking of the net is represented by tokens, black dots inside places. Figure 1 shows a Given a Petri net structure = ( , , ) and ∈ ∪ , we call preset of to the set • = { | ( , ) ∈ } . Respectively, the postset of is • = { | (, ) ∈ } . In a marked Petri net , the transition ∈ can be fired , if • ⊆ . The red firing of leads to a new marking = ( \ • ) ⊎ •
. Where \ • ⊎ is the sum of multisets. marking ′. The set of all reachable markings of ( , ) → is the multiset formed by deleting of the elements in • , and ′, denote that being in marking , firing transition led to is denoted by [ , ⟩ .
Given a Petri net structure = ( , , )
. The incidence matrix of is the matrix defined by = −1 if ∈ • ∧ ∉ •, = 1 if ∈ • ∧ ∉ • , and = 0
A -invariant of a Petri net structure = ( , , ) with incidence matrix , is an integer solution to the equation = 0 such that ≥ 0 and ≠ 0. The support of , denoted as ⟨ ⟩ is the set of transitions whose corresponding entries in are strictly = (( × ) ∪ ( × )) ∩ .
Proposition 1 Fundamental property of -invariants Parikh vector ⃖⃗ is a -invariant if → . [13] Let be a finite sequence of transitions of a net which is enabled at a marking . Then the The Proposition 1 results are essential for our goal. This states that after executing all the transitions in a -invariant (including repetitions), we arrive at the same marking from which we started. Thus, a -component is a possible cycle of the net. In Figure 1, the subnet in red is the -component induced by the -invariant [0 1 1 1 0 0]. Definition 2.4 A labelled Petri net is a tuple ( , , , , ) where ( , , ) is a Petri net structure, is a set of activity labels, and ∶ → , a labelling function that assigns activity names to transitions.
In this context, the labels will be the names of the process activities. The rest of the article assumes that no two transitions can have the same label. So, when we say label, transition, or activity, we mean the same thing.
Definition 2.5 Let = ( , , , , ) be a labeled Petri net and a transition not in ∪ . is a workflow net (WF-net) [14] if and only if: 1. contains an input place (source place) such that • = ∅ , 2. contains an output place (sink place) such that • = ∅ , 3. = ( , ∪ { }, ∪ {(, ), ( , )}, ∪ , ∪ {( , )}) is strongly connected.
In Process Mining, it is common to assume that WF nets are ”well-formed”. Specifically, it requires that a WF-net be sound.
Definition 2.6 Let = ( , , , , ) is sound [14] if and only if:
be a WF-net with an input place and an output place . 1. ( , []) is safe, i.e., places cannot hold multiple tokens at the same time; 2. for any marking ∈ [ , []⟩ , ∈ implies = [] ; 3. for any marking ∈ [ , []⟩ , [] ∈ [ , ⟩ ; 4. ( , []) contains no dead transitions.
Events stored in event logs have several attributes, for example, case identifier, name of the activity executed, resources used, information about who performs the activity, start and end date, etc. For our purposes, it is enough to consider that the events have the name of the executed activity and a case identifier. Also, we assume that the events with the same case identifier are in a total order relationship. Thus, we use the following simplified definition of an event log.
Let be a set of activity names. A trace is a finite sequence of elements of . An event log is a set of traces.
An event log may contain noise or behavior that does not belong to the underlying process. However, in this work, we assume that the event logs are noise-free; that is, we consider that the process generated all the recorded behavior. In real-life event logs, this can be a huge assumption. However, there are preprocessing methods that mitigate this problem, for example,
Two essential concepts mentioned briefly in the introduction are the completeness of an event log and the concurrency between activities. Both are based on the direct-follows relation
Let be an event log. is directly followed by , denoted by > , if and only if there is a trace = ⟨ 1, 2, ..., ⟩ and ∈ {1, ..., − 1} such that ∈ and = and +1 = . The set > = {(, ) | , ∈ , >
} is the direct follow relation.
For a Petri net, we can also consider the direct follow relation between transitions. , ′ and ″ of such that 1 → ′ 2 → .
″
Let 1 and 2 transitions of the marked Petri net ( , 0) labeled by , and respectively. We say that is directly followed by if and only if there are reachable markings
Note that, unlike the causal relationship, there is no need for a place connecting the transitions in this case.
Now, the usual definition of completeness is recalled from [
Let be an event log extracted from the WF-net . It is said that is complete if the direct follows relation derived from , coincides with that derived from .
The completeness property is weaker than requiring that all possible traces be in the event log, which is impossible if the Petri net has cycles. However, even this weak definition rarely holds true in real-life settings. Therefore, it would be more meaningful to talk about the rate of completeness rather than completeness.
#( ,→)
Let be an event log extracted from the a WF-net , with at least two transitions. By #(, →) , we denote the number of pairs of activities in direct follow relation concerning . Similarly, #( , →) denotes the number of pairs of activities in direct follow relation concerning . The quotient #(,→) is the rate of completeness of the log with respect to the net .
To the best of our knowledge, the above definition had not been explicitly stated in the literature. However, it was used in [17] to evaluate the rediscovery capability of the algorithm proposed there. The rate of completeness can measure the completeness of an event log. Note that the rate of completeness is 1 only if the log is complete in the usual sense mentioned earlier.
Intuitively, two activities are concurrent if there is neither a causal relationship nor a conflict between them. In a Petri net, we considered that two transitions are concurrent if: Definition 2.12 A pair of transitions labeled by , ∈ are concurrent in the sound WF-net ( , []) if • ∩ • = ∅ , and if there is a marking ∈ [ , []⟩ such that transitions labeled by and can be fired, and after firing one of them, the other one can still be fired.
In agreement with [
Definition 2.13 Let be an event log and the set of activities. If , ∈ concurrent with if > , and > . Concurrency is denoted by || . , we said that is
A formal definition of a concurrency oracle is given in [ 18]. However, it is enough for us to
say that a concurrency oracle is “a black-box Boolean function that asserts whether a given pair
of events are concurrent or not” [
Let be a concurrency oracle. Abusing the notation, we will treat as a family of twoelement sets, such that {, } ∈ ⇔ || . That is, we consider an oracle as the set of pairs of concurrent activities.
In this subsection, we recall one of the earlier works of Process Discovery due to Agrawal et, al. [19]. The goal of that work was not to build a Petri net but a labeled directed graph. In particular, we summarize the second algorithm shown there, which assumes that the traces have no repeated activities. This algorithm is fundamental to our proposal; for this reason, it is described in detail through an example.
Example 1: We illustrate the Agrawal’s algorithm using the log 1 = {⟨, , , ⟩, ⟨, , , ⟩, ⟨, , , ⟩, ⟨, , , ⟩} . (Example 7 of [19])
Firstly, a graph is created with vertices equal to the set of activities ({, , , , , } an empty set of arcs. Then: ) and initially 1. For each trace of 1, the transitive closure of the direct follow relation is added to the set of arcs. The resulting graph is shown in the Figure 2 on the left. 2. Arcs that appear in both directions are removed. In addition, arcs belonging to some strongly connected component of the graph are eliminated too. The resulting graph from step 2 is shown in the Figure 2 in the center. 3. For each trace, the subgraph induced by it is taken, and its transitive reduction is calculated.
Arcs that do not belong to any of these transitive reductions are removed. The resulting graph from step 3 is shown in the Figure 2 on the right.
Figure 3 shows the transitive reductions of the step 3. These graphs are indeed the skeletons of (partial-ordered sets). express Petri net executions as an alternative to traces, although the verification problem (checking if a is executable by a given Petri net) is more complex [20]. In this context, the fact that two vertices are not related is interpreted as the activities involved (their labels) being concurrent. In the Example, (, ) , (, ) , and (, ) are concurrent relationships. Thus, Agrawal’s algorithm is useful to extract concurrency relations between activities from traces. 3. Extracting Concurrency from Incomplete Event Logs
We hypothesize that concurrent relationships between activities within a cycle are not observed when analyzing the event log due to the interleaved occurrence of activities outside the cycle. However, if the part of the traces corresponding to a cycle is isolated, ignoring everything outside the cycle, the previously hidden concurrent relationships become observable. Example 2: Consider the WF-net shown in Figure sitions belonging to cyclic components are colored ors. From this net the following event log is {⟨, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ℎ, , , , ⟩, ⟨, , , , , , , 4 in which with diferent extracted: L2 trancol= , , , , , , , , ℎ, , , , , , , , , , , , , , , ⟩, ⟨, , , , , , , , , , , , , , , ℎ, , , , , , , , , , , , , , , , , , , , , , , ⟩} .
If instead of considering the complete event log, we consider only the projection of the traces on one of the cycles, for example, the pink one, we obtain the traces ′2 = {⟨, , , , , , , , , , , , , , ⟩, ⟨, , , , , , , , , , , , , , , , , , , , , , ⟩, ⟨, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ⟩} . From ′2 we can build an event log with no repeated activities in the traces (splitting the trace just before starting the cycle again). In our exam″ ple, we get the log 2 = {⟨, , , , , , , ⟩, ⟨, , , , , , ⟩, ⟨, , , , , , , ⟩, ⟨, , , , , , , ⟩, ⟨, , , , , , ⟩, ⟨, , , , , , , ⟩, ⟨, , , , , , , ⟩, ⟨, , , , , , , ⟩, ⟨, , , , , , ⟩} .
″
Notice that, 2 fulfill the assumptions of the Agrawal’s algorithm. Hence, we obtain that ( , ) , (, ), (, ) , (, ) , (, ), ( , ), (, ), and (, ) are concurrent relationships. Only the red ones were explicitly recorded.
3.2.1. Support concepts and operators First, some concepts and operators on the event log needed for concurrency extraction are introduced. The concept of repetitive dependency introduced in [21] is also recalled. Definition 3.1 Let be an event log, and ∈ be a trace.
1. The non-repetitive division of , denoted as ( ) , is a set of sub-traces { 1, 2, ..., } such that: • = 1 2⋯ , • 1 is the larger prefix of with no repeated activities, and • for ∈ {2, ..., } , is the larger prefix of without repetition of activities, where = 1⋯ −1 . 2. The non-repetitive event log derived from is () = repetitive divisions of traces in . ⋃ ( ); the union of all non
Notice that the non-repetitive division of a trace is unique; consequently, () for a given and contains traces that have no repeated activities. is unique Example 3: Consider the event log 3 = { 1 = ⟨, , , , , , , , , , , , , , ⟩, , , , , , , , , , , , , , , , , , , ⟩, 3 = ⟨, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ⟩} extracted from WF-net in Figure 4. ( 1) = {⟨, , , , , , , ⟩, ⟨, , , , , , ⟩} ( 3) = {⟨, , , , , , , ⟩, ⟨, , , , , , ⟩, ⟨, , , , , , , ⟩, ⟨, , , , , , , ⟩, ⟨, , , , , , ⟩, ⟨, , , , , , , ⟩, ⟨, , , , , , , ⟩, ⟨, , , , , , , ⟩, ⟨, , , , , , ⟩} 2 = ⟨, , , , .
The next definition was stated in [ 21], and it is the base for computing the -invariants of a Petri net from their language.
Definition 3.2 Let be an event log, with activity names in . An activity is repetitively dependent on , denoted as ≺ if is always observed between two apparitions of in ∈ . If has been observed at least twice in ∈ , then ≺ . The set of transitions from which is repetitively dependent is given by the function () ∶ → 2 ; then () = { | ≺ } . If was observed at most once in each ∈ , then () = ∅ .
The sets () are not -invariant; however, it was shown in [21] that these are included in the support of at least one -invariant, thus representing repetitive parts of the underlying Petri net.
Now, using the introduced concepts, the concurrency oracle can be stated. 3.2.2. General Approach The algorithm is divided into two steps. In the first step, the goal is to build a tree. The idea is that the tree nodes represent the repeating parts of a WF-net. The root node represents the complete WF-net. A WF-net is not a repeating component, but if we add an artificial transition like point 3 of definition 2.5, we can consider it so. Its child nodes are the cycles contained in it that are not contained in other cycles. In turn, the children of these will be their inner cycles until reaching the cycles that do not include any cycle inside, which will be the tree leaves. The non-repeating part of the WF-net also forms a node. For the WF-net in Figure 4, the generated tree is shown in Figure 5.
Of course, we do not have a WF-net in advance. Figure 5 only illustrates the ideal case where we know the cycles. In real cases where we only have one event log, the tree we will build will have traces on the nodes instead of the subnets in Figure 5. To construct the traces corresponding to one cycle, we use the sets () from Definition 3.3.
The second step is to find the concurrency relationships one node at a time. The strategy is to take an in-depth tour. Once a tree leaf is reached, we break the cycles so that the traces generated by them do not have repeated activities. This allows us to find concurrency relationships using Agrawal’s algorithm.
We repeat the same strategy as in the leaves as we go up through the nodes. The diference is that Agrawal’s algorithm can now find concurrences between activities that belong to the child nodes. We resort to a heuristic to decide whether these concurrences are conserved. 3.2.3. Step 1: Building the Tree In sections 3.2.2 and 3.2.3, we described the method using the event log 2 shown above as a running example.
This section shows the first step of our algorithm: the decomposition of a process into its repetitive components and the arrangement of these in the form of a tree. Unlike Figure 5, we do not have a WF-net to extract the cycles from there; all we have is an incomplete event log. We will try with this log to approximate the tree we would obtain if we had a model.
The nodes will contain sets of traces, and we define the root node as the one that contains the original event log, 2.
To find its child nodes, we proceed as follows: we find the first repeated activity in any of the traces; in our example, this activity is . In this case, is the first activity repeated in the first trace, although we could consider any other trace.
This activity represents the “start” of the cycle. We compute the set of activities on which repetitively depends. In our example, this set is ( ) = { , , } . The projection of the traces of 2 onto ( ) , denoted by ( ) ( 2), results in the set: {⟨ , , , , , , , , , , , , , ⟩, ⟨ , ⟩, ⟨ , ⟩} . This set is a child node of the root.
Note that we did approximate the yellow loop (Figure 4) using the repeating dependency. We project the log onto ( ) = { , , } because, as we mentioned when illustrating our hypothesis, we want to leave out all behavior outside of cycles.
Now, we remove from 2 all the activities that appear in ( ) ; the new ”event log” is ′2 = {⟨, , , , , , , , , , , , , , , , , , ℎ, , , , ⟩, ⟨, , , , , , , , , , , , , ℎ, , , , , , , , , , , , , , , ⟩, ⟨, , , , , , , , , , , , , ℎ, , , , , , , , , , , , , , , , , , , , , , , ⟩} .
We proceed in a similar way with the event log ′2. We find the first repeated activity in any of its traces. In this example, the activity is , when we start from the first trace. Although any other trace with repeated activities can be used. We compute () for ′2, resulting: () <= { , , , , , , , } . Now, we project the traces of ′2 onto () , resulting in the set () ( ′2) = {⟨, , , , , , , , , , , , , ⟩, ⟨, , , , , , , , , , , , , , , , , , , , , , ⟩, ⟨, , , , , , , , , , , , , , , , , , , , , , , , , , , , , ⟩} . The projection of the log onto () is another child of the root node. In this case, we approximate the pink cycle using the set () = { , , , , , , , } . 3.2.4. Step 2: Finding concurrency Once the tree is built, we traverse its nodes in depth-first order. Upon reaching a node, the concurrency relations between activities in the traces of that node are extracted as follows: • For leaf nodes, we transform the log contained in the node to a non-repetitive event log (Definition 3.2). The resulting log fulfills the assumptions of the Agrawal algorithm. So, we apply the Agrawal algorithm to this log, and the pairs of concurrent activities returned by the algorithm are added to the set of concurrent relations. • For internal nodes, there is a slight change. Consider an internal node named nd. First, the non-repeating event log is obtained from the log contained in node nd. We applied the Agrawal algorithm to this non-repeating log, but since we are not making any assumptions about the rate of completeness of the log, it is impossible to guarantee that the found concurrency relations are all WF-net concurrences. That is because we are inferring beyond what is recorded. However, we apply the following heuristic rule to decide if a concurrency relationship returned by Agrawal’s algorithm holds in the set of concurrency relationships delivered by our oracle.
If Agrawal’s algorithm returns that and are concurrents, we must consider the following cases: 1. and belong to the set of activities of one of the child nodes of nd. 2. belongs to the set of activities of one child node of nd, and belongs to the set of activities of another diferent child node of nd. 3. belongs to one of the child nodes of nd and to none.
4. neither nor belongs to any of the children nodes of nd.
In the first case, the concurrency between and will be preserved only if it was found when the child node was parsed. If there are concurrency between and , it should have been observed when executing the innermost cycle (deepest node) that contains and . If it was not observed when analyzing the inner cycle, there is no reason why it could be observed in a larger cycle.
In the second case, concurrency is preserved if and only if there is some explicitly observed concurrency (according to definition 2.13) between one of the activities of one node and an activity of the other node. This is because two inner cycles of a third cycle can be concurrent with each other, but they can also be sequential. To ensure that we are not adding false concurrency relationships (which actually are sequential relationships), we require that at least one concurrency relationship has been observed between the activities in the inner loops.
In cases 3 and 4, concurrency is always preserved. The reason is that they are activities inside a cycle with nested cycles, but those activities are in the ”non-repetitive” part of the cycle; that is, they are not inside any of the nested cycles. Therefore, the fact that they appeared in reverse order, as required by Agrawal’s algorithm, is indicative that they are, in fact, concurrent.
Following our example, the first node visited contains the traces {⟨ , , , , , , , , , , , , , ⟩, ⟨ , ⟩, ⟨ , ⟩} . Applying the described procedure, no concurrency relationship was found there, which is consistent with the model.
The second node visited contains the traces {⟨, , , , , , , , , , , , , ⟩, ⟨, , , , , , , , , , , , , , , , , , , , , , ⟩, ⟨, , , , , , , , , , , , , , , , , , , , , , , , , , , , , ⟩} . Applying the procedure, it follows that 1 = { ( , ) , (, ) , (, ), ( , ) , (, ), ( , ) , ( , )} are concurrency relations, which is consistent with the model.
The third node visited contains the traces 2 = {⟨, , , , ℎ, , , , ⟩, ⟨, , , ℎ, , ⟩, ⟨, , , ℎ, , , ⟩} . Applying the procedure, it follows that {(, ) , (, ℎ)} are concurrency relations, which is consistent with the model.
The last node visited contains the original event log. Following the described procedure, it follows that 3 = {(, ), ( , ) , ( , ), (, ), ( , ), (, ), (, ), ( , ), (, ), ( , ), (, ), ( , ), ( , ), ( , ), ( , ), (, ), ( , ), (, )} are concurrency relations, which is consistent with the model.
Therefore, the concurrences returned by our oracle are = 1 ∪ 2 ∪ 3 . Only the red ones are found by the -oracle.
The procedures derived from the proposed method have been implemented as a software tool in Phyton. It is available at https://www.websysmex.online/#/Cesar. The experiments have been performed on eight test cases where artificial logs are obtained from Petri nets with diverse structures; the logs are obtained by executing the modes in the PIPE tool [22].
The reason for using artificial event logs instead of real-life ones is that it is possible to compare the efectiveness of the method to known concurrency relationships in the test PN, which are unknown in real-life event logs. Petri nets and their corresponding event logs are available too at the same site. In the tests, we use event logs with rates of completeness of 30%, 40%, and 50%, approximately. The results of the tests are compared to those of the -oracle.
Below the results of the method are shown for the eight event logs: is the set of pairs of concurrent relations returned by our oracle, is the set of pairs of concurrent relations computed by the -oracle, and || is the set of concurrent relations in the Petri net . found by our method. Analogously, Figure 8 shows | ∩ ||| . As expected, the higher the rate of | ||| completeness of the event log, the higher the percentage of revealed concurrency relationships.
The results achieved by our proposal show that it can extract significantly more concurrency relationships than those explicitly recorded.
However, in no case were they able to reveal the total attendance. Furthermore, the percentage of concurrency relationships found is very similar to the completeness rate for some nets.
Extracting unrecorded concurrency relations would be trivial if overgeneralization did not matter. However, discovering precise models requires that the oracle return as few false concurrency relationships as possible.
Figure 9 shows |∩ ||| , the percentage of concurrency relations of the extracted by our || oracle concerning the total number of relations that the oracle determined as concurrences.
Figure 10 shows the same rate for the -oracle ( | ∩ ||| ).
| |
Our proposal achieved results above 90% for most of the nets, which we consider favorable. However, for Petri net 6, it was found that almost 30% of the relationships that the oracle ”said” were concurrent were not. Therefore, in this case, using our oracle could lead to models with low precision. It is also striking that, in some cases, the higher the completeness rate, the more false matches are obtained. As expected, the alpha oracle gets fewer errors. All -oracle errors are associated with short loops.
This paper proposed a novel approach to building concurrency oracles based on discovering repetitive patterns from the event log. It has been shown in the tests that although the implemented oracle cannot determine all the concurrences, it can infer significantly more concurrency relationships than those straightforwardly determined from the event log. These results are encouraging and show that a concurrency oracle can be helpful when dealing with incomplete logs.
However, a few issues remain before it can be used in real logs. Mainly, the surplus of false concurrency relationships should be mitigated. Heuristic rules like that in step two of our proposal can reduce spurious concurrences. This approach has the advantage of not imposing constraints on the event log; however, for the same reason, it will not be possible to guarantee that all the concurrences found are indeed in the net.
Another approach to solve this issue is to constrain the class of WFNs to be dealt with to find a ”minimum behavior” that the log must hold to ensure that all the concurrency relationships determined by the oracle are true. Although we aim to make the oracle usable in actual environments, we prefer the first option. Our current research goes in that direction. and future directions, in: On The Move to Meaningful Internet Systems 2003: CoopIS, DOA, and ODBASE: OTM Confederated International Conferences, CoopIS, DOA, and ODBASE 2003, Catania, Sicily, Italy, November 3-7, 2003. Proceedings, Springer, 2003, pp. 389–406. [10] H. Ponce-de León, C. Rodríguez, J. Carmona, K. Heljanko, S. Haar, Unfolding-based process discovery, in: Automated Technology for Verification and Analysis: 13th International Symposium, ATVA 2015, Shanghai, China, October 12-15, 2015, Proceedings 13, Springer, 2015, pp. 31–47. [11] J. E. Cook, A. L. Wolf, Event-based detection of concurrency, ACM SIGSOFT Software
Engineering Notes 23 (1998) 35–45. [12] W. Van Der Aalst, A. Adriansyah, A. K. A. De Medeiros, F. Arcieri, T. Baier, T. Blickle, J. C.
Bose, P. Van Den Brand, R. Brandtjen, J. Buijs, et al., Process mining manifesto, in: Business Process Management Workshops: BPM 2011 International Workshops, Clermont-Ferrand, France, August 29, 2011, Revised Selected Papers, Part I 9, Springer, 2012, pp. 169–194. [13] J. Desel, J. Esparza, Free choice Petri nets, 40, Cambridge university press, 1995. [14] W. Van Der Aalst, Process mining: data science in action, volume 2, Springer, 2016. [15] N. Tax, N. Sidorova, W. M. van der Aalst, Discovering more precise process models from event logs by filtering out chaotic activities, Journal of Intelligent Information Systems 52 (2019) 107–139. [16] R. Conforti, M. La Rosa, A. H. ter Hofstede, Filtering out infrequent behavior from business process event logs, IEEE Transactions on Knowledge and Data Engineering 29 (2016) 300–314. [17] T. Tapia-Flores, E. Rodríguez-Pérez, E. López-Mellado, Discovering process models from incomplete event logs using conjoint occurrence classes., in: ATAED@ petri nets/ACSD, 2016, pp. 31–46. [18] D. Reißner, A. Armas-Cervantes, M. La Rosa, Generalization in automated process discovery: A framework based on event log patterns, arXiv preprint arXiv:2203.14079 (2022). [19] R. Agrawal, D. Gunopulos, F. Leymann, Mining process models from workflow logs, in: Advances in Database Technology—EDBT’98: 6th International Conference on Extending Database Technology Valencia, Spain, March 23–27, 1998 Proceedings 6, Springer, 1998, pp. 467–483. [20] G. Juhás, R. Lorenz, J. Desel, Can i execute my scenario in your net?, in: Applications and Theory of Petri Nets 2005: 26th International Conference, ICATPN 2005, Miami, USA, June 20-25, 2005. Proceedings 26, Springer, 2005, pp. 289–308. [21] T. Tapia-Flores, E. López-Mellado, A. P. Estrada-Vargas, J.-J. Lesage, Discovering petri net models of discrete-event processes by computing t-invariants, IEEE Transactions on Automation Science and Engineering 15 (2017) 992–1003. [22] P. Bonet, C. M. Lladó, R. Puijaner, W. J. Knottenbelt, et al., Pipe v2. 5: A petri net tool for performance modelling, in: Proc. 23rd Latin American Conference on Informatics (CLEI 2007), 2007.