2,040 research outputs found
Event Data and Queries for Multi-Dimensional Event Data in the Neo4j Graph Database
No full textData model and generic query templates for translating and integrating a set of related CSV event logs into a single event graph for as used in https://dx.doi.org/10.1007/s13740-021-00122-1 Provides input data for 5 datasets (BPIC14, BPIC15, BPIC16, BPIC17, BPIC19) Provides Python scripts to prepare and import each dataset into a Neo4j database instance through Cypher queries, representing behavioral information not globally (as in an event log), but locally per entity and per relation between entities. Provides Python scripts to retrieve event data from a Neo4j database instance and render it using Graphviz dot. The data model and queries are described in detail in: Stefan Esser, Dirk Fahland: Multi-Dimensional Event Data in Graph Databases (2020) https://arxiv.org/abs/2005.14552 and https://dx.doi.org/10.1007/s13740-021-00122-1 Fork the query code from Github: https://github.com/multi-dimensional-process-mining/graphdb-eventlogs {"references": ["Stefan Esser, Dirk Fahland: Multi-Dimensional Event Data in Graph Databases (2020). arXiv: 2005.14552, https://arxiv.org/abs/2005.14552", "Esser, Stefan. (2020, February 19). A Schema Framework for Graph Event Data. Zenodo. https://doi.org/10.5281/zenodo.3820037", "Esser, S., Fahland, D.: Storing and querying multi-dimensional process event logs usinggraph databases. In: C.D. Francescomarino, R.M. Dijkman, U. Zdun (eds.) BusinessProcess Management Workshops - BPM 2019 International Workshops, Vienna, Austria,September 1-6, 2019, Revised Selected Papers,Lecture Notes in Business InformationProcessing, vol. 362, pp. 632\u2013644. Springer (2019). https://doi.org/10.1007/978-3-030-37453-2_51"]
Results of Multi-Perspective Concept Drift Detection on BPIC17 data using Event Knowledge Graphs
No full textExtensive results of multi-perspective concept drift detection performed on the BPI Challenge 2017 dataset retrieved using the related implementation from Github: https://github.com/multi-dimensional-process-mining/ekg-bpic17-concept-drift-detection-multi-perspectiv
Event Graph of BPI Challenge 2015
No full textBusiness process event data modeled as labeled property graphs Data Format ----------- The dataset comprises one labeled property graph in two different file formats. #1) Neo4j .dump format 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/ /bin/neo4j-admin.(bat|sh) load --database=graph.db --from= The .dump was created with Neo4j v3.5. #2) .graphml format A .zip file containing a .graphml file of the entire graph Data 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 nodes 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 Data Contents ------------- neo4j-bpic15-2021-02-17 (.dump|.graphml.zip) An integrated graph describing the raw event data of the entire BPI Challenge 2015 dataset. van Dongen, B.F. (Boudewijn) (2015): BPI Challenge 2015. 4TU.ResearchData. Collection. https://doi.org/10.4121/uuid:31a308ef-c844-48da-948c-305d167a0ec1 This data is provided by five Dutch municipalities. The data contains all building permit applications over a period of approximately four years. There are many different activities present, denoted by both codes (attribute concept:name) and labels, both in Dutch (attribute taskNameNL) and in English (attribute taskNameEN). The cases in the log contain information on the main application as well as objection procedures in various stages. Furthermore, information is available about the resource that carried out the task and on the cost of the application (attribute SUMleges). The processes in the five municipalities should be identical, but may differ slightly. Especially when changes are made to procedures, rules or regulations the time at which these changes are pushed into the five municipalities may differ. Of course, over the four year period, the underlying processes have changed. The municipalities have a number of questions, namely: What are the roles of the people involved in the various stages of the process and how do these roles differ across municipalities? What are the possible points for improvement on the organizational structure for each of the municipalities? The employees of two of the five municipalities have physically moved into the same location recently. Did this lead to a change in the processes and if so, what is different? Some of the procedures will be outsourced from 2018, i.e. they will be removed from the process and the applicant needs to have these activities performed by an external party before submitting the application. What will be the effect of this on the organizational structures in the five municipalities? Where are differences in throughput times between the municipalities and how can these be explained? What are the differences in control flow between the municipalities? There are five different log files available in this collection. Events are labeled with both a code and a Dutch and English label. Each activity code consists of three parts: two digits, a variable number of characters, and then three digits. The first two digits as well as the characters indicate the subprocess the activity belongs to. For instance ‘01_HOOFD_xxx’ indicates the main process and ‘01_BB_xxx’ indicates the ‘objections and complaints’ (‘Beroep en Bezwaar’ in Dutch) subprocess. The last three digits hint on the order in which activities are executed, where the first digit often indicates a phase within a process. Each trace and each event, contain several data attributes that can be used for various checks and predictions. Furthermore, some employees may have performed tasks for different municipalities, i.e. if the employee number is the same, it is safe to assume the same person is being identified. The data contains the following entities and their events - Application - a building permit application handled in one of five Dutch municipalities - Case_R - a user or worker involved in handling the application - Responsible_actor - a user or worker designated as responsible actor for an activity - monitoringResource - a user or worker designated as monitoring resource for an activity The data contains 5 event log nodes as the data was integrated from 5 different event logs from 5 different systems. Data Size --------- BPIC15, nodes: 268851, relationships: 262041
Automatic discovery of data-centric and artifact-centric processes
No full textProcess discovery is a technique that allows for automatically discovering a process model from recorded executions of a process as it happens in reality. This technique has successfully been applied for classical processes where one process execution is constituted by a single case with a unique case identifier. Data-centric and artifact-centric systems such as ERP systems violate this assumption. Here a process execution is driven by process data having various notions of interrelated identifiers that distinguish the various interrelated data objects of the process. Classical process mining techniques fail in this setting. This paper presents an automatic technique for discovering for each notion of data object in the process a separate process model that describes the evolution of this object, also known as artifact life-cycle model. Given a relational database that stores process execution information of a data-centric system, the technique extracts event information, case identifiers and their interrelations, discovers the central process data objects and their associated events, and decomposes the data source into multiple logs, each describing the cases of a separate data object. Then classical process discovery techniques can be applied to obtain a process model for each object. The technique is implemented and has been evaluated on the production ERP system of a large retailer
Event Graph of BPI Challenge 2016
No full textBusiness process event data modeled as labeled property graphs Data Format ----------- The dataset comprises one labeled property graph in two different file formats. #1) Neo4j .dump format 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/ /bin/neo4j-admin.(bat|sh) load --database=graph.db --from= The .dump was created with Neo4j v3.5. #2) .graphml format A .zip file containing a .graphml file of the entire graph Data 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 nodes 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 Data Contents ------------- neo4j-bpic16-2021-02-17 (.dump|.graphml.zip) An integrated graph describing the raw event data of the entire BPI Challenge 2016 dataset. Dees, Marcus; van Dongen, B.F. (Boudewijn) (2016): BPI Challenge 2016. 4TU.ResearchData. Collection. https://doi.org/10.4121/uuid:360795c8-1dd6-4a5b-a443-185001076eab UWV (Employee Insurance Agency) is an autonomous administrative authority (ZBO) and is commissioned by the Ministry of Social Affairs and Employment (SZW) to implement employee insurances and provide labour market and data services in the Netherlands. The Dutch employee insurances are provided for via laws such as the WW (Unemployment Insurance Act), the WIA (Work and Income according to Labour Capacity Act, which contains the IVA (Full Invalidity Benefit Regulations), WGA (Return to Work (Partially Disabled) Regulations), the Wajong (Disablement Assistance Act for Handicapped Young Persons), the WAO (Invalidity Insurance Act), the WAZ (Self-employed Persons Disablement Benefits Act), the Wazo (Work and Care Act) and the Sickness Benefits Act. The data in this collection pertains to customer contacts over a period of 8 months and UWV is looking for insights into their customers' journeys. Data has been collected from several different sources, namely: 1) Clickdata from the site www.werk.nl collected from visitors that were not logged in, 2) Clickdata from the customer specific part of the site www.werk.nl (a link is made with the customer that logged in), 3) Werkmap Message data, showing when customers contacted the UWV through a digital channel, 4) Call data from the callcenter, showing when customers contacted the call center by phone, and 5) Complaint data showing when customers complained. All data is accompanied by data fields with anonymized information about the customer as well as data about the site visited or the contents of the call and/or complaint. The texts in the dataset are provided in both Dutch and English where applicable. URL's are included based on the structure of the site during the period the data has been collected. UWV is interested in insights on how their channels are being used, when customers move from one contact channel to the next and why and if there are clear customer profiles to be identified in the behavioral data. Furthermore, recommendations are sought on how to serve customers without the need to change the contact channel. The data contains the following entities and their events - Customer - customer of a Dutch public agency for handling unemployment benefits - Office_U - user or worker involved in an activity handling a customer interaction - Office_W - user or worker involved in an activity handling a customer interaction - Complaint - a complaint document handed in by a customer - ComplaintDossier - a collection of complaints by the same customer - Session - browser-session identifier of a user browsing the website of the agency - IP - IP address of a user browsing the website of the agency Data Size --------- BPIC16, nodes: 8109680, relationships: 8683313
Event Graph of BPI Challenge 2014
No full textBusiness process event data modeled as labeled property graphs Data Format ----------- The dataset comprises one labeled property graph in two different file formats. #1) Neo4j .dump format 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/ /bin/neo4j-admin.(bat|sh) load --database=graph.db --from= The .dump was created with Neo4j v3.5. #2) .graphml format A .zip file containing a .graphml file of the entire graph Data 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 nodes 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 Data 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 incidents Data Size --------- BPIC14, nodes: 919838, relationships: 668238
Discover Context-Rich Local Process Models (Extended Abstract)
No full textWe introduce a new ProM plugin called Discover Context-Rich LPMs which mines a log for large local process models (LPMs) based on supported words. The main advantage of this plugin is that it produces much larger and much fewer LPMs than other tools. The plugin is packaged with an additional plugin called Generate HTML coverage report which calculates the coverage of LPMs along with several other quality measures. This extra plugin is useful to select and improve a set of LPMs
Exploring Task Execution Patterns in Event Graphs
No full textClassical process mining aims to capture the behavior of a process based on a single dimension: the sequence of activities grouped by process cases. This viewpoint fails to capture how individual actors are organizing their work across multiple cases. We present a tool that uses the graph database Neo4j to model actor behavior over different cases as an event graph. We then use Neo4j queries to detect task execution patterns in the graph describing how multiple actors collaborate across multiple cases. Exploring and visualizing these patterns enables the data driven analysis of tasks, routines, and habits as studied in organizations research
Event Graph of BPI Challenge 2017
No full textBusiness process event data modeled as labeled property graphs Data Format ----------- The dataset comprises one labeled property graph in two different file formats. #1) Neo4j .dump format 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/ /bin/neo4j-admin.(bat|sh) load --database=graph.db --from= The .dump was created with Neo4j v3.5. #2) .graphml format A .zip file containing a .graphml file of the entire graph Data 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 nodes 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 Data Contents ------------- neo4j-bpic17-2021-02-17 (.dump|.graphml.zip) An integrated graph describing the raw event data of the entire BPI Challenge 2017 dataset. van Dongen, B.F. (Boudewijn) (2017): BPI Challenge 2017. 4TU.ResearchData. Collection. https://doi.org/10.4121/uuid:5f3067df-f10b-45da-b98b-86ae4c7a310b This event log pertains to a loan application process of a Dutch financial institute. The data contains all applications filed trough an online system in 2016 and their subsequent events until February 1st 2017, 15:11. The company providing the data and the process under consideration is the same as doi:10.4121/uuid:3926db30-f712-4394-aebc-75976070e91f. However, the system supporting the process has changed in the meantime. In particular, the system now allows for multiple offers per application. These offers can be tracked through their IDs in the log. The data contains the following entities and their events - Application - a credit application document submitted by a customer to a Dutch financial institute - Offer - a loan offer document created by the institute and sent to the customer - Workflow - a logical grouping of activities by the case management system supporting workers at the financial institute to handle applications and offers - Case_R - a user or worker of the financial institute - Case_AO - a derived entity describing the reified relation between an offer and its related application - Case_AW - a derived entity describing the reified relation between the workflow and its related application - Case_WO - a derived entity describing the reified relation between an offer and its related workflow Data Size --------- BPIC17, nodes: 1425995, relationships: 1030019
- …
