Blog Posts

An Introduction to the XES Standard

One of the goals of the IEEE Task Force on Process Mining, where Fluxicon is a member, is to promote the use of process mining techniques and tools. In my opinion, an important aspect of that is the existence of common and widely-accepted standards. A standard gives users the assurance that they will not have to settle for, and become locked into, the proprietary formats of one vendor.

In process mining, arguably the most important thing to standardize is the data format for event logs. So far, this standard has been the venerable MXML format. However, MXML is clearly showing its age, in that it imposes quite severe restrictions on what kind of information can – and what cannot – be contained in an event log.

One of my last projects at Eindhoven University of Technology was to define a new event log format to address these problems, eventually resulting in the new XES standard1. XES is an XML-based format, and its name is an acronym for eXtensible Event Stream. In designing the XES standard, we have used these four guiding principles, which also nicely summarize its main benefits:

While XES takes a lot of inspiration and some well-proven concepts from MXML, it is also radically different in some aspects. The data meta-model for XES, as an UML 2.0 class diagram, looks like this:

XES maintains the general structure of an event log: A log (corresponding to a process) contains a set of traces (i.e., specific execution instances), which in turn each contain a sequence of events. Each of these three concepts can contain an arbitrary set of attributes, which hold the actual data.

In addition to the fact that all attributes are now considered equal (i.e., there are no “special fields” like “originator” anymore), more importantly they are now strongly typed. In addition to strings, attributes can now also alternatively contain date (i.e., timestamp), integer, floating-point, or boolean values. These additional types greatly increase the expressivity of the format, making it easier to store (meta-)data of process execution, like e.g. the cost of an activity.

So, if there are no longer dedicated, “special”, fields for the activity name or the actor, how do you know what a specific attribute actually means, i.e., how to attach semantics to that data? For this purpose XES introduces the concept of extensions. An extension defines a number of standardized attributes for each level in the hierarchy (e.g., log, trace, even attributes), together with their type (e.g., string, boolean) and their specific attribute keys.

Initially, the XES standard comes with a number of standard extensions. Some examples are:

If an XES log uses these standard extensions, their attributes can be correctly interpreted by the application using this data (e.g., a process mining algorithm)2. However, if a log describes a process in a very specific domain, or from a specific system, you can also easily define your own domain-specific extension. And, of course, additional attributes (that are not defined by any extension) are always allowed3.

People familiar with MXML probably know this problem: You have a log which describes a process on a number of levels of abstraction. If you now convert that log to MXML, you have to pick which of these levels to use, i.e. what to put in the “WorkflowModelElement” attribute. Typically, people have resolved this issue by converting the log to multiple MXML files, one for each level of abstraction.

The XES standard introduces the concept of event classifiers, which makes the workaround described above obsolete. A classifier simply defines a set of event attributes (by their attribute keys) which define the identity of an event. This means that, if two events have the same values for each of these attributes, they are considered equal4. So, if you have an event log with multiple levels of abstraction, you can now convert it only once, with all relevant information in the events’ attributes, and simply add a classifier for each level of abstraction.

That much for why XES was sorely needed as an updated event log standard, and I hope that I could convince you of its benefits. The great news is that the IEEE Task Force on Process Mining agrees, and has accepted XES as the new standard for event logs.

This means that we can hopefully expect more and more tools to support XES going forward, generating a more level and competitive playing field for process mining tools, and also more security for investments in process mining. Currently, the following tools support the XES standard:

You can find a lot more information about the XES standard, the OpenXES reference implementation, and developer resources on the XES Standard website. I especially recommend the XES Standard Definition draft, which goes into way more detail about everything you may want to know about XES.

We hope that XES will spread widely and quickly, and we are convinced that it plays an important part in making process mining available to more people. If you would like me to write more on any specific feature or aspect of the XES standard, please let me know in the comments!

  1. While I was leading these efforts, of course many other people have played an important role. XES would not be what it is today without the crucial feedback from Wil van der Aalst, Boudewijn van Dongen, Eric Verbeek, Peter van den Brand, Joos Buijs, and many others. ↩︎

  2. This makes it possible that e.g. a social network miner “knows” which attributes to use for building its social network ↩︎

  3. Of course, this presents the potential downside that a reading application may not know what to do with them ↩︎

  4. Equal in the sense that they refer to the same concept, e.g. the same activity in a process ↩︎

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples