To prevent spam users, you can only post on this forum after registration, which is by invitation. If you want to post on the forum, please send me a mail (h DOT m DOT w DOT verbeek AT tue DOT nl) and I'll send you an invitation in return for an account.
Inductive mining: Rules for embedding optionality under parallelism
It is unclear to me what rule the inductive miner directly-follows in ProM 6 (IMd) follows in order to decide whether sub trees embedded under a parallel operator should be optional, i. e. embedded under an XOR(tau,...) construct.
The current behavior seems a bit inconsistent. I have not found anything about this in Sander Leemans' thesis, which I regard as the specification of this plugin.
I'm asking for clarification of the rule that IMd follows here. Consider the following log involving parallelism over activities a and b:
<a,b>
<b,a>
<a>
<b>
Plugin Inductive Miner directly follows generates the process tree PARA(a,b). Although from looking at the log one might prefer PARA(XOR(a,tau),XOR(b,tau)), the simpler solution is correct because the directly-follows graphs of those two process trees are indistinguishable.
Now let's replace the single tasks with embedded self-loops:
<a,b>
<b,a>
<a,a>
<b,b>
From IMd's behavior in the previous example I would have expected the tree PARA(LOOP(a,tau),LOOP(b,tau)).
But in this case, although the process trees are again undistinguishable, ProM decides to make the construct embedded under the parallel gateway optional, giving us PARA(XOR(LOOP(a,tau),tau),XOR(LOOP(b,tau),tau)).
I can't see what might cause this difference in behavior. There must be some rule about cut detection, log splitting or tree normalization that explains this surprising inconsistency, but I can't find it. Can anyone point it out to me?
Best Regards,
Sebastian
The current behavior seems a bit inconsistent. I have not found anything about this in Sander Leemans' thesis, which I regard as the specification of this plugin.
I'm asking for clarification of the rule that IMd follows here. Consider the following log involving parallelism over activities a and b:
<a,b>
<b,a>
<a>
<b>
Plugin Inductive Miner directly follows generates the process tree PARA(a,b). Although from looking at the log one might prefer PARA(XOR(a,tau),XOR(b,tau)), the simpler solution is correct because the directly-follows graphs of those two process trees are indistinguishable.
Now let's replace the single tasks with embedded self-loops:
<a,b>
<b,a>
<a,a>
<b,b>
From IMd's behavior in the previous example I would have expected the tree PARA(LOOP(a,tau),LOOP(b,tau)).
But in this case, although the process trees are again undistinguishable, ProM decides to make the construct embedded under the parallel gateway optional, giving us PARA(XOR(LOOP(a,tau),tau),XOR(LOOP(b,tau),tau)).
I can't see what might cause this difference in behavior. There must be some rule about cut detection, log splitting or tree normalization that explains this surprising inconsistency, but I can't find it. Can anyone point it out to me?
Best Regards,
Sebastian
Howdy, Stranger!
Categories
- 1.6K All Categories
- 45 Announcements / News
- 224 Process Mining
- 6 - BPI Challenge 2020
- 9 - BPI Challenge 2019
- 24 - BPI Challenge 2018
- 27 - BPI Challenge 2017
- 8 - BPI Challenge 2016
- 68 Research
- 1K ProM 6
- 393 - Usage
- 287 - Development
- 9 RapidProM
- 1 - Usage
- 7 - Development
- 54 ProM5
- 19 - Usage
- 187 Event Logs
- 32 - ProMimport
- 75 - XESame