Implementation of Basic Inductive Miner

[Kuhlkrypto]

Summary

This Pull request aims to introduce the basic inductive miner to the rust4pm library.
The implementation provides a discovery foundation for the Rust ecosystem that outputs a Process Tree, following the formal definitions of the Inductive Miner in literature.

Motivation

The goal was to write a "true to the source" implementation of the Inductive Miner in Rust, i.e. an implementation that combines the algorithmic ideas and clean recursive structure of the Inductive Miner while benefiting from Rust's memory safety and performance.

Scope of Work

The discovery logic is based on the Inductive Miner as described in Chapter 6.1 in "Robust Process Mining with Guarantees" by Sander J. J. Leemans.
This includes:

• Discovery of all basic Cuts:
  • Exclusive Choice
  • Sequence
  • Parallel
  • Redo Loop
• Base Cases: Empty Log and Single Activity
• Fallthroughs:
  • Empty trace
  • Activity Once per Trace
  • Activity Concurrent
  • Tau Loop (Strict & Standard)
  • Flower Model: final fallback to ensure a sound process model is always returned
• Log Splitting Logic: log partitioning logic for each cut type

Unit Tests and Documentation

Each file contains a test mod containing basic unit test, verifying the correctness of cut detection, log splitting, fallthroughs etc. against test logs. Furthermore, all important functions and structs have been documented with "doc-comments"

Implementation Notes

In some cases the implementation ports logic from the ProM workbench, those files have been marked accordingly.

---

Contributor:
I conducted this work while employed at TU Dresden.

[aarkue]

Hi @Kuhlkrypto,
Thanks for this contribution; the inductive miner would really be a great addition to Rust4PM! 😄
It will likely take a bit of time to review everything. Before that, I also have two small general questions:

1. Have you already validated/tested against the current implementation of the IM in ProM / PM4Py? It would be good to know exactly if there are differences in behavior and what they are. I believe there are also instances where the IM(f) in ProM/PM4Py do not produce the same output.
2. I think direct ports from the ProM IM implementation might be problematic to publish with the MIT/Apache license the Rust4PM project carries. Are those really direct ports or just inspired by the ProM code? There are probably a few different options (e.g., I/someone else does a clean-room implementation of them based on tests/paper specifications only, I/we get permission from the original copyright author, ...) to mitigate this either way, but it would be good to make sure everything is 100% safe.

Thanks again for your work and Cheers,
Aaron

[Kuhlkrypto]

Hey @aarkue
Thanks for your quick feedback! I'm glad to hear you're excited to get the IM into Rust4PM.
To address your questions:

1. I have mainly tested against the PM4Py implementation and to a lesser extent against ProM. I used the Sepsis Case Event Log and there are some differences. The main difference is that my implementation uses the "standard sequence cut", while both Pm4Py and ProM use the strict sequence cut. I also noticed that those implementations seem to detect concurrency a bit earlier than mine. I haven't quite figured out why yet. It could be something internal, such as the fold operation where the tree is compressed, or perhaps something in the split / fallthrough logic.

2. Unfortunately, I ported some logic directly from ProM without giving the MIT / Apache license enough thought at the time. To address this issue, I am willing to rewrite the affected sections and strictly adhere to the pseudocode and logic of the original dissertation, to ensure that everything is 100% safe.

I hope you haven't reviewed too much of the code yet. I'll start rewriting the affected sections, and I'll also take this as an opportunity to see if I can determine why the behavior differs from PM4Py / ProM.

Cheers
Fabian

[Kuhlkrypto]

Hi @aarkue,

sorry for the delay. I reached out to Sander Leemans regarding the ported parts of the implementation and received permission to use/adapt the code, so the licensing situation should now be clarified.

In the meantime, I also added a fold operator for improved simplification/analysis of the resulting process trees and fixed two bugs related to tau handling.

I'll continue looking into the behavioral differences compared to PM4Py/ProM as well.

Cheers,
Fabian

[aarkue]

Hi @Kuhlkrypto,
Nice, thanks! I also spoke with Sander about it briefly, and he is generally open to it, and also willing to give some input/recommendations for the code.
The legalities are unfortunately still not completely out of the picture, as other parties (e.g., universities, employers, etc.) might also have claims on the code.

Thus, my recommended plan would be as follows:

1. You remove the direct-port implementation from your code/the PR, and just leave the type definition/stub of the functions
2. We merge the resulting (partial) implementation in a dedicated branch on Rust4PM
3. We/you/Sander/etc. can work on filling the gaps and updating/improving the code iteratively.

For Step 3, you are, of course, very welcome to continue working on it as well, but don't feel obligated in case you don't want to/have time. Worst case, I or somebody else could also pick it up from there.

How does this sound to you? Would that be an option you'd agree with? If yes, you can go ahead and do 1. and I will take care of setting up 2/3.

Thanks again for your effort, and Cheers,
Aaron