About Precisely a week ago I read the ‘How to Get Started With Prom‘ blog post on the Fluxicon Blog (err, ‘Capacitor‘). In this blog post Anne explains how an event log can be constructed, using Nitro in this case, then inspected and finally how a process model can be mined and animated using ProM. Overall, the blog post is very nice, as are all posts at the Fluxicon Blog.

There is however one thing I noticed when I was half-way the post: they use ProM 5! At first I thought, why? I mean, ProM 6 is ProM 6 after all, it’s not 4.5, it’s not 5.3, it’s 6! Therefore, it should be better than 5. Furthermore, Fluxicon, especially Christian, had a great influence in the development of ProM 6: Christian designed the new slick user interface of ProM 6 and also developed XES, the new event log standard on which ProM 6 is based (with backward compatibility with MXML which is used in ProM 5). Furthermore, ProM 6 uses ‘packages’ to wrap plug-ins. Packages can be installed and updated independently of the framework therefore allowing plug-ins to be updated by the authors independently of the release cycle of ProM 6.

So, I wondered, why explain new users how ProM 5 works? Shouldn’t you point them to ProM 6? Let them use the newest process mining tool, the state-of-the-art, with all its improvements. I’m not saying that ProM 5 is bad, of course not, but ProM 6 is better. Or is it?

Of course, I could have emailed Anne this question and I would have received a reply but I want to make this a public discussion. Why/when would you use ProM 5 instead of ProM 6?

Well, I can give a couple of reasons but I would sure like to know yours. And, of course, especially Anne’s reasons for introducing ProM 5 to our new process miners instead of ProM 6.

So, in summary, I believe that the benefits of ProM 6 compared to ProM 5 are:

• Better graphical interface which is nicer than the one of ProM 5. The main new feature of the GUI of ProM 6, in my opinion, is that it’s object based. A plug-in requires certain object (types) and produces certain others. This allows for dynamic ‘chaining’ of plug-ins, each plug-in taking the analysis one step further;
• Separation between plug-in and ProM 6 framework. You can choose which plug-ins / packages to install and updates can be made more frequent and independent of the ProM 6 framework updates;
• Support for the new XES event log format but also still supporting the well-known MXML format;
• Separation of GUI and execution, if a plug-in crashes the framework keeps running in most cases. Furthermore, it also allows for easier ‘grid deployment’ than ProM 5;

However, at the moment, ProM 5 has more (how much more?) plug-ins to offer. Each ProM 5 plug-in needs to be updated by the author (or a student) in order to run in ProM 6. So if you plan to do sophisticated analysis you might want to keep ProM 5 installed.

To conclude, I think that new process miners should be introduced to ProM 6. The usability is better than that of ProM 5 although for both you need a learning period.
For those more advanced in process mining it is necessary to switch between ProM 5 and ProM 6, depending on the type of analysis you want to perform. Hopefully most of the ProM 5 plug-ins will find their way, some with improvements, to ProM 6.

But, that’s only my opinion, what do you think? Do you think ProM 6 can replace ProM 5 yet? Do you point a new process miner to ProM 5 or ProM 6? And did I miss any (dis)advantages???
Let me know either in a comment on this post, the post at the Fluxicon Capacitor or maybe in a dedicated discussion on LinkedIn.

Looking forward to your opinions!!!

Joos

This article was first published on Blog of Joos Buijs: ProM 5 versus ProM 6.