Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
40
datasets available to search
ShareScore release 0.9.0
Dataset results
40 results for “event log”
Antarctic Circumnavigation Expedition event log: recording data and sample collection in the Southern Ocean during the austral summer of 2016/17.
<p><strong>Dataset abstract</strong></p> <p>The Antarctic Circumnavigation Expedition (ACE) spent 90 days circumnavigating Antarctica on the R/V Akademik Tryoshnikov during the austral summer of 2016/17. This dataset provides a record of the instrument deployments as well as dataset and sample collection events that took place during the expedition.</p> <p><strong>Dataset contents</strong></p> <ul> <li>ace_events.csv, data file, comma-separated values</li> <li>sampling_method_descriptions.csv, metadata, comma-separated values</li> <li>README.txt, metadata, text</li> <li>data_file_header.txt, metadata, text</li> </ul> <p><strong>Dataset license</strong></p> <p>This event log is made available under a Creative Commons Attribution 4.0 International License (CC BY 4.0) whose full text can be found at https://creativecommons.org/licenses/by/4.0/</p> <p> </p>
An IoT-Enriched Event Log for Process Mining in Smart Factories
<p><strong>DEPRECATED - current version: </strong><a href="https://figshare.com/articles/dataset/Dataset_An_IoT-Enriched_Event_Log_for_Process_Mining_in_Smart_Factories/20130794">https://figshare.com/articles/dataset/Dataset_An_IoT-Enriched_Event_Log_for_Process_Mining_in_Smart_Factories/20130794</a></p> <p> </p> <p>Modern technologies such as the Internet of Things (IoT) are becoming increasingly important in various domains, including Business Process Management (BPM) research. One main research area in BPM is process mining, which can be used to analyze event logs, e.g., for checking the conformance of running processes. However, there are only a few IoT-based event logs available for research purposes. Some of them are artificially generated, and the problem occurs that they do not always completely reflect the actual physical properties of smart environments. In this paper, we present an IoT-enriched XES event log that is generated by a physical smart factory. For this purpose, we created the DataStream XES extension for representing IoT-data in event logs. Finally, we present some preliminary analysis and properties of the log.</p>
Event logs from Northeast U.S. Shelf Long Term Ecological Research (NES-LTER) Transect cruises, ongoing since 2017
This package provides a concatenated table of events recorded on seasonal Transect cruises for Northeast U.S. Shelf Long-Term Ecological Research (NES-LTER) and other opportunistic cruises within the transect region. Events were recorded onboard with Rolling Deck to Repository (R2R) event logger (elog) software. Event listings include date, time, ship's position, instrument, and action for over the side operations, underway data collection, and other miscellaneous events during the cruise. The event log is used post-cruise in physical sample cataloging and data integration. Cruises are seasonal and include NES-LTER dedicated voyages, spring and fall cruises in collaboration with the Ocean Observatories Initiative (OOI), and additional opportunistic cruises.
Event logs from Northeast U.S. Shelf Long Term Ecological Research (NES-LTER) cruises to the Martha's Vineyard Coastal Observatory (MVCO) ongoing since 2017
This package provides a table of cruises to the Martha's Vineyard Coastal Observatory for Northeast U.S. Shelf Long-Term Ecological Research (NES-LTER). The majority of events are single day cruises, however, samples missing an MVCO Event Number were collected on multi-day NES-LTER transect cruises aboard larger research vessels. The same sampling protocols for CTD and bongo collection are used on both cruise types. Sampling frequency is approximately monthly, with NES-LTER sampling ongoing since 2017. Cruises involve collection of water column bottle samples, surface bucket samples, and zooplankton net tow samples, as well as ship-provided data. NES-LTER transect cruises will have more extensive underway and acoustic data which can be found by searching by cruise at https://www.rvdata.us/data. The event number for each cruise is provided, along with date, vessel name, cruise identifier where applicable, link to data location (for CTD, ADCP, and other underway data), and checklist of six data types.
CCE LTER process cruise, in the California Current region, event log records including date, time, position and activity for use in post-cruise data integration based on co-sampling indexes. From 2006 to 2019 CCE LTER used a locally developed event logging system. During P2107, CCE LTER started to utilize the R2R Event Logger on UNOL ships, 2006 - 2024 (ongoing).
The event logger program developed and maintained by the California Cooperative Oceanic Fisheries Investigations, SIO, program is used aboard CCE LTER process cruises to create indexes with temporal, spatial and activity information for post-cruise data integration. The event log is configured aboard the ship for the recording of sampling events by both ship crew personnel on the bridge, and research personnel in the lab. The event log is processed post-cruise to correct for various errors.
Marine Mammal Survey, Sightings and Sampling Event Log at Palmer Station, Antarctica, 2020-2024
Seasonal sea ice-influenced marine ecosystems at both poles are characterized by high productivity concentrated in space and time by local, regional, and remote physical forcing. These polar ecosystems are among the most rapidly changing on Earth. The PALmer (PAL) LTER seeks to build on three decades of long-term research along the western side of the Antarctic Peninsula (WAP) to gain new mechanistic and predictive understanding of ecosystem changes in response to disturbances spanning long-term, subdecadal, and higher-frequency “pulses” driven by a range of processes, including long-term climate warming, natural climate variability, and storms. These disturbances alter food-web composition and ecological interactions across time and space scales that are not well understood. We seek to determine the differential effects of disturbance and resilience on krill predators with different life histories, foraging behaviors, and demographic patterns. Specifically, changes in foraging behavior can affect adult fitness, body condition, and reproductive rates, as well as offspring survival. Preliminary analyses suggest mean chick fledgling mass decreases later in the austral summer as storm disturbances increase. If storms are not a factor influencing chick mass, parental effects or ecosystem phenology may play a larger role. For whales, changes in foraging effort and increases in body condition should correlate with increased pregnancy rates. We will test for linkages between whale foraging efficiency related to storms with female pregnancy rates the following year. Our prediction is that in seasons with more storms and poorer foraging conditions, fewer whales will become pregnant. However, as whales are long-lived, we predict this will not have a major effect on the long-term positive population trend. We will contribute fundamental understanding of how population dynamics and physiological processes are responding within a polar marine ecosystem undergoing profound change
Procure-To-Payment (P2P) Object-centric Event Log in OCEL 2.0 Standard
<p><strong>Short Description</strong></p> <p>This process describes the Procure-To-Pay (P2P) procedure within an organization, starting from the initiation of a purchase requirement up to the execution of payment. This simulation extensively uses genuine SAP transactions and object types to offer a realistic representation of the P2P process.</p> <p><strong>Overview</strong></p> <p>Within our simulated organization:</p> <ul> <li> <p>Procurement Initiatives: The procurement journey begins when a department or individual recognizes a need and creates a Purchase Requisition using transaction ME51N.</p> </li> <li> <p>Approval Process: Before the purchase can proceed, the requisition must be approved. This is carried out using transaction ME54N. Given the nature of our simulation, there may be instances where the approval process takes an unusually long time, exemplifying the Lengthy Approval Process behavior.</p> </li> <li> <p>Vendor Interactions:</p> <ul> <li>Upon approval, a Request for Quotation is sent out to potential vendors using transaction ME41.</li> <li>Vendors then submit their quotations, which are maintained in the system using transaction ME47.</li> </ul> </li> <li> <p>Purchase Order Creation: Once a vendor's quotation is selected, a Purchase Order is created using transaction ME21N. The purchase order is then subjected to an internal approval process (ME29N). Occasionally, maverick buying—where purchases are made without proper authorization—can be observed.</p> </li> <li> <p>Goods & Invoice Management:</p> <ul> <li>When the goods are received, a Goods Receipt is recorded using transaction MIGO.</li> <li>Invoices from vendors are then received and recorded. A three-way match, which checks the purchase order, goods receipt, and invoice for discrepancies, is performed using transaction MRBR.</li> </ul> </li> <li> <p>Payment: Once everything is verified, payments are executed using transaction F110. However, there may be instances of Duplicate Payments in our simulation, where the system mistakenly pays the same invoice more than once.</p> </li> </ul> <p><strong>Special Behaviors:</strong></p> <ul> <li>Maverick Buying: Unauthorized purchases, bypassing the standard procedure.</li> <li>Duplicate Payments: An error leading to the same invoice being paid multiple times.</li> <li>Lengthy Approval Process: Delays in approving purchase requisitions or purchase orders, which might lead to operational inefficiencies.</li> </ul> <p><strong>General Properties</strong></p> <p>An overview of log properties is given below.</p> <table> <thead> <tr> <th>Property</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Event Types</td> <td>10</td> </tr> <tr> <td>Object Types</td> <td>7</td> </tr> <tr> <td>Events</td> <td>14671</td> </tr> <tr> <td>Objects</td> <td>9543</td> </tr> </tbody> </table> <p><strong>Authors</strong></p> <p>Gyunam Park and Leah Tacke genannt Unterberg</p> <p><strong>Contributing</strong></p> <p>To contribute, drop us an email! We are happy to receive your feedback.</p>
Techmaster event log
<p>Techmaster log for the replication of experiments described in Context-Aware Process Performance Indicator Prediction in IEEE Access 2020.</p>
Compositional discovery of architecture-aware and sound process models from event logs of multi-agent systems: experimental data.
<p>This repository contains the experimental data used for the evaluation of the compositional approach to the discovery of process models from event logs of multi-agent systems, where agents interact according to specific patterns of synchronous and asynchronous interactions.</p> <p>According to the experiment plan, there is the folder for each interface pattern containing:</p> <ol> <li>The reference model (Petri net encoded in PNML-file)</li> <li>The event log obtained by simulating the behavior of the reference model (XES-file)</li> <li>The model discovered directly from the generated event log (Petri net encoded in PNML-file)</li> <li>The model discovered by composing the agent model w.r.t. the interface pattern (Petri net encoded in PNML-file)</li> </ol>
SHP event log
<p>SHP log for the replication of experiments described in Context-Aware Process Performance Indicator Prediction in IEEE Access 2020.</p> <p> </p>
An Empirical Evaluation of Unsupervised Event Log Abstraction Techniques in Process Mining
<p>This upload contains the event logs, generated by L-Sim, on which the experiments of the related paper were performed.</p><p>The related paper is accepted in the journal Information Systems.</p>
Game Data Event Log from Age of Empire Interactions
<p><span>The event log describes players' behavior in the real-time strategy game Age of Empires. Each case describes the events that a player triggers in a game. </span><span>There are 185.094 cases that consist</span><span> of more than 18 million events. The timestamp represents the elapsed time since the start of the game.</span></p> <p><span>Each player is assigned an</span><span> Elo ranking that is higher, the better the player is. This allows us to study the implications of skill on players' behavior. Also, games can take place on different maps, influencing the situations the players find themselves in. Some games follow clear initial strategies, which are called build orders. These build orders are comparable to chess openings.</span></p> <p><span>The event log is split into ten parts to make the import feasible for smaller machines.</span></p>
Process Models obtained from event logs with with different information-preserving abstractions
<p>This dataset contains results of the experiment to analyze information preservation and recovery by different event log abstractions in process mining described in: Sander J.J. Leemans, Dirk Fahland "Information-Preserving Abstractions of Event Data in Process Mining"<br> Knowledge and Information Systems, ISSN: 0219-1377 (Print) 0219-3116 (Online), accepted May 2019</p> <p>The experiment results were obtained with: https://doi.org/10.5281/zenodo.3243981</p>
Object-Centric Event Log for Age of Empires Game Interactions
<p>The dataset contains object-centric event logs in the OCEL 2.0 ( <a href="https://www.ocel-standard.org/" target="_blank" rel="noopener">https://www.ocel-standard.org/ </a>) format.</p> <p>The event logs originate from 100,000 Age of Empires 2 matches. In this real-time strategy game, players control units (like villagers or archers) and build structures (like houses or lumber camps) to create an efficient economy and win against the other players. Players can control multiple units at once, and they can utilize game mechanics to automate parts of the process for them, so they must not trigger every event themselves. The beginning of the game focuses on building economic structures that are as efficient as possible. Normative process descriptions, so-called build orders, describe battle-tested interaction patterns for the beginning of the game, similar to chess openings.</p> <p>The large object-centric event log contains 1000 matches and has the following properties:</p> <table> <tbody> <tr> <td><strong>Property</strong></td> <td><strong>Value</strong></td> </tr> <tr> <td>Objects</td> <td>361,935</td> </tr> <tr> <td>Object Types</td> <td>30</td> </tr> <tr> <td>Events</td> <td>2,372,505</td> </tr> <tr> <td>Event Types</td> <td>829</td> </tr> </tbody> </table> <p> </p> <p>The following table describes the most important object types:<br><br></p> <table> <tbody> <tr> <td><strong>Object Type or (Group of Object Types)</strong></td> <td><strong><span>Explanation</span> </strong></td> </tr> <tr> <td>Match</td> <td>The match represents the competition of two players.</td> </tr> <tr> <td>Player</td> <td>There is one object per player. They are connected to all events that involve player input.</td> </tr> <tr> <td>Session</td> <td>There is one session per player in a match. The session is connected to all events happening on the machine of a player. The events can involve the player directly or they can also be game logic-based events triggered by the game engine.</td> </tr> <tr> <td>Villager</td> <td>Worker units to gather resources and build infrastructure.</td> </tr> <tr> <td>Town Center</td> <td>Central buildings for villager production and resource drop-off. Capable of setting automated gather points to assign tasks for newly created villagers.</td> </tr> <tr> <td>(Resource Drop-Off Group)</td> <td>Includes Lumber Camps, Mining Camps, and Mills. These facilities not only serve as drop-off points but can automatically command workers to gather the corresponding resources upon build completion.</td> </tr> <tr> <td>Farms</td> <td>Agricultural units for a continuous food supply. Farms can sometimes be replenished automatically, depending on game settings or upgrades.</td> </tr> <tr> <td>(Military Buildings)</td> <td>Structures for training military units and producing siege weaponry. Capable of setting gather points to automate unit deployment.</td> </tr> <tr> <td>(Research Buildings)</td> <td> <p>Facilities dedicated to technological advancements and upgrades.</p> </td> </tr> <tr> <td>(Military Units)</td> <td> <p>Units used for combat operations.</p> </td> </tr> </tbody> </table> <p> </p> <p>The following table describes the most important activities:</p> <p> </p> <table> <tbody> <tr> <td><strong>Event Type</strong></td> <td><strong><span>Explanation</span></strong></td> </tr> <tr> <td>Command Build [Structure]</td> <td>Issued by players to direct units to construct buildings.</td> </tr> <tr> <td>Start Build [Structure]</td> <td>Marks the beginning of the construction of a building by a designated group of villagers.</td> </tr> <tr> <td>Complete Build [Structure]</td> <td>Signals the completion of a building's construction, making the building operational and freeing up capacity of the constructing units.</td> </tr> <tr> <td>Gather [Resource]</td> <td>Represents the command to a unit to collect resources such as wood, stone, food, or gold.</td> </tr> <tr> <td>Command Research [Technology]</td> <td>Issued by players to initiate a research task in a research building.</td> </tr> <tr> <td>Start Research [Technology]</td> <td>Marks the beginning of the research process once resources arrived.</td> </tr> <tr> <td>Complete Research [Technology]</td> <td>Denotes the completion of a research task, unlocking new technologies or enhancements, and freeing up production capacity.</td> </tr> <tr> <td>Command Queue [Unit]</td> <td>Issued by players to add units to the production queue of a building.</td> </tr> <tr> <td>Start Production [Unit]</td> <td>Marks the beginning of unit production within a facility, as soon as there is capacity.</td> </tr> <tr> <td>Complete Queue [Unit]</td> <td>Signals the end of unit production, resulting in the deployment of a new unit and freeing up production capacity.</td> </tr> </tbody> </table> <p> </p> <p>The zip file contains filtered object-centric event logs that only contain 10 matches to explore the data set with faster loading time.</p>
Synthetic XES Event Log of Malignant Melanoma Treatment
<p>The synthetic event log described in this document consists of 25,000 traces, generated using the process model outlined in Geyer et al. (2024) [1] and the DALG tool [2]. This event log simulates the treatment process of malignant melanoma patients, adhering to clinical guidelines. Each trace in the log represents a unique patient journey through various stages of melanoma treatment, providing detailed insights into decision points, treatments, and outcomes.</p> <p>The DALG tool [2] was employed to generate this data-aware event log, ensuring realistic data distribution and variability. </p> <p> </p> <p>DALG: <a href="https://github.com/DavidJilg/DALG">https://github.com/DavidJilg/DALG</a></p> <p> </p> <p>[1] Geyer, T., Grüger, J., & Kuhn, M. (2024). Clinical Guideline-based Model for the Treatment of Malignant Melanoma (Data Petri Net) (1.0). Zenodo. <a href="https://doi.org/10.5281/zenodo.10785431">https://doi.org/10.5281/zenodo.10785431</a></p> <p>[2] Jilg, D., Grüger, J., Geyer, T., Bergmann, R.: DALG: the data aware event log generator. In: BPM 2023 - Demos & Resources. CEUR Workshop Proceedings, vol. 3469, pp. 142–146. CEUR-WS.org (2023)</p>
Simulated XES event log of a marketing campaign system
<p>We relied on the interview-driven methodology defined in our previous work \cite{benvenuti2022}, which allowed us to specify various simulation scenarios to frame the boundaries of all possible pipeline executions.</p> <p>Then, we generated this simulated event logs in the traditional XES format using the Simio (https://www.simio.com/), obtaining 10,000 execution traces compliant with the simulation scenarios. In the picture it is shown the Directly-Follow Graph (DFG) representing the pipeline structure, discovered by feeding a process discovery tool (https://fluxicon.com/disco/) with the simulated event log.</p> <p>The pipeline is triggered when the system receives a request to model a new marketing campaign or to report on how an already existing one is performing. In both cases, the first two steps of the pipeline are querying the required data and to apply specific transformations on it. Then, if the request was for a report there is the need of merging the queried data, while for the request of a model an algorithm to compute it is launched. Next, if the request was for a model, the result needs to be stored.<br> Finally, the pipeline ends with either the report or the model being generated.</p>
(Un)Fair Process Mining Event Logs
<p><strong>License: </strong>CC-BY-4.0</p> <p><strong>Event Logs:</strong></p> <p>We introduce a set of 12 distinct event logs, three for each of the four domains: hiring, healthcare, lending, and renting. These event logs have been carefully curated and simulated, each containing 10,000 cases, thereby providing an extensive resource for researchers focusing on fairness in process mining.</p> <p>In each of these domains, the three event logs represent varying degrees of discrimination, offering researchers an opportunity to explore the nuances and complexities that arise in diverse real-world scenarios. By presenting each log with a thorough description of the inherent processes and their respective attributes, we aim to provide a robust groundwork for understanding the potential sources of discrimination and addressing fairness in process mining.</p> <p>We have ensured that all the event logs are provided in the eXtensible Event Stream (XES) standard format. This adherence to a recognized standard not only ensures broad compatibility but also facilitates interoperability across a variety of process mining tools. By choosing this common format, we aim to encourage and simplify the utilization of these logs for researchers across different platforms.</p> <p><strong>* Hiring</strong></p> <p>The data describes a multifaceted recruitment process with diverse application pathways ranging from minimal processing to extensive multi-step procedures. The variability of these routes, largely dependent on numerous determinants, yields a spectrum of outcomes from instant rejection to successful job offers.</p> <p>The logs include attributes such as age, citizenship, German proficiency, gender, religion, and years of education. While these attributes may inform candidate profiles, their misuse could engender discrimination. Variables like age and education may signify experience and skills, citizenship and German language may address job logistics, but these should not unjustly eliminate applicants. Gender and religion, unrelated to job performance, must not sway hiring. Therefore, the use of these attributes must uphold fairness, avoiding any potential bias.</p> <p><strong>* Hospital</strong></p> <p>The data depicts a hospital treatment process that commences with registration at an Emergency Room or Family Department and advances through stages of examination, diagnosis, and treatment. Notably, unsuccessful treatments often entail repetitive diagnostic and treatment cycles, underscoring the iterative nature of healthcare provision.</p> <p>The logs incorporate patient attributes such as age, underlying condition, citizenship, German language proficiency, gender, and private insurance. These attributes, influencing the treatment process, may unveil potential discrimination. Factors like age and condition might affect case complexity and treatment path, while citizenship may highlight healthcare access disparities. German proficiency can impact provider-patient communication, thus affecting care quality. Gender could spotlight potential health disparities, while insurance status might indicate socio-economic influences on care quality or timeliness. Therefore, a comprehensive examination of these attributes vis-a-vis the treatment process could shed light on potential biases or disparities, fostering fairness in healthcare delivery.</p> <p><strong>* Lending</strong></p> <p>This data illustrates the steps within a loan application process. From an initial appointment request, the process navigates various stages, including information verification and underwriting, culminating in loan approval or denial. Additional steps may be required, such as co-signer enlistment or collateral assessment. Some cases experience outright appointment denial, indicating the process's variability, reflecting applicants' differing credit situations.</p> <p>The logs' attributes can aid in identifying influences on outcomes and detecting discrimination. Personal characteristics ('age', 'citizen', 'German speaking', and 'gender') and socio-economic indicators ('YearsOfEducation' and 'CreditScore') can impact the process. While 'yearsOfEducation' and 'CreditScore' can validly inform creditworthiness, 'age', 'citizen', 'language ability', and 'gender' should not bias loan decisions, ensuring these attributes are used responsibly fosters equitable loan processes.</p> <p><strong>* Renting</strong></p> <p>The data represents a rental process. It begins with a prospective tenant applying to view a property. Subsequent steps include an initial screening phase, viewing, decision-making, and a potential extensive screening. The process ends with the acceptance or rejection of the prospective tenant. In some cases, a tenant may apply for viewing but be rejected without the viewing occurring.</p> <p>The logs contain attributes that can shed light on potential biases in the process. 'Age', 'citizen', 'German speaking', 'gender', 'religious affiliation', and 'yearsOfEducation' might influence the rental process, leading to potential discrimination. While some attributes may provide useful insights into a potential tenant's reliability, misuse could result in discrimination. Thus, fairness must be observed in utilizing these attributes to avoid potential biases and ensure equitable treatment.</p>
Order Management Object-centric Event Log in OCEL 2.0 Standard
<p><strong>General Description</strong></p> <p>This process describes the management of customer orders within a company, comprising both the registration and payment of incoming orders, as well as the process of packing and shipping these orders. For these tasks, our company deploys staff in their sales, warehousing, and shipment departments.</p> <p>This is an artificial event log according to the <a href="https://www.ocel-standard.org/">OCEL 2.0 Standard</a> simulated using CPN-Tools. Both the CPN and the SQLite can be downloaded. The simulation is an extension of the <a href="https://www.ocel-standard.org/beta/event-logs/simulations/legacy-logs">order management log</a> in the former OCEL standard.</p> <p><strong>Process Overview</strong></p> <p>At our company, <strong>customers</strong> place <strong>orders</strong> <em>(place order)</em> for different <strong>products</strong> in varying amounts. Each product type has a price and a weight. In the current market situation, there is an inflation that irregularly leads to an increase of prices. These price rises have a negative impact on customers’ purchasing power, i.e., on order volumes.</p> <p>When a customer places an order, this order is assigned to an <strong>employee</strong> of our company’s sales department. To foster customer satisfaction, our company has a single-face-to-customer policy. This means that per customer there is one primary sales representative who ought to render all services related to that customer. If that first representative is unavailable, a second sales representative should take care of the order. Should this employee be also unavailable, the order has to be managed by another employee. The tasks of sales employees comprise the registration <em>(confirm order)</em> as well as payment processing <em>(payment reminder, pay order)</em>.</p> <p>In parallel to this, the shipment of goods is prepared. For this, the stock of our company is checked by an employee of the warehousing department for the availability of the ordered <strong>items</strong>. If necessary, the warehouser reorders the item <em>(item out of stock, reorder item)</em>. Items ready for shipment are collected <em>(pick item)</em> for the placement into <strong>packages</strong> that are addressed to single customers. Here, it may happen that a package content relates to multiple orders, and order volumes are distributed over multiple packages.</p> <p>After all items allocated to a package have been picked, the package is compiled by a warehousing employee <em>(create package)</em>. Later on, this package is picked up by a shipment employee for transport <em>(send package)</em>. According to another policy, a warehousing employee should provide assistance to the shipment employee in loading the package. However, oftentimes shippers act contrary to that policy and load packages alone or together with a second shipment employee.</p> <p>Finally, the package is shipped. Deliveries may fail repeatedly <em>(failed delivery)</em> until successful delivery <em>(package delivered)</em>.</p> <p>The figure below depicts the process in a simplified manner, using an informal process notation to describe the control-flow and the involved object types. A formal description is given along with the artifacts in the next section.</p> <p>Further information can be found at: <a href="https://www.ocel-standard.org/event-logs/simulations/order-management/">https://www.ocel-standard.org/event-logs/simulations/order-management/</a></p> <p><strong>General Properties </strong></p> <p>An overview of log properties is given below.</p> <table> <thead> <tr> <th>Property</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Event Types</td> <td>11</td> </tr> <tr> <td>Object Types</td> <td>6</td> </tr> <tr> <td>Events</td> <td>21008</td> </tr> <tr> <td>Objects</td> <td>10840</td> </tr> </tbody> </table> <p><strong>Control-Flow Behavior </strong></p> <p>The behavior of the log is described by a <a href="https://www.ocel-standard.org/beta/event-logs/simulations/logistics/images/full-ocpn.svg">respective object-centric Petri net</a>. Also, individual object types exhibit behavior that can be described by simpler Petri nets. See below.</p> <table> <thead> </thead> <tbody> <tr> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/order-management/images/orders-ocpn.svg">orders</a></td> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/order-management/images/customers-ocpn.svg">customers</a></td> </tr> <tr> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/order-management/images/items-ocpn.svg">items</a></td> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/order-management/images/employees-ocpn.svg">employees</a></td> </tr> <tr> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/order-management/images/packages-ocpn.svg">packages</a></td> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/order-management/images/products-ocpn.svg">products</a></td> </tr> <tr> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/order-management/images/full-ocpn.svg"><strong>Full object-centric Petri net</strong></a></td> </tr> </tbody> </table> <p><strong>Object Relationships </strong></p> <p>The company pursues the "one-face-to-the-customer" policy, in which every customer has a dedicated sales representative as well as a deputy (secondary representative). These relationships are described in the log.</p> <table> <thead> <tr> <th>Source Object Type</th> <th>Target Object Type</th> <th>Qualifier</th> </tr> </thead> <tbody> <tr> <td>employees</td> <td>customers</td> <td>primarySalesRep</td> </tr> <tr> <td>employees</td> <td>customers</td> <td>secondarySalesRep</td> </tr> </tbody> </table> <p>Additionally, object-to-object relations can emerge at executions of specific activities:</p> <table> <thead> <tr> <th>Activity</th> <th>Source Object Type</th> <th>Target Object Type</th> <th>Qualifier</th> </tr> </thead> <tbody> <tr> <td>create package</td> <td>package</td> <td>employee</td> <td>packed by</td> </tr> <tr> <td>send package</td> <td>package</td> <td>employee</td> <td>forwarded by</td> </tr> <tr> <td>send package</td> <td>package</td> <td>employee</td> <td>shipped by</td> </tr> </tbody> </table> <p><strong>Simulation Model </strong></p> <p>The CPN used to create this event log can also be downloaded.To obtain simulated data, extract the linked ZIP file and play out the CPN therein, e.g., by using <a href="https://cpntools.org/">CPN Tools</a>.</p> <p>The play-out produces CSV files according to the schema of OCEL2.0. The provided jupyter notebook can be used to convert these files to an SQLite dump.</p> <p>For a technical documentation of the simulation model, please open the attached CPN with CPN Tools and see the annotations therein.</p> <p><strong>Acknowledgements</strong></p> <p>Funded under the Excellence Strategy of the Federal Government and the Länder<em>. </em>We also thank the Alexander von Humboldt (AvH) Stiftung for supporting our research.</p>
Angular GitHub Commits Object-centric Event Log
<p><strong>Overview</strong></p> <p>This real-world object-centric event log in the OCEL 2.0 standard contains an extraction of the commit information from the <a href="https://github.com/angular/angular">GitHub repository</a> used to developed the <a href="https://www.angular.io/">Angular</a> platform. A single code commit in the repository is abstracted to one event in the log. The dataset contains essential information for each commit, such as the timestamp and the contributor's details. Crucially, commit information is connected to two classes of objects: the file(s) affected by the commit, and the branch(es) in the repository containing the commit.</p> <p><strong>Description</strong></p> <p>GitHub, a popular platform for developers offering the functionalities of the Git versioning system, allows to record single modifications to software projects by contributors; such modifications are grouped in units called <strong>commits</strong>. Commits contain all details of the edits operated on a group of files in the projects. Therefore, all commits of a project constitute a ledger, that allows to rewind or fast-forward all contributions in the project.</p> <p>Commits in a project are arranged in <strong>branches</strong>, which form a tree-like structure. A contributor may create a new branch, essentially a copy of the project, in order to commit modifications safely. Once the contributor is satisfied with the edits, they may <strong>merge</strong> their new branch back into the pre-existing branch (realized by applying the modifications of all the new commits sequentially, and then solving the conflicts that may arise).</p> <p>This log contains an extraction of the commit information of the <a href="https://www.angular.io/">Angular</a> project on <a href="https://github.com/angular/angular">GitHub</a>. The abstraction level is such that every commit corresponds to an event in the log.</p> <p>For each event, the following information is recorded:</p> <ul> <li>a unique identifier (<strong>hash</strong>)</li> <li>the author's timestamp of the commit (includes timezone information)</li> <li>an <strong>activity label</strong>: the Angular project conforms to the <a href="https://www.conventionalcommits.org/">Conventional Commits</a> initiative, which mandates commit messages containing an initial identifier. This helps to reconstruct a clean activity notion. Some of the labels have been cleaned by hand (for instance, in case of typos)</li> <li>the message of the commit</li> <li>the contributor's name</li> <li>the contributor's email (<strong>resource</strong>)</li> <li>a <strong>merge</strong> flag; <strong>True</strong> if the commit is a merge, <strong>False</strong> otherwise</li> <li>information related to the <strong>files</strong> edited by the commit (in case of renames, we track the new name)</li> <li>information related to the <strong>branches</strong> in which the commit appears</li> </ul> <p>Files and branches are two distinct object types in this log. Note that a commit might not be associated to any file. Conversely, a commit always appears in at least one branch.</p> <p>This event log has been extracted with the help of <a href="https://github.com/ishepard/pydriller">PyDriller</a>.</p> <p><strong>Properties</strong></p> <p>This event log has the following properties:</p> <table> <tbody> <tr> <td><strong>Property</strong></td> <td><strong>Value</strong></td> </tr> <tr> <td>Events</td> <td>27847</td> </tr> <tr> <td>Activity Labels</td> <td>67</td> </tr> <tr> <td>Object Types</td> <td>2</td> </tr> <tr> <td>Objects (files)</td> <td>35392</td> </tr> <tr> <td>Objects (branches)</td> <td>119</td> </tr> </tbody> </table> <p><strong>Get started</strong></p> <p>Download the dataset, and position it in the folder of your Python script or console.</p> <p><em>pip install pm4py</em></p> <p>To manipulate object-centric logs programmatically, use the functionality of the <em>ocel</em> package <a href="https://pm4py.fit.fraunhofer.de/static/assets/api/2.7.5.1/api.html#object-centric-process-mining-pm4py-ocel">in the PM4Py library</a>. Additionally, check out the <a href="https://www.ocel-standard.org/beta/tool-support/overview/">tool support</a> for object-centric event logs!</p> <p><em>from pm4py import ocel</em></p> <p><strong>Acknowledgements</strong></p> <p>We thank the Alexander von Humboldt (AvH) Stiftung for supporting our research.</p>
Simplified Event Logs for Sepsis Patient Trajectories
<p>This dataset contains a simplified excerpt from a real event log that tracks the trajectories of patients admitted to a hospital to be treated for sepsis, a life-threatening condition. The log has been recorded by the Enterprise Resource Planning of the hospital. Additionally, the dataset contains three synthetic logs that increase the number of trajectories within the original log timespan, while maintaining other statistical characteristics.</p> <p>In total, the dataset contains four files in .zip format and a companion that describes the statistical method used to synthesize the logs as well as the dataset content in detail. The dataset can be used in testing the performance of event-based process-mining and log (runtime) monitoring tools against an increasing load of events.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.