过程挖掘（Process Mining）5——事件日志（Event Logs）（2）：XES数据标准

本文介绍事件日志的存储标准。

MXML

在2010年之前，事件日志的存储和交换的标准是MXML（Mining eXtensible Markup Language），这个标准出现于2013年，并且被流程挖掘工具ProM采用。

XES

由于MXML对标准类型存在严格定义，以及扩展的局限性，在实践中展现了很多不足，于是提出了更好的标准XES。XES是MXML的继承者，XES格式具有更少的约束并且是真正可扩展的（less restrictive and truly extensible），这个标准已于2010年被IEEE流程挖掘工作小组采用，成为流程挖掘的事件日志的IEEE标准。
XES标准的概念和元素可以用下面的UML类图体现

日志Log、行迹Trace、事件Event

这三个是事件日志的三级结构，前面文章已经介绍得很详细。

属性Attribute

属性是对日志log、行迹trace和事件event的描述，从图中我们可以看到属性定义在这三种元素中。属性的数据值类型有String、Date、Int、Float和Boolean，从图中我们也可以看到XES支持属性嵌套（复合属性）。属性的key可以说是引用属性的值，比如说属性名（name，timestamp）。
一种特殊属性是全局属性global attributes，可以定义在行迹或者事件之上，当我们定义了全局属性，那么被定义的元素就必须包含这个属性，

扩展Extensions

扩展属性是预先定义好的，对事件日志中属性的规范（像是能够成为约定成俗的属性）。XES定义了一些标准扩展：
· concept扩展：是对行迹和事件的name属性的定义
· time扩展：是对事件时间戳属性的定义。
还有organizational扩增、life-cycle扩展等。

分类器Classifier

分类器是一个包含属性集合的工具，它根据这些属性集合及其取值，对事件进行分类。在流程发现中，通常使用事件的name属性作为分类器，以进行流程模型的挖掘。

下面给出XES文件片段，有XML基础的应该很容易看懂：

<?xml version="1.0" encoding="UTF-8" ?>
	<extension name="Concept" prefix="concept" uri="http://.../concept.xesext"/>
	<extension name="Time" prefix="time" uri="http://.../time.xesext"/>
	<extension name="Organizational" prefix="org" uri="http://.../org.xesext"/>
	<global scope="trace">
		<string key="concept:name" value="name"/>
	</global>
	<global scope="event">
		<date key="time:timestamp" value="2010-12-17T20:01:02.229+02:00"/>
		<string key="concept:name" value="name"/>
		<string key="org:resource" value="resource"/>
	</global>
	<classifier name="Activity" keys="concept:name"/>
	<classifier name="Resource" keys="org:resource"/>
	<classifier name="Both" keys="concept:name org:resource"/>
	<trace>
		<string key="concept:name" value="1"/>
		<event>
			<string key="concept:name" value="register request"/>
			<string key="org:resource" value="Pete"/>
			<date key="time:timestamp" value="2010-12-30T11:02:00.000+01:00"/>
			<string key="Event_ID" value="35654423"/>
			<string key="Costs" value="50"/>
		</event>
		<event>
			<string key="concept:name" value="examine thoroughly"/>
			<string key="org:resource" value="Sue"/>
			<date key="time:timestamp" value="2010-12-31T10:06:00.000+01:00"/>
			<string key="Event_ID" value="35654424"/>
			<string key="Costs" value="400"/>
		</event>
		<event>
			<string key="concept:name" value="check ticket"/>
			<string key="org:resource" value="Mike"/>
			<date key="time:timestamp" value="2011-01-05T15:12:00.000+01:00"/>
			<string key="Event_ID" value="35654425"/>
			<string key="Costs" value="100"/>
		</event>
		<event>
			<string key="concept:name" value="decide"/>
			<string key="org:resource" value="Sara"/>
			<date key="time:timestamp" value="2011-01-06T11:18:00.000+01:00"/>
			<string key="Event_ID" value="35654426"/>
			<string key="Costs" value="200"/>
		</event>
		<event>
			<string key="concept:name" value="reject request"/>
			<string key="org:resource" value="Pete"/>
			<date key="time:timestamp" value="2011-01-07T14:24:00.000+01:00"/>
			<string key="Event_ID" value="35654427"/>
			<string key="Costs" value="200"/>
		</event>
	</trace>
	<trace>
		<string key="concept:name" value="2"/>
		<event>
			<string key="concept:name" value="register request"/>
			<string key="org:resource" value="Mike"/>
			<date key="time:timestamp" value="2010-12-30T11:32:00.000+01:00"/>
			<string key="Event_ID" value="35654483"/>
			<string key="Costs" value="50"/>
		</event>
		...
	</trace>
	...
</log>

OpenXES

OpenXES是XES标准的参考实现，它是基于java的。
OpenXES的主页：http://www.xes-standard.org/openxes/start
下载：http://www.xes-standard.org/openxes/download#openxes_226
开发者指导文档：http://www.xes-standard.org/openxes/developerguide
Javadoc：http://ais-hudson.win.tue.nl:8080/view/XES/job/OpenXES/javadoc/

博主@李明子的几个文章对其进行了介绍：
专栏
OpenXES开源库介绍
基于OpenXES的XES反序列化源码示例
基于OpenXES的XES序列化源码示例

关于XES和OpenXES先介绍这么多（看了上面已经满足了操作xes的基本要求了），后续有空再补充。

提取事件日志面临的挑战

• 关联/事件关联
  当定义了事件，事件数据的形成可能散布在多个数据库和系统中，如何识别事件关联的数据并将它们整合起来形成事件数据是一个问题。
  这个问题可以说是现在对流程挖掘日趋见长的需求和事件日志存储规范和标准的形成和符合的不足之间的矛盾。最好是从现在开始定义好一个事件，并对流程事件进行存储。
• 时间戳
  事件是有顺序的，然后不同系统之间的时钟选择和时延的存在，使得确定事件发生的时间和顺序称为一个挑战。
• 快照
  事件日志的记录可能只是一段时间的快照，这就使得有些案例的记录可能有头无尾、有尾无头或者无头无尾，怎样处理这样的数据是个问题。
• 范围
  事件日志存储的数据的跨度要多大？比如对一个组织，哪些部门、哪些数据库、哪些表以及哪些属性需要被记录下来，以避免所存储的数据范围过小（不足以分析）或者过大（耗费更多的存储空间）。这可能需要领域知识和业务需要的分析。
• 粒度
  事件日志中的事件的粒度可能有多种级别，跟我们的业务和用户关联有关，怎么决定存储的粒度也是需要考虑的问题。