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.

datasets available to search

ShareScore release 0.9.0

Dataset results

10 results for “Object-centric event log”

Learn how ShareScore rates datasets ↗

zenodo44/100

Procure-To-Payment (P2P) Object-centric Event Log in OCEL 2.0 Standard

Short Description 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. Overview Within our simulated organization: <ul> <li> Procurement Initiatives: The procurement journey begins when a department or individual recognizes a need and creates a Purchase Requisition using transaction ME51N. </li> <li> 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. </li> <li> Vendor Interactions: <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> 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. </li> <li> Goods & Invoice Management: <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> 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. </li> </ul> Special Behaviors: <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> General Properties An overview of log properties is given below. <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> Authors Gyunam Park and Leah Tacke genannt Unterberg Contributing To contribute, drop us an email! We are happy to receive your feedback.

opencc-by-4.0Oct 2023View details →

zenodo40/100

Object-Centric Event Log for Age of Empires Game Interactions

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. 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. The large object-centric event log contains 1000 matches and has the following properties: <table> <tbody> <tr> <td>Property</td> <td>Value</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>   The following table describes the most important object types: <table> <tbody> <tr> <td>Object Type or (Group of Object Types)</td> <td>Explanation </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> Facilities dedicated to technological advancements and upgrades. </td> </tr> <tr> <td>(Military Units)</td> <td> Units used for combat operations. </td> </tr> </tbody> </table>   The following table describes the most important activities:   <table> <tbody> <tr> <td>Event Type</td> <td>Explanation</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>   The zip file contains filtered object-centric event logs that only contain 10 matches to explore the data set with faster loading time.

opencc-by-4.0Jun 2024View details →

zenodo40/100

Order Management Object-centric Event Log in OCEL 2.0 Standard

General Description 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. 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. Process Overview At our company, customers place orders (place order) for different products 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. When a customer places an order, this order is assigned to an employee 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 (confirm order) as well as payment processing (payment reminder, pay order). 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 items. If necessary, the warehouser reorders the item (item out of stock, reorder item). Items ready for shipment are collected (pick item) for the placement into packages 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. After all items allocated to a package have been picked, the package is compiled by a warehousing employee (create package). Later on, this package is picked up by a shipment employee for transport (send package). 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. Finally, the package is shipped. Deliveries may fail repeatedly (failed delivery) until successful delivery (package delivered). 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. 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> General Properties  An overview of log properties is given below. <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> Control-Flow Behavior  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. <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">Full object-centric Petri net</a></td> </tr> </tbody> </table> Object Relationships  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. <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> Additionally, object-to-object relations can emerge at executions of specific activities: <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> Simulation Model  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>. 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. For a technical documentation of the simulation model, please open the attached CPN with CPN Tools and see the annotations therein. Acknowledgements Funded under the Excellence Strategy of the Federal Government and the Länder. We also thank the Alexander von Humboldt (AvH) Stiftung for supporting our research.

opencc-by-4.0Sep 2023View details →

zenodo40/100

Angular GitHub Commits Object-centric Event Log

Overview 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. Description 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 commits. 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. Commits in a project are arranged in branches, 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 merge 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). 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. For each event, the following information is recorded: <ul> <li>a unique identifier (hash)</li> <li>the author's timestamp of the commit (includes timezone information)</li> <li>an activity label: 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 (resource)</li> <li>a merge flag; True if the commit is a merge, False otherwise</li> <li>information related to the files edited by the commit (in case of renames, we track the new name)</li> <li>information related to the branches in which the commit appears</li> </ul> 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. This event log has been extracted with the help of <a href="https://github.com/ishepard/pydriller">PyDriller</a>. Properties This event log has the following properties: <table> <tbody> <tr> <td>Property</td> <td>Value</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> Get started Download the dataset, and position it in the folder of your Python script or console. pip install pm4py To manipulate object-centric logs programmatically, use the functionality of the ocel 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! from pm4py import ocel Acknowledgements We thank the Alexander von Humboldt (AvH) Stiftung for supporting our research.

opencc-by-4.0Oct 2023View details →

zenodo36/100

Simulated Object-Centric Event Logs (OCEL 2.0) for Order-to-Cash, Procure-to-Pay, Hiring, and Hospital Patient Lifecycle Processes

This dataset contains simulated object-centric event logs for four distinct business processes: Order-to-Cash (O2C), Procure-to-Pay (P2P), Hiring, and Hospital Patient Lifecycle. Each process is designed to reflect realistic workflows, encompassing multiple object types and capturing key activities, decision points, and process dynamics. The dataset is aimed at providing a rich source of data for process mining, analysis, and modeling activities. 1. Order-to-Cash (O2C):    The O2C process simulates an end-to-end business flow starting from customer order placement to payment receipt. It includes diverse activities such as order approval, fulfillment, invoice generation, and payment processing, involving object types like Customers, Orders, Products, and Invoices. The dataset captures variability through random decisions, synchronization between departments, and workarounds in credit checks and inventory adjustments. Attributes such as customer tiers, order values, and shipment statuses add further depth, allowing for detailed analysis of this complex process. 2. Procure-to-Pay (P2P):    The P2P process simulates the procurement lifecycle, from requisition creation to payment of suppliers. Key activities include purchase order creation, three-way matching, goods receipt, and payment processing. The event log records object types such as Purchase Requisitions, Purchase Orders, Suppliers, and Invoices. Variability is introduced through approval decisions, batching, and potential mismatches in the matching process. The dataset represents the inherent complexities of real-world procurement operations, including batching and synchronization issues between different process stages. 3. Hiring Process:    The hiring process log tracks the recruitment lifecycle, from job requisition creation to onboarding. It includes object types like Candidates, Job Requisitions, Recruiters, and Interviewers. The process covers activities such as resume screening, interviews, assessments, and offer management. Variability in the hiring process is introduced through random delays, candidate decisions, and background check durations. Batching occurs in stages like resume screening and onboarding, while synchronization challenges arise during interview scheduling. 4. Hospital Patient Lifecycle:    This log represents the lifecycle of patients within a hospital, capturing interactions with multiple resources such as physicians, beds, and medical equipment. The process begins with pre-admission activities, followed by diagnosis, treatment, and discharge. The dataset includes object types like Patients, Physicians, and Medical Equipment, with attributes related to patient demographics and event severity. The process reflects the dynamic nature of hospital operations, including synchronization of resources and the occurrence of workarounds in case of delays or resource unavailability. Each process simulation captures high variability, synchronization issues, and batching, making this dataset suitable for analyzing real-world operational challenges. The logs provide a comprehensive view of complex workflows, supporting advanced analysis, including object-centric process mining. This description will provide the necessary details about the dataset, highlighting its structure, purpose, and potential uses for researchers and process analysts. Object-centric event logs conceived and simulated by the o1-preview-2024-09-12 LRM, using the https://github.com/fit-alessandro-berti/llm-ocel-simulator project.

opencc-by-4.0Oct 2024View details →

zenodo32/100

Temporal Event Knowledge Graphs transformed from Object-Centric Event Logs

In the paper"Transforming Object-Centric Event Logs to Temporal Event Knowledge Graphs", we introduced and formalized temporal Event Knowledge Graphs (tEKGs) and presented an algorithm to transform Object-Centric Event Logs (OCEL) 2.0 into tEKGs. Data sets are the results of transforming OCEL 2.0 log files. The source of the generated dump files are as follows: <ol> <li>ContainerLogistics.neo4j.dum : <a href="../records/8428084">Link to the source data</a></li> <li>OrderManagement.neo4j.dump: <a href="../records/8428112">Link to the source data</a></li> <li>Procure-To-Payment.neo4j.dump: <a href="../records/8412920">Link to the source data</a></li> </ol> The version of the dump files is 5.12.0. Additionally, for restoring dump files inside Neo4j, you need to enter the username and password, which is indicated below: Username: neo4j Password: 12345678

opencc-by-4.0Mar 2024View details →

zenodo32/100

Collection of Object-Centric Event Logs (OCEL 1.0 format; JSON-OCEL specification)

We provide some realistic examples of logs in the OCEL standard. The logs have originally been published at https://www.ocel-standard.org/

opencc-by-4.0Aug 2023View details →

zenodo28/100

Collection of Object-Centric Event Logs (OCEL 2.0 format; SQLite specification)

We provide some realistic examples of logs in the OCEL 2.0 standard.

opencc-by-4.0Aug 2023View details →

zenodo28/100

Collection of Object-Centric Event Logs (OCEL 2.0 format; XML specification)

We provide some realistic examples of logs in the OCEL 2.0 standard.

opencc-by-4.0Aug 2023View details →

zenodo28/100

Container Logistics Object-centric Event Log

General Description Our company sells goods overseas. After receiving an order, the shipment of goods is scheduled. According to this schedule, the goods are picked up from the local production site and brought to a terminal where a logistics service provider receives and ships them. 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.  Process Overview From a customer order perspective, the process begins when the order is registered at our company (register customer order). After registration, a transport document is created in which details of the further process are recorded (create transport document). Using this information, the logistics service provider is contacted to coordinate the transport of the ordered goods to the seaport. Twice a week, that provider sends a vehicle to a terminal, with a limited capacity for containers of ordered goods to be transported from the terminal to a seaport. For our company, available capacties vary from vehicle to vehicle, as we are not the only company booking spots. Once the logistics service provider receives our transport documents, they book capacities according to availability and container prioritizations in the upcoming weeks (book vehicles). Once the dates for transporting the goods to the terminal are set, our company contacts a container depot to reserve the required containers (order empty containers). When a container’s vehicle departure approaches, the goods are prepared, packed and shipped to the terminal. For this purpose, a truck is sent to the container depot (pick up empty container). Meanwhile, the ordered goods to be shipped are packed into handling units at the production site. After loading the handling units (load truck), the truck drives the full container to the terminal (drive to terminal). At the terminal, the container is picked up by a free forklift and weighed (weigh). Unless the vehicle departure is imminent, the container is placed in the storage location at the terminal (place in stock). Finally, it is moved to the vehicle (bring to loading bay, load to vehicle) which departs at a fixed time (depart). Despite careful planning, containers sometimes miss a vehicle’s departure. In this case, the container is rescheduled to the next possible vehicle (reschedule container) and kept near the loading ramp until then. Further information can be found at: <a href="https://www.ocel-standard.org/beta/event-logs/simulations/logistics/">https://www.ocel-standard.org/beta/event-logs/simulations/logistics/</a> General Properties  An overview of log properties is given below. <table> <thead> <tr> <th>Property</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Event Types</td> <td>14</td> </tr> <tr> <td>Object Types</td> <td>7</td> </tr> <tr> <td>Events</td> <td>35761</td> </tr> <tr> <td>Objects</td> <td>14013</td> </tr> </tbody> </table> Control-Flow Behavior  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. <table> <tbody> <tr> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/logistics/images/Container-ocpn.svg">Container</a></td> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/logistics/images/Transport%20Document-ocpn.svg">Transport Documents</a></td> </tr> <tr> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/logistics/images/Customer%20Order-ocpn.svg">Customer Order</a></td> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/logistics/images/Truck-ocpn.svg">Truck</a></td> </tr> <tr> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/logistics/images/Forklift-ocpn.svg">Forklift</a></td> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/logistics/images/Vehicle-ocpn.svg">Vehicle</a></td> </tr> <tr> <td><a href="https://www.ocel-standard.org/beta/event-logs/simulations/logistics/images/Handling%20Unit-ocpn.svg">Handling Unit</a></td> <td> </td> </tr> </tbody> </table>   Object Relationships    During the process, object-to-object relations can emerge at activity occurrences as follows. <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 Transport Document</td> <td>Customer Order</td> <td>Transport Document</td> <td>TD for CO</td> </tr> <tr> <td>Book Vehicle</td> <td>Transport Document</td> <td>Vehicle</td> <td>Regular VH for TD</td> </tr> <tr> <td>Book Vehicle</td> <td>Transport Document</td> <td>Vehicle</td> <td>High-Prio VH for TD</td> </tr> <tr> <td>Order Empty Containers</td> <td>Transport Document</td> <td>Container</td> <td>CR for TD</td> </tr> <tr> <td>Pick Empty Container</td> <td>Truck</td> <td>Container</td> <td>TR loads CR</td> </tr> <tr> <td>Load Truck</td> <td>Container</td> <td>Handling Unit</td> <td>CR contains HU</td> </tr> <tr> <td>Reschedule Container</td> <td>Transport Document</td> <td>Vehicle</td> <td>Substitute VH for TD</td> </tr> </tbody> </table> Simulation Model  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>. The play-out produces CSV files according to the schema of OCEL2.0. <a href="https://www.ocel-standard.org/beta/event-logs/simulations/logistics/data/csv_to_sql.ipynb">This Python notebook</a> can be used to convert these files to an SQLite dump. For a technical documentation of the simulation model, please open the attached CPN with CPN Tools and see the annotations therein. Acknowledgements Funded under the Excellence Strategy of the Federal Government and the Länder. Funded by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany's Excellence Strategy - EXC-2023 Internet of Production - 390621612. We also thank the Alexander von Humboldt (AvH) Stiftung for supporting our research.

opencc-by-4.0Aug 2023View details →

ScienceDex guides

Understand access before you commit

These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.

Compare curated 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.

allen-brain-atlas

neuroscienceopenDocumentation, web resources, and API references are available online.

Last verified 2026-04-30Open record

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.

abode-home-cage

behavioral-neuroscienceopenThe DataShare record exposes download links for annotations, documentation, license text, and the zipped per-snippet data directory.

Last verified 2026-04-30Open record

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.

dandi-nwb

electrophysiologyopenPublished Dandiset metadata and archive endpoints are available through the production DANDI API.

Last verified 2026-04-30Open record

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.

ibl

behavioral-neuroscienceopenPublic sessions can be searched and loaded from the IBL public data server through ONE.

Last verified 2026-04-29Open record

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.

openneuro

neuroscienceopenPublished datasets are available on demand over the internet.

Last verified 2026-04-29Open record