DOI: 10.4121/14169494
title: Event Graph of BPI Challenge 2014

description: Business process event data modeled as labeled property graphs<br><br>Data Format<br>-----------<br><br>The dataset comprises one labeled property graph in two different file formats.<br><br>#1) Neo4j .dump format<br><br>A neo4j (https://neo4j.com) database dump that contains the entire graph and can be imported into a fresh neo4j database instance using the following command, see also the neo4j documentation: https://neo4j.com/docs/<br><br>/bin/neo4j-admin.(bat|sh) load --database=graph.db --from=<br><br>The .dump was created with Neo4j v3.5.<br><br>#2) .graphml format<br><br>A .zip file containing a .graphml file of the entire graph<br><br><br>Data Schema<br>-----------<br><br>The graph is a labeled property graph over business process event data. Each graph uses the following concepts<br><br>:Event nodes - each event node describes a discrete event, i.e., an atomic observation described by attribute "Activity" that occurred at the given "timestamp"<br><br>:Entity nodes - each entity node describes an entity (e.g., an object or a user), it has an EntityType and an identifier (attribute "ID")<br><br>:Log nodes - describes a collection of events that were recorded together, most graphs only contain one log node<br><br>:Class nodes - each class node describes a type of observation that has been recorded, e.g., the different types of activities that can be observed, :Class nodes group events into sets of identical observations<br><br>:CORR relationships - from :Event to :Entity nodes, describes whether an event is correlated to a specific entity; an event can be correlated to multiple entities<br><br>:DF relationships - "directly-followed by" between two :Event nodes describes which event is directly-followed by which other event; both events in a :DF relationship must be correlated to the same entity node. All :DF relationships form a directed acyclic graph.<br><br>:HAS relationship - from a :Log to an :Event node, describes which events had been recorded in which event log<br><br>:OBSERVES relationship - from an :Event to a :Class node, describes to which event class an event belongs, i.e., which activity was observed in the graph<br><br>:REL relationship - placeholder for any structural relationship between two :Entity nodes<br><br>The concepts a further defined in Stefan Esser, Dirk Fahland: Multi-Dimensional Event Data in Graph Databases. CoRR abs/2005.14552 (2020) https://arxiv.org/abs/2005.14552<br><br><br>Data Contents<br>-------------<br><br>neo4j-bpic14-2021-02-17 (.dump|.graphml.zip)<br><br>An integrated graph describing the raw event data of the entire BPI Challenge 2014 dataset. <br>van Dongen, B.F. (Boudewijn) (2014): BPI Challenge 2014. 4TU.ResearchData. Collection. https://doi.org/10.4121/uuid:c3e5d162-0cfd-4bb0-bd82-af5268819c35 <br><br>BPI Challenge 2014: Similar to other ICT companies, Rabobank Group ICT has to implement an increasing number of software releases, while the time to market is decreasing. Rabobank Group ICT has implemented the ITIL-processes and therefore uses the Change-proces for implementing these so called planned changes. Rabobank Group ICT is looking for fact-based insight into sub questions, concerning the impact of changes in the past, to predict the workload at the Service Desk and/or IT Operations after future changes. The challenge is to design a (draft) predictive model, which can be used to implement in a BI environment. The purpose of this predictive model will be to support Business Change Management in implementing software releases with less impact on the Service Desk and/or IT Operations. We have prepared several case-files with anonymous information from Rabobank Netherlands Group ICT for this challenge. The files contain record details from an ITIL Service Management tool called HP Service Manager. <br><br>The original data had the information as extracts in CSV with the Interaction-, Incident- or Change-number as case ID. Next to these case-files, we provide you with an Activity-log, related to the Incident-cases. There is also a document detailing the data in the CSV file and providing background to the Service Management tool. All this information is integrated in the labeled property graph in this dataset.<br><br>The data contains the following entities and their events<br><br>- ServiceComponent - an IT hardware or software component in a financial institute<br>- ConfigurationItem - an part of a ServiceComponent that can be configured, changed, or modified<br>- Incident - a problem or issue that occurred at a configuration item of a service component<br>- Interaction - a logical grouping of activities performed for investigating an incident and identifying a solution for the incident<br>- Change - a logical grouping of activities performed to change or modify one or more configuration items<br>- Case_R - a user or worker involved in any of the steps<br>- KM - an entry in the knowledge database used to resolve incidents<br><br><br>Data Size<br>---------<br><br>BPIC14, nodes: 919838, relationships: 6682386<br><br>