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.

672

datasets available to search

ShareScore release 0.9.0

Dataset results

672 results for “Logs”

Learn how ShareScore rates datasets ↗

zenodo40/100

BPM Synthetic UI Logs Collection

This data package described in the BPM Demos&Resources publication entitled: "BPM Hub: An Open Collection of UI Logs", consists of synthetic UI logs along with corresponding screenshots. The UI logs closely resemble real-world use cases within the administrative domain. They exhibit varying levels of complexity, measured by the number of activities, process variants, and visual features that influence the outcome of decision points. For its generation, the <a href="https://canela.lsi.us.es/bpmloggenerator/">BPM Log Generator tool</a> has been used, which requires the following initial generation configuration: Initial Generation Configuration <ul> <li>Seed log: Includes a single instance for each process variant and their associated screenshots.</li> <li>Variability configuration: <ul> <li>Case-level: Refers to variations in the content that can be introduced or modified by the user, such as variations in the text inputs, selectable options, checkboxes, etc.</li> <li>Scenario-level: Refers to varying the GUI (Graphical User Interface) components related to the look and feel of the different applications appearing in the process screenshots.</li> </ul> </li> </ul> Data Package Contents The data package comprises three distinct processes, P1, P2, P3, for which their initial configuration is provided, i.e., a tuple of <SeedLog, Case-level variability conf., Scenario-level variability conf.>. They are characterized by the following: P1. Client Creation <ul> <li>Activities: 5</li> <li>Variants: 2</li> <li>Decision point: Revolves around the presence of an attachment in the reception of an email.</li> </ul> P2. Client Deletion. User's presence in the system <ul> <li>Activities: 7</li> <li>Variants: 2</li> <li>Decision point: Based on the result of the user's search in the Customer Management System (CRM), represented by a checkbox.</li> </ul> P3. Client Deletion. Validation of customer payments <ul> <li>Activities: 7</li> <li>Variants: 4</li> <li>Decision: Involves two conditions: <ol> <li>The presence of an attachment justifying the payment of the invoices in the email.</li> <li>The existence of pending invoices in the user CRM profile.</li> </ol> </li> </ul> These problems depict processes with a single decision point, without cycles, and executed sequentially to ensure a non-interleaved execution pattern. Particularly, P3 shows higher complexity as its decision point is determined by two visual characteristics. Generation of UI Logs For each problem, case-level variations have been applied to generate logs with different sizes in the range of {10, 25, 50, 100} events. In cases where the log exceeds the desired size, the last instance is removed to maintain completeness. Each log size has its associated balanced and unbalanced log. Balanced logs have an approximately equal distribution of instances across variants, while unbalanced logs have a frequency difference of more than 20% between the most frequent and least frequent variants. Scenarios To ensure the reliability of the obtained results, 30 scenarios are generated for each tuple <Problem, LogSize, Balanced?>. These scenarios exhibit slight variations at the scenario-level, particularly in the look and feel and user interface of the applications depicted in the screenshots. Each scenario consists of UI logs that correspond to specific problems categorized by log size (10, 25, 50, 100) and balanced? (Balanced, Unbalanced). Folders containing UI logs and their corresponding screenshots are organized in folders named as follows: sc{scenarioId}_size_{LogSize}_{Balanced?}. Additional Artefacts In addition, each problem includes two more artefacts: <ul> <li>initial_generation_configuration folder: Holds the data needed for problem data generation using the [5] tool.</li> <li>decision.json file: Specifies the condition driving the decision made at the decision point.</li> </ul> decision.json The decision.json acts as a testing oracle, serving as a label for validating mined data. It contains two main sections: "UICompos" and "decision". The "UICompos" section includes a key for each activity related to the decision, storing key-value pairs that represent the UI components involved, along with their bounding box coordinates. The "decision" section defines the condition for a case to match a specific variant based on the mentioned UI components.

opencc-by-4.0Jun 2023View details →

zenodo40/100

Borehole logs of the projects STIMTEC and STIMTEC-X

Logs available for each borehole in the Research mine Reiche Zeche (Freiberg, Germany) during the projects STIMTEC and STIMTEC-X. Logging operations were carried out by LIAG (Hannover, Germany). The types of data available include optical televiewer (OTV) and acoustic televiewer (BHTV) logs, as well as sonic and caliper logs.

opencc-by-4.0Aug 2023View details →

zenodo40/100

Results and log of LLM-KG-Bench runs described in article "Developing a Scalable Benchmark for Assessing Large Language Models in Knowledge Graph Engineering", Meyer et al. 2023

Results and logs of <a href="https://github.com/AKSW/LLM-KG-Bench">LLM-KG-Bench</a> runs described in article "Developing a Scalable Benchmark for Assessing Large Language Models in Knowledge Graph Engineering", Meyer et al., to appear in <a href="https://2023-eu.semantics.cc/page/accepted_posters">SEMANTICS 2023 poster track</a> proceedings.

opencc-by-4.0Aug 2023View details →

zenodo40/100

SeaPaCS sampling log and samples

The file contains two sheets: one is the sample log for the sampling performed on the 14th and 15th of July, in Anzio (RM), Italy (harbour and coastal samples), as well as a first description of the samples collected.  The two tows with the neuston net allowed an approximate calculation of the average plastic concentration (particles > 300 µm) per cubic meter of seawater along the coast of Anzio.  This is the updated version as there was a mistake in the number of plastics found (68 instead of 72 as wrongly reported previously).

opencc-by-4.0Sep 2023View 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 →

dryad40/100