Event Graph of BPI Challenge 2014

Business process event data modeled as labeled property graphsData Format-----------The dataset comprises one labeled property graph in two different file formats.#1) Neo4j .dump formatA 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//bin/neo4j-admin.(bat|sh) load --database=graph.db --from=The .dump was created with Neo4j v3.5.#2) .graphml formatA .zip file containing a .graphml file of the entire graphData Schema-----------The graph is a labeled property graph over business process event data. Each graph uses the following concepts:Event nodes - each event node describes a discrete event, i.e., an atomic observation described by attribute "Activity" that occurred at the given "timestamp":Entity nodes - each entity node describes an entity (e.g., an object or a user), it has an EntityType and an identifier (attribute "ID"):Log nodes - describes a collection of events that were recorded together, most graphs only contain one log node: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: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: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.:HAS relationship - from a :Log to an :Event node, describes which events had been recorded in which event log: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:REL relationship - placeholder for any structural relationship between two :Entity nodesThe 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.14552Data Contents-------------neo4j-bpic14-2021-02-17 (.dump|.graphml.zip)An integrated graph describing the raw event data of the entire BPI Challenge 2014 dataset. van Dongen, B.F. (Boudewijn) (2014): BPI Challenge 2014. 4TU.ResearchData. Collection. https://doi.org/10.4121/uuid:c3e5d162-0cfd-4bb0-bd82-af5268819c35 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. 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.The data contains the following entities and their events- ServiceComponent - an IT hardware or software component in a financial institute- ConfigurationItem - an part of a ServiceComponent that can be configured, changed, or modified- Incident - a problem or issue that occurred at a configuration item of a service component- Interaction - a logical grouping of activities performed for investigating an incident and identifying a solution for the incident- Change - a logical grouping of activities performed to change or modify one or more configuration items- Case_R - a user or worker involved in any of the steps- KM - an entry in the knowledge database used to resolve incidentsData Size---------BPIC14, nodes: 919838, relationships: 6682386# 数据格式 本数据集包含一份带标签属性图（labeled property graph），提供两种不同文件格式。 1. Neo4j .dump 格式 该文件为Neo4j（https://neo4j.com）数据库备份文件，包含完整图结构，可通过以下命令导入至全新Neo4j数据库实例，具体可参考Neo4j官方文档：https://neo4j.com/docs//bin/neo4j-admin.(bat|sh) load --database=graph.db --from= 该.dump文件由Neo4j v3.5版本生成。 2. .graphml 格式 该文件为包含完整图结构的.graphml文件的.zip压缩包。 # 数据模式 本图为面向业务流程事件数据的带标签属性图，各图均采用以下概念模型： - 事件节点（Event nodes）：每个事件节点描述一个离散事件，即由属性"Activity"定义的原子观测行为，发生时间由属性"timestamp"标注。 - 实体节点（Entity nodes）：每个实体节点描述一类实体（如对象或用户），包含实体类型（EntityType）与标识符（属性"ID"）。 - 日志节点（Log nodes）：用于描述一批同步记录的事件集合，多数图仅包含一个日志节点。 - 类别节点（Class nodes）：每个类别节点描述一类已记录的观测行为，例如可被观测到的各类活动；类别节点将事件聚合为同类观测的集合。 - CORR关系：从事件节点指向实体节点，用于描述事件与特定实体的关联关系，一个事件可关联至多多个实体。 - DF关系：即"直接跟随"关系，存在于两个事件节点之间，用于描述某一事件紧随另一事件发生；处于DF关系中的两个事件必须关联至同一实体节点。所有DF关系共同构成有向无环图。 - HAS关系：从日志节点指向事件节点，用于描述某事件日志收录了哪些事件。 - OBSERVES关系：从事件节点指向类别节点，用于描述某事件所属的事件类别，即该图中观测到的具体活动类型。 - REL关系：用于表示任意两个实体节点间的结构化关系的占位符。 以上概念的详细定义可参考：Stefan Esser, Dirk Fahland: Multi-Dimensional Event Data in Graph Databases. CoRR abs/2005.14552 (2020) https://arxiv.org/abs/2005.14552 # 数据内容 neo4j-bpic14-2021-02-17（.dump|.graphml.zip） 本整合图完整描述了BPI挑战赛2014（BPI Challenge 2014）数据集的原始事件数据。 原始数据集来源：van Dongen, B.F. (Boudewijn) (2014): BPI Challenge 2014. 4TU.ResearchData. 数据集集合. https://doi.org/10.4121/uuid:c3e5d162-0cfd-4bb0-bd82-af5268819c35 BPI挑战赛2014背景：与其他ICT企业类似，荷兰合作银行信息技术部（Rabobank Group ICT）需在缩短上市周期的同时，推进愈发频繁的软件版本发布工作。该部门已落地ITIL（信息技术基础设施库，Information Technology Infrastructure Library）流程，并通过变更流程实施此类所谓"计划性变更"。荷兰合作银行信息技术部希望基于事实，深入探究过往变更的影响相关细分问题，以预测未来变更后服务台（Service Desk）与/或IT运维部门的工作负载。本次挑战赛旨在设计可在商业智能（Business Intelligence，BI）环境中落地的（草稿版）预测模型，辅助业务变更管理团队在实施软件版本发布时，降低其对服务台与/或IT运维部门的影响。 我们为本次挑战赛准备了多份匿名化的荷兰合作银行信息技术部相关案例文件，数据源自名为HP Service Manager（惠普服务管理器）的ITIL服务管理工具，以CSV（逗号分隔值，Comma-Separated Values）格式导出，以交互编号、事件编号或变更编号作为案例ID。除案例文件外，我们还提供了与事件案例相关的活动日志，以及一份详解CSV文件数据内容与服务管理工具背景的文档。本数据集的带标签属性图已整合上述全部信息。 本数据集包含以下实体及其对应事件： - ServiceComponent：金融机构中的IT硬件或软件组件 - ConfigurationItem：服务组件中可被配置、变更或修改的部件 - Incident：服务组件的配置项上发生的问题或故障 - Interaction：为调查事件并确定解决方案而执行的一系列活动的逻辑分组 - Change：为变更或修改一个或多个配置项而执行的一系列活动的逻辑分组 - Case_R：参与任意流程步骤的用户或工作人员 - KM：用于解决事件的知识库条目 # 数据规模 BPIC14：节点数919838，关系数6682386