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”
Interaction event data logged by the SMASH medication safety dashboard
<p>Interaction event data logged by the SMASH medication safety dashboard from 21 January 2016 to 13 October 2016.</p>
Simulated Object-Centric Event Logs (OCEL 2.0) for Order-to-Cash, Procure-to-Pay, Hiring, and Hospital Patient Lifecycle Processes
<p>This dataset contains simulated object-centric event logs for four distinct business processes: <strong>Order-to-Cash (O2C)</strong>, <strong>Procure-to-Pay (P2P)</strong>, <strong>Hiring</strong>, and <strong>Hospital Patient Lifecycle</strong>. 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.</p> <p>1. <strong>Order-to-Cash (O2C)</strong>:<br> 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.</p> <p>2. <strong>Procure-to-Pay (P2P)</strong>:<br> 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.</p> <p>3. <strong>Hiring Process</strong>:<br> 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.</p> <p>4. <strong>Hospital Patient Lifecycle</strong>:<br> 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.</p> <p>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.</p> <p>This description will provide the necessary details about the dataset, highlighting its structure, purpose, and potential uses for researchers and process analysts.</p> <p>Object-centric event logs conceived and simulated by the <strong>o1-preview-2024-09-12</strong> LRM, using the https://github.com/fit-alessandro-berti/llm-ocel-simulator project.</p> <p> </p> <p> </p>
(Un)Fair Process Mining Event Logs (Converted to OCEL)
<p><strong>Converted to OCEL 1.0 JSONOCEL and OCEL 2.0 XML from traditional event logs available at: </strong><a href="https://zenodo.org/records/8059489" target="_new" rel="noopener">Zenodo - Record 8059489</a>.</p> <p><strong>Object Types:</strong> <code>{ Person }</code></p> <p><strong>Person-level Attributes:</strong></p> <ul> <li><strong>(int) overallProtected:</strong> An attribute (0/1) indicating whether the person has experienced discrimination. <em>(Note: If you're developing a fairness assessment algorithm, only use this attribute in the testing phase!)</em></li> <li><strong>(int) sumBoolDiscrFactors:</strong> Counts the number of possible discrimination factors that apply to the person.</li> <li><strong>(int) reworkedActivities:</strong> The total amount of rework involved in the person’s processing.</li> <li><strong>(float) throughputTime:</strong> The total processing time for a person.</li> <li><strong>(int) numOcc_ACTIVITY:</strong> Counts the number of times an activity occurs in the person’s lifecycle.</li> </ul> <p><strong>Event-level Attributes:</strong></p> <ul> <li><strong>resource:</strong> The resource involved in processing a given person.</li> </ul> <p> </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>
Manually Annotated Event Log of Users Prompts in LLMs for Conceptual Modeling
<p>This repository contains the supplementary material for our paper at ER 2024 Conference. </p> <p>The data contains the results of an empirical study with 76 undergraduate information systems students. The students submitted the course assignments in 39 groups (of one or two students). The assignment used for the study required use case modeling with UML use case diagrams and domain modeling with UML class diagrams. The groups were first expected to interact with an LLM and then, if needed, to manually improve their models. Groups were randomly assigned to interact with either GPT 4.0 or Code Llama 34B Instruct in one of three application domains. </p> <p>The participants were instructed to engage with the LLM until they were satisfied with the results or opted to skip further refinement. The interaction log contains the following fields: User ID, Input (the user prompt), Response (the modeling artifacts), and the Prompt Number (within user ID).</p>
Temporal Event Knowledge Graphs transformed from Object-Centric Event Logs
<p>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:</p> <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> <p>The version of the dump files is <strong>5.12.0</strong>. Additionally, for restoring dump files inside Neo4j, you need to enter the username and password, which is indicated below:</p> <p><strong>Username</strong>: neo4j</p> <p><strong>Password</strong>: 12345678</p> <p> </p>
Translucent Event Logs based on the Sepsis Event Log and the Inductive Miner - infrequent
<p>The translucent events logs in this file are based on the Sepsis Event Log (https://data.4tu.nl/articles/dataset/Sepsis_Cases_-_Event_Log/12707639/1) published by Felix Mannhardt. The folders' name specify the threshold setting of the Inductive Miner - infrequent (0.4, 0.6, and 0.8). Details on the generation can be found in https://doi.org/10.1007/978-3-031-70396-6_9.</p>
Translucent Event Logs based on the Road Traffic Fine Management Event Log and the Inductive Miner - infrequent
<p>The translucent events logs in this file are based on the Road Traffic Fine Management Event Log (https://data.4tu.nl/articles/dataset/Road_Traffic_Fine_Management_Process/12683249) published by Massimiliano de Leoni and Felix Mannhardt. The folders' name specify the threshold setting of the Inductive Miner - infrequent (0.4, 0.6, and 0.8). Details on the generation can be found in https://doi.org/10.1007/978-3-031-70396-6_9.</p>
Differentially Private Release of Event Logs for Process Mining
<p>The anonymized event logs of the experiments in the paper "Differentially Private Release of Event Logs for Process Mining"</p>
Sighting data and tactile events logged from mixed-group underwater interactions
<p>Interactions between mammalian social groups are generally antagonistic as individuals in groups cooperate to defend resources from non-members. Members of the family Delphinidae inhabit a three-dimensional habitat where resource defense is usually impractical. Here, we describe a long-term partial fusion of two communities of Atlantic spotted dolphins (<i>Stenella frontalis</i>). The northern community, studied for 30 years, immigrated 160 km to the range of the southern community, observed for 20 years. Both communities featured fission-fusion grouping patterns, strongest associations between adult males, and frequent affiliative contact between individuals. For the five-year period following the immigration, we found members of all age classes and both sexes in mixed groups, but there was a strong bias toward finding immigrant males in mixed groups. Some association levels between males, and males and females, from different communities were as high as the highest within-community associations. Affiliative contacts indicate that these individuals were forming bonds, likely for future mating opportunities. The mixing of two separate social groups with new bond formation is rare in terrestrial mammal groups. Such mixing between spotted dolphin groups suggests that adaptations to respond aggressively to 'outsiders' is diminished in this species and possibly other ecologically similar dolphins.</p>
High-Utility Anonymization of Event Logs for Process Mining: Supplementary Material
<p>In this document, we list the selected event logs, their characteristics, and their descriptive statistics. Also, attached to this document the anonymized event logs.</p>
Verifying the Conformance of Human Behavior Using Hybrid Models - Synthetic Event Logs
<p>Synthetic event logs used in the evaluation of the approach for the verification of conformance checking of human behavior, using hybrid process models.</p>
A Collection of Event Logs of Blockchain-based Applications
<p>A set of event logs of 101 blockchain-based applications (DApps). For each DApp, there are two event log files. The first one is a raw version where data is encoded by blockchain. The second file is a decoded version where data is decoded into a human-readable format. If a DApp has multiple versions on different blockchain networks, then there are two event log files (encoded and decoded) for each version. In addition, the event registry file includes a comprehensive list of event names and their corresponding signatures obtained from contract ABIs of the 101 DApps. </p>
Event logs containing deletions
<p>Supplemental dataset containing deletions.</p>
Collection of Object-Centric Event Logs (OCEL 1.0 format; JSON-OCEL specification)
<p>We provide some realistic examples of logs in the OCEL standard. The logs have originally been published at https://www.ocel-standard.org/ </p>
Sighting data and tactile events logged from mixed-group underwater interactions
Open the record for dataset details and reuse information.
Simulated Event Log: Udon-ya
<p>This dataset is a simulated event log in standard <a href="https://xes-standard.org/">XES format</a>.<br> It contains events pertaining to restaurant operations of a fictional <a href="https://en.wikipedia.org/wiki/Udon">Udon</a>, a Japanese noodle dish, Restaurant. In Japanese:うどん屋 [udon-ya].<br> There are 16,412 generated cases distributed over the span of one year, containing in total 674,486 events of 36 unique activities.<br> The log makes use of the lifecycle extension, providing <em>start</em> and <em>complete</em> events per event instance (+ <em>schedule</em> for one activity).</p> <p>Timestamps are (semi-)realistically distributed over daily and weekly business patterns. The underlying simulation respects resource availability and capacity and incorporates queueing as its main dynamics-drivers in addition to a specified medium-complexity control flow. There is looping behavior, interleaving concurrency and event attribute-dependent control-flow routing.</p> <p>The event log is comprised of three different restaurant processes: <em>preparation (prep)</em>, store <em>opening/closing </em>and <em>service</em>.</p> <ul> <li><em>prep</em>: In the mornings, senior employees prepare ingredients with long cooking/resting times.</li> <li><em>opening/closing: </em>Restaurant setup, opening, cleanup and closing performed with higher propensity by part-time employees.</li> <li><em>service</em>: Customer groups arrive, queue for tables, are seated and order one dish per customer. Then, ordered dishes are prepared concurrently as resource availability permits and served all at once. Finally, the customers at one table eat concurrently but pay and leave the restaurant together (synchronized).<br> There is lunch service ~11:30-14:30 and dinner service ~18:00-21:00 with peak customer rush hours at ~13:00-13:15 and ~18:30-19:00 on weekdays. The restaurant is closed on Mondays.</li> </ul> <p>The dish preparation subprocess has a <em>1 to n</em> multiplicity with cases, making the log pseudo-object centric. Dishes have a unique global id which is referenced in all associated events.</p> <p> </p> <p>Organizationally, there are six different employees with varying working hours, capacity and activity assignments, propensities and skill. Activity assignments are based on a division of back of the house (<em>BOH</em>) and front of the house (<em>FOH</em>). There are also additional resources to represent, e.g., the restaurant table capacity.</p> <ul> <li><em>Tenchou-san</em> (Jap. 店長), the shop manager. Up to two times faster than the other cooks. Mostly <em>BOH</em>.</li> <li><em>Oku-san</em>, the shop manager's wife. Bridge between <em>BOH </em>and <em>FOH</em>.</li> <li><em>Deshi-san A</em> & <em>B</em>, two skilled cooks. Only <em>BOH</em>.</li> <li><em>Baito-san A</em> & <em>B</em>, two part-time workers mostly serving customers (<em>FOH</em>).</li> </ul> <p> </p> <p>Furthermore, there are five engineered instances of temporary concept drift with varying impact within the overall process span from 2023-04-01 to 2024-03-31.</p> <ol> <li>From 2023-06-20 to 2023-07-26: Decreased customer arrival rate and group size, resulting in visibly reduced activity.</li> <li>From 2023-09-01 to 2023-10-22: Slightly increased customer arrival rate and group size.</li> <li>From 2023-10-15 to 2023-11-05: Most important (human) resource becomes unavailable, resulting in increased utilization of compensating resources.</li> <li>From 2023-11-19 to 2023-12-10: Reduced restaurant table capacity, not causing any prominent effects.</li> <li>From 2023-12-10 to 2024-01-15: Increased restaurant table capacity, not causing any prominent effects.</li> </ol> <p> </p> <p>The simulation software used is a past version of <a href="https://git.rwth-aachen.de/leah.tgu/qprsim">https://git.rwth-aachen.de/leah.tgu/qprsim</a>, by the same author as this dataset. The repository specifically contains the configuration for this log generation as a Jupyter notebook in <em>sample/udonya.ipynb</em>.</p>
Collection of Object-Centric Event Logs (OCEL 2.0 format; SQLite specification)
<p>We provide some realistic examples of logs in the OCEL 2.0 standard.</p>
Collection of Object-Centric Event Logs (OCEL 2.0 format; XML specification)
<p>We provide some realistic examples of logs in the OCEL 2.0 standard.</p>
Container Logistics Object-centric Event Log
<p><strong>General Description</strong></p> <p>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.</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. </p> <p><strong>Process Overview</strong></p> <p>From a <strong>customer order</strong> perspective, the process begins when the order is registered at our company <em>(register customer order)</em>. After registration, a <strong>transport document</strong> is created in which details of the further process are recorded <em>(create transport document)</em>.</p> <p>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 <strong>vehicle</strong> 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 <em>(book vehicles)</em>. Once the dates for transporting the goods to the terminal are set, our company contacts a <strong>container</strong> depot to reserve the required containers <em>(order empty containers)</em>.</p> <p>When a container’s vehicle departure approaches, the goods are prepared, packed and shipped to the terminal. For this purpose, a <strong>truck</strong> is sent to the container depot <em>(pick up empty container)</em>. Meanwhile, the ordered goods to be shipped are packed into <strong>handling units</strong> at the production site. After loading the handling units <em>(load truck)</em>, the truck drives the full container to the terminal <em>(drive to terminal)</em>.</p> <p>At the terminal, the container is picked up by a free <strong>forklift</strong> and weighed <em>(weigh)</em>. Unless the vehicle departure is imminent, the container is placed in the storage location at the terminal <em>(place in stock)</em>. Finally, it is moved to the vehicle <em>(bring to loading bay, load to vehicle)</em> which departs at a fixed time <em>(depart)</em>.</p> <p>Despite careful planning, containers sometimes miss a vehicle’s departure. In this case, the container is rescheduled to the next possible vehicle <em>(reschedule container)</em> and kept near the loading ramp until then.</p> <p>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></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>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> <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> <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> <p> </p> <p><strong>Object Relationships </strong></p> <p> </p> <p>During the process, object-to-object relations can emerge at activity occurrences as follows.</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 Transport<br> 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<br> Containers</td> <td>Transport Document</td> <td>Container</td> <td>CR for TD</td> </tr> <tr> <td>Pick Empty<br> 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<br> Container</td> <td>Transport Document</td> <td>Vehicle</td> <td>Substitute VH for TD</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. <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.</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>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.</p>
Palmer (PAL) log of events aboard Palmer LTER cruises off the coast of the Western Antarctic Peninsula (cruise happenings ordered by time) is a meta dataset, including lat-lon, datetime, activity, events, etc, 1991 - 2019.
The event log for the Palmer LTER research cruises provides a mapping of sampling and other research activities to spatial, temporal and other variables. Event numbers are used to coordinate relational indexes and provide users of the data with a high-level index for relating measurements across research components.
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.