# DataStream XES Extension: Embedding IoT Sensor Data into Extensible Event Stream Logs
## 2 Foundations and Related Work
### Process Mining  
One technique to analyze IoT sensor data together with related event data is process mining. Process mining describes three analysis tasks. The most common is (i) process discovery. Discovery techniques take an event log and produce a process model depicting the process executed in the log [5; 6]. The second task is (ii) conformance checking, which is used to verify the conformance of real process instances to a given a-priori model. The last analysis task is (iii) enhancement that uses an event log and the associated process model to identify bottlenecks and to improve the process accordingly [5]. All tasks require an event log as input. Many proposals have been made in the past for storing event logs. The first was MXML, as a simple XML format for audit and trails in process-aware information systems [37]. XES, the current standard event log model, is also based on XML and widely used in both industrial and academic contexts [7; 38]. An XES event log can contain one or more traces. Each trace represents a process instance. A trace, in turn, consists of the sequence of executed activities, each represented by an event. Furthermore, event logs can store additional attributes, such as resources and data elements [39]. An XES attribute consist of (a) a data type represented by the qualified name of the XML element, (b) a key to denote the type of attribute (unique within its container), and (c) a value (see Listing 1). XES describes six types of attributes: string, date, int, float, boolean and id which have a value, as well as two additional attributes, container and list, which can hold arbitrary child attributes. All attributes can also be nested (even inside non-container and non-list attributes) [7]. ```
1<logxes.version=\"1.0\"
2 xmls=\"[[http://www.xes-standard.org](http://www.xes-standard.org)]([http://www.xes-standard.org](http://www.xes-standard.org))\"
33.res.cercer=\"cpe.org\"
4 xes.features=\"nested-attributes\">
5<extensionname=\"Concept\"prefix=\"concept\"uri=\"[[http://www.xes-standard.org/concept.xesext](http://www.xes-standard.org/concept.xesext)]([http://www.xes-standard.org/concept.xesext](http://www.xes-standard.org/concept.xesext))\"/>
6<extensionname=\"Lifecycle\"prefix=\"lifecycle\"uri=\"[[http://www.xes-standard.org/lifecycle.xesext](http://www.xes-standard.org/lifecycle.xesext)]([http://www.xes-standard.org/lifecycle.xesext](http://www.xes-standard.org/lifecycle.xesext))\"/>
7<extensionname=\"Identity\"prefix=\"identifier\"uri=\"[[http://www.xes-standard.org/identity.xesext](http://www.xes-standard.org/identity.xesext)]([http://www.xes-standard.org/identity.xesext](http://www.xes-standard.org/identity.xesext))\"/>
8<extensionname=\"Time\"prefix=\"time\"uri=\"[[http://www.xes-standard.org/time.xesext](http://www.xes-standard.org/time.xesext)]([http://www.xes-standard.org/time.xesext](http://www.xes-standard.org/time.xesext))\"/>
9<globalscope=\"trace\">
10<stringkey=\"concept:name\"value=\"name\"/>
11</global>
12<globalscope=\"event\">
13<stringkey=\"concept:name\"value=\"name\"/>
14<stringkey=\"lifecycle:transition\"value=\"start\"/>
15<datekey=\"time:timestamp\"value=\"1970-01-01T00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:0:00:00:0:00:0:00:0:0:0:0:0:0:0:0:0:0:0:0:0:0:



noticeable difference with XES is the explicit inclusion of the concept of activity in OCEL, which is absent in XES [42]. When representing a process execution into the OCEL format, information about traces, events, or the overall sequence of steps is only available implicitly, by linking together the models of each object. This means that information is potentially lost, and ambiguities regarding the process model might appear. While theoretically, it is possible to define an object type corresponding to an overall case as understood in XES, it is non-standard and therefore not automatically analyzable. In this case, XES is still a better fit.