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.
Q: Will Inductive Miner directly follows ever use a flower model fall through?
Hello there,
I am still reading Sander Leemans' thesis, and now I wonder whether Inductive Miner - directly follows would actually ever be forced to fall through to a flower model.
Suppose there is no looping behavior. Then one would always expect to find an XOR or sequence cut.
Suppose there is looping behavior, and one can find neither a loop nor a parallel cut. Then ex hypothesi strictDfgTauLoop or dfgTauLoop would apply, until there is no more looping behavior.
Am I correct? I have not been able to construct a counterexample to my reasoning. There is no example in Sander's thesis either, as far as I can see. Perhaps I have overlooked it.
-- Sebastian
I am still reading Sander Leemans' thesis, and now I wonder whether Inductive Miner - directly follows would actually ever be forced to fall through to a flower model.
Suppose there is no looping behavior. Then one would always expect to find an XOR or sequence cut.
Suppose there is looping behavior, and one can find neither a loop nor a parallel cut. Then ex hypothesi strictDfgTauLoop or dfgTauLoop would apply, until there is no more looping behavior.
Am I correct? I have not been able to construct a counterexample to my reasoning. There is no example in Sander's thesis either, as far as I can see. Perhaps I have overlooked it.
-- Sebastian
Comments
-
I also see that the ProM coding in
org.processmining.plugins.inductiveminer2.withoutlog.variants.MiningParametersIMWithoutLog
specifies the basic fall throughs FallThroughWithoutLogTauLoopStrict() and FallThroughWithoutLogFlowerWithoutEpsilon().This is different from what is said in the thesis: The coding does not use dfgTauLoop at all, but instead falls back to the flower model.As it is not so described in the thesis, this must be a more recent insight. What is the reasoning behind preferring the flower model to dfgTauLoop? -
I can think of one reason: Removing every incoming edge of a start node might delete very many edges. (In particular when two start nodes are bidirectionally connected, both edges will be removed.) This might lead to DFGs where unwarranted XOR cuts are found, so that using the flower model instead is closer to the original almost-concurrency.
Does that sound plausible? -
Well, no it doesn't, because a tau loop over a disjunction is just a flower model. So is the reasoning that in many cases dfgTauLoop would produce a flower model anyway, and it's just safer or more efficient to use flowerModel directly? I'm still not sure whether there are cases in which IMD-D does not find a cut and applying dfgTauLoop would be undesirable.
-
I'd like to partially answer my own question: A DFG where IM-D will not apply a cut and not apply strictDfgTauLoop can be derived from log L100 on page 221.
A DFG with start nodes a, b, c and end nodes e, g and the following edges will do:
(c,d), (d,e), (e,f), (f,d), (b,a), (a,d), (a,b), (b,d), (c,g)
dfgTauLoop would also not apply to this log.
So: I would still like to know why dfgTauLoop is not used by IM-D in ProM 6.10. Is it, because it is either always the case that it would result in a flower model if it did apply, or it would not apply at all. This would indeed a reason why it is useless. As it is not stated in Leemans' thesis, is there a paper or note mentioning this anywhere?
Howdy, Stranger!
Categories
- 1.6K All Categories
- 45 Announcements / News
- 225 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
- 394 - Usage
- 288 - Development
- 9 RapidProM
- 1 - Usage
- 7 - Development
- 54 ProM5
- 19 - Usage
- 187 Event Logs
- 32 - ProMimport
- 75 - XESame