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.
260
datasets available to search
ShareScore release 0.9.0
Dataset results
260 results for “Empirical Study”
An Empirical Evaluation of Competitive Programming AI: A Case Study of AlphaCode
<p><strong>Abstract</strong><br> AlphaCode, the code generation system by DeepMind, is an AI technology for assisting software developers in solving competitive programming problems using natural language problem descriptions.<br> However, there is no existing work comparing AlphaCode-generated codes with human codes.<br> In this paper, we conduct an empirical study to find code similarities and performance differences between AlphaCode-generated codes and human codes.<br> We collect 44 generated codes in C++ and Python languages from AlphaCode official website that solve 22 problems on Codeforces.<br> We then retrieve 31,736 human codes by using Codeforces API.<br> The results show that (i) the generated code from AlphaCode and the human code is not similar (i.e., the similarity of 0.26 for both C++ and Python), however, the code fragments in the generated code are comprised of various human codes (i.e., uniqueness of 3.30\% and 8.94\% for C++ and Python respectively) and<br> (ii) the generated code performs on par with or worse than the human code in terms of execution time and memory usage.<br> Moreover, AlphaCode employs excessive nested loops and unnecessary variable declarations (e.g., used \textit{long long} instead of \textit{int}), which causes a low performance regarding our manual investigation.</p>
Artefact to our paper "An Empirical Study of Automated Unit Test Generation for Python"
<p><strong>Artefact for “An Empirical Study of Automated Unit Test Generation for Python”</strong></p> <p>Together with our paper “An Empirical Study of Automated Unit Test Generation for Python”, we provide this artefact for future use.</p> <p><strong>Pynguin Version</strong></p> <p>We used Pynguin 0.25.2 for our experiments. The releases of Pynguin are archieved by Zenodo, too. Pynguin 0.25.2 is available under DOI <a href="https://doi.org/10.5281/zenodo.6836225">10.5281/zenodo.6836225</a>.</p> <p><strong>Preparation of the Environment</strong></p> <p>We use the <a href="https://python-poetry.org"><code>poetry</code></a> dependency-management tool to manage all dependencies for this artefact. Install this tool if you have not done yet. Furthermore, let <code>poetry</code> create a virtual environment for the experiment by execution <code>poetry install</code>.</p> <p><strong>Execution of the Experiment</strong></p> <p>The execution scripts make several assumptions that are based on our infrastructure. We maintain a SLURM cluster infrastructure that defines different <code>constraints</code> for different machines.</p> <p>Furthermore, we assume some paths to be present: we assume every computing machine to have writable mount points at <code>/local/${USER}</code> and <code>/local/hdd/${USER}</code>. On our machines, both are mount points on the local hard disk/SSD of the computing machines. Additionally, we have a shared mount <code>/scratch/${USER}</code>, which is mounted via NFS from a central file server. This mount point is also mounted on all computing machines.</p> <p>We assume the created and packaged Docker image to be located at <code>/scratch/lukasczy/pynguin.tar</code>. You can change this path by editing the XML files. These XML files contain the basic definitions of the jobs: they specify the SLURM constraint, the version of the Pynguin Docker container, the used Pynguin configurations as well as the modules used for the experiments. These modules have to reside under <code>projects</code>, as they come with this artefact.</p> <p>The Python script <code>execution.py</code> generates the actual run scripts from the XML file. It generates all scripts necessary to run a SLURM array job consisting of all runs for the experiment. Further general settings for the SLURM array job are present in this file.</p> <p>The Bash script <code>run_experiment.sh</code> executes the full execution pipeline; one has to specify the variable <code>EXPERIMENT_NAME</code> to match the name of the respective XML file who's defined experiment shall be executed.</p> <p><em>Important:</em> Executing the full experiment can take several days, depending on your computing infrastructure! We do therefore provide the raw result CSVs for further inspection.</p> <p><strong>Data Analysis</strong></p> <p>All raw data resides in the <code>data</code> folder:</p> <ul> <li><code>loc_data.csv</code> contains all information about the lines of code in each module. This file was created using the <code>extract_locs_and_types.py</code> script in the root folder. Please note that executing this script requires that the <code>cloc</code> utility tool is installed on your system's path.</li> <li><code>types.csv</code> and <code>types_per_module.csv</code> contain type information extract from the modules at different granularity level. They are also generated using the aforementioned script.</li> <li><code>results-assertion.csv.xz</code> contains the raw results from the experiment for RQ3 that evaluates the effectiveness of the assertions.</li> <li><code>results.csv.xz</code> contains the raw results from the experiment for RQ1 and RQ2.</li> </ul> <p>We provide the Jupyter Notebook that generated the plots, tables, and various LaTeX macros in the <code>notebooks</code> folder. Please note that if you want to reexecute this notebook, you might have to change the <code>PAPER_EXPORT_PATH</code> constant in cell <code>[2]</code> to a suitable location on your machine. Executing this notebook requires a installation of a TeX system to be available on your system because the plots are generated using <code>pdflatex</code> and <code>matplotlib</code>s pgf backend.</p> <p><strong>Further Data</strong></p> <p>The folder <code>projects</code> contains all the projects in the versions stated in our paper. The folder <code>run-logs</code> contains all the run logs from our experiment executions.</p>
Artifact for ESEC/FSE Paper: "23 Shades of Self-Admitted Technical Debt: An Empirical Study on Machine Learning Software"
<p>Artifact for ESEC/FSE paper entitled "23 Shades of Self-Admitted Technical Debt: An Empirical Study on Machine Learning Software"</p>
An empirical study on the influence of developers' experience on software test code quality
<p>Software developers' engagement in open-source software projects lies in different levels of participation, e.g., core or peripheral developers. Recent studies have investigated the role of developers' contributions and their influence on software quality. However, few studies investigate the relationship between the developers' experience and test code quality in software projects. In this study, we aim to investigate the relationship between the developers' experience and the test code quality from the perspective of test smells. We performed an empirical study to analyze the insertion and removal of test smells in four open-source Java projects. We collected 18 test smells and calculated their authorship through the projects' Tags. The four software projects contain 386 test classes and 5,178 test smells. We found out that the insertion of 67.28\% of test smells occurs during the test class creation, and the removal of 20.88\% of test smells occurs during the evolution of projects. In addition, core developers are responsible for inserting 88.91\% and removing 89.82\% test smells. Core developers insert and remove more test smells than the peripheral developers. Most test smell removal is due to test code deletion, which may indicate that both core and peripheral developers are unaware of test smells in test code.</p>
Curated dataset of bug fix commits from "An Empirical Study on Real Bug Fixes"
<p>To cite it:</p> <p><code>@misc{bfdataset,<br> author = {Martin Monperrus},<br> title = {Curated dataset of bug fix commits from "An Empirical Study on Real Bug Fixes"},<br> year = 2017,<br> doi = {10.5281/zenodo.1004734},<br> url = {https://doi.org/10.5281/zenodo.1004734}<br> }</code></p> <pre> </pre> <p> </p>
Replication Kit for Paper: "Are There Any Unit Tests? An Empirical Study on Unit Testing in Open Source Python Projects"
<p>Replication Kit for the Paper "Are there any Unit Tests? An Empirical Study on Open Source Python Projects" by Fabian Trautsch, Jens Grabowski.</p> <p>You can cite the paper via:</p> <p>@inproceedings{trautsch2017there,<br> title={Are There Any Unit Tests? An Empirical Study on Unit Testing in Open Source Python Projects},<br> author={Trautsch, Fabian and Grabowski, Jens},<br> booktitle={Proceedings of the IEEE International Conference on Software Testing, Verification and Validation (ICST)},<br> pages={207--218},<br> year={2017},<br> organization={IEEE}<br> }</p> <p> </p> <p>Contents:<br> 1) Used version of the vcsSHARK<br> - located in “vcsSHARK”<br> 2) Used version of the testImpSHARK<br> - located in “testImpSHARK”<br> 3) Analysis implementations<br> - located in “testImpSHARK/testimpshark/analysis”<br> 4) Raw Data CSV Files<br> - located in “testImpSHARK/testimpshark/analysis/data<br> 5) Raw MongoDB<br> - located in “mongo_backup”</p> <p><br> Usage:<br> 1) Usage instructions for the vcsSHARK is given on its github homepage (http://ftrautsch.github.io/vcsSHARK/index.html) or directly in the “vcsSHARK/pyvcsshark/main.py” file</p> <p>2) Usage instructions for the testImpSHARK:<br> - if only one revision should be analyzed use “testImpSHARK/main.py”<br> - if all revisions should be analyzed use “testImpSHARK/execution.py”<br> - in both files concrete instructions can be found</p> <p>3) Each analysis file is commented. For some of them (rq1_boxplot.py and rq4.py the connection to the MongoDB must be changed). For the R files, the path to the data must be adapted. Otherwise, the files can be directly executed.</p> <p>4) The MongoDB can be restored via:<br> mongorestore --gzip --archive=smartshark040816.gz --db smartshark --host <HOST> --port <PORT> --username <USERNAME> --password <PASSWORD> --authenticationDatabase <AUTHENTICATION_DATABASE></p> <p><br> Tests:<br> 1) The tests can be run directly via the unittest framework of python: e.g., python -m unittest tests/test_common.py</p>
Data for: Evolution Reinforces Cooperation with the Emergence of Self-Recognition Mechanisms: an empirical study of the Moran process for the iterated Prisoner's dilemma using reinforcement learning
<p>This contains data used for a paper titled: Evolution Reinforces Cooperation with the Emergence of Self-Recognition Mechanisms: an empirical study of the Moran process for the iterated Prisoner's dilemma using reinforcement learning.</p> <p>Numerous data sets are included, the main being `main.csv` which includes the fixation counts for a number of Moran processes between pairs of players from the Axelrod library.</p> <p>The source code and explanation of the data is here: https://github.com/Axelrod-Python/axelrod-moran. </p> <p> </p>
Supplementary materials to the article "Practices and attitudes toward replication in empirical translation and interpreting studies"
<p><strong>Abstract of the paper:</strong></p> <p>This article presents the results of three studies on practices in and attitudes toward replication in empirical translation and interpreting studies. The first study reports on a survey in which 52 researchers in translation and interpreting with experience in empirical research answered questions about their practices in and attitudes toward replication. The survey data were complemented by a bibliometric study of publications indexed in the Bibliography of Interpreting and Translation (BITRA) (Franco Aixelá 2001–2019) that explicitly stated in the title or abstract that they were derived from a replication. In a second bibliometric study, a conceptual replication of Yeung’s (2017) study on the acceptance of replications in neuroscience journals was conducted by analyzing 131 translation and interpreting journals. The article aims to provide evidence-based arguments for initiating a debate about the need for replication in empirical translation and interpreting studies and its implications for the development of the discipline.</p> <p><strong>Description of the supplementary materials:</strong></p> <ul> <li>Material 1: questionnaire in English</li> <li>Material 2: questionnaire in Spanish</li> <li>Material 3: results of both questionnaires</li> <li>Material 4: corpus of identified replications in Translation and Interpreting Studies (TIS)</li> <li>Material 5: acceptance of replications in TIS journals</li> </ul>
Deep learning based Image Compression for Microscopy Images: An Empirical Study
<p>This dataset supports the manuscript titled "Deep Learning Based Image Compression for Microscopy Images: An Empirical Study." The materials provided are essential for replicating the experiments in the study. The dataset is divided into three main parts:</p> <ol> <li>Config: train and test yaml config files for both 2D and 3D mmv_im2im labelfree task</li> <li>Sample_data: sample data to test the compression and the downstream labelfree code, in both 2D and 3D case.</li> <li>Model: fine-tuned 2D/3D labelfree model and 3D compression model. We use pre-trained 2D compression models from CompressAI</li> </ol> <p> </p>
An Empirical Study on Challenges of Event Management in Microservice Architectures
<p>Data set of the submitted manuscript "An Empirical Study on Challenges of Event Management in Microservice Architectures"</p>
Raw Coding Data for "Insights for Improving Diagram Editing Gained from an Empirical Study"
<p>This MaxQDA Exchange file contains the raw coding data for "Insights for Improving Diagram Editing Gained from an Empirical Study"</p>
Data of the Paper "How to Communicate when Submitting Patches: an Empirical Study of the Linux Kernel"
<p>This repository includes the data of the paper "How to Communicate when Submitting Patches: an Empirical Study of the Linux Kernel".</p> <p>It contains three parts:</p> <ol> <li>Related online documents.</li> <li>Original questionnaire of the survey.</li> <li>Survey results.</li> </ol> <p> </p>
On the Continuous Code Quality Outcomes of Continuous Integration: An Empirical Study
<p>Here we provide all datasets that we rely on in our research questions and all violin plots for RQ3</p>
An Empirical Study of Word Embedding Dimensionality Reduction
<p>In order to analyze the impact on model quality while reducing the number of dimensions, strictly controlled trainings of word embedding are performed on Wikipedia corpora of 170 languages. The specially designed word embedding training tool makes use of processed corpus and intermediate results to accelerate the training, while keeping the consistency of negative sampling.</p> <p>Tests of semantic relatedness show that, except for some corpora of poor scale, the margin gain from extra dimensions significantly decreases above 200.</p>
Dataset for "Property-based Testing within ML Projects: an Empirical Study" (ICSME NIER 2024)
<p>The dataset for the ICSME NIER 2024 paper "Property-based Testing within ML Projects: an Empirical Study". Descriptions of each column can be found in the readme.md file.</p>
Online Appendix of "Toward Interactive Optimization of Source Code Differences: An Empirical Study of Its Performance"
<div> <div><strong>Abstract</strong></div> <div>This is the dataset of the paper entitled "Toward Interactive Optimization of Source Code Differences: An Empirical Study of Its Performance", presented at SCAM 2024. It contains information related to the target commits and their attributes, as well as simulation results pertaining to the research questions in the paper.</div> <div> </div> <div>The target projects and commits in the dataset are based on a prior study: Nugroho, et al.: "How different are different diff algorithms in Git?: Use --histogram for code changes", Empirical Software Engineering, 2020, https://doi.org/10.1007/s10664-019-09772-z</div> <div> </div> </div> <div> <div><strong>Survey Overview</strong></div> <div> <div><em>1. Filtration</em></div> <div> <div>We collected attributes related to the changes for filtering and RQ purposes.</div> <ul> <li>Number of lines</li> <li>Number of changed lines</li> <li>Similarity distance</li> <li>Number of mismatch diff area</li> </ul> <div><em>2. RQ1</em></div> <div> <div>We investigate the minimum number of feedback actions needed to correct the initial diffs to the target diffs. Regarding the simulation, two types of heuristic functions (non-admissible and admissible functions) have been used to reduce costs. When the search with the non-admissible heuristic function of the initial state does not match the ideal optimal result, i.e., when there is room for improvement in the number of feedback actions, we applied another A* search with the admissible heuristic function.</div> <div> </div> <div> <div>We obtained the following results through search:</div> <ul> <li>Number of feedback actions (A* search with non-admissible heuristic)</li> <li>Number of feedback actions (A* search with admissible heuristic)</li> </ul> <div> </div> <div><em>3. RQ2</em></div> <div> <div> <div>We investigated the various effects that feedbacks have on the diffs by examining the diffs at depth 1 of the search tree. The dataset records the maximum, minimum, median, mean, and standard deviation for each search problem.</div> <br> <div>The study yielded the following results:</div> <ul> <li>Similarity distance</li> <li>Number of mismatch diff area</li> </ul> </div> </div> </div> </div> </div> </div> <div> <div> </div> <div> <div><strong>Dataset Columns</strong></div> <div>The following are the contents represented by the columns in the CSV file and their descriptions.</div> <div> </div> <div> <table> <tbody> <tr> <td>Column name</td> <td>Description</td> </tr> <tr> <td>project_name</td> <td>Name of the project associated with the data.</td> </tr> <tr> <td>filename</td> <td>Name of the file being analyzed.</td> </tr> <tr> <td>filepath</td> <td>Path to the file within the project.</td> </tr> <tr> <td>commit_id</td> <td>Commit hash representing the new version of the file.</td> </tr> <tr> <td>parent_commit</td> <td>Commit hash representing the old version of the file.</td> </tr> <tr> <td>error_commit</td> <td>An error occurred when retrieving the commit from the repository.</td> </tr> <tr> <td>error_setup</td> <td>Any error when generating the new and old versions of the file.</td> </tr> <tr> <td>error_analyze</td> <td>An error when collecting information for filtering.</td> </tr> <tr> <td>new_loc</td> <td>Lines of the new version of the source code.</td> </tr> <tr> <td>old_loc</td> <td>Lines of the old version of the source code.</td> </tr> <tr> <td>histogram_len</td> <td>Path length of the diff when using the Histogram algorithm.</td> </tr> <tr> <td>myers_len</td> <td>Path length of the diff when using the Myers algorithm.</td> </tr> <tr> <td>histogram-myers#edge</td> <td>Number of difference edges between Histogram and Myers diff.</td> </tr> <tr> <td>histogram-dp#edge</td> <td>Number of difference edges between Histogram and initial diff.</td> </tr> <tr> <td>myers-dp#edge</td> <td>Number of difference edges between Myers and initial diff.</td> </tr> <tr> <td>histogram-myers#area</td> <td>Number of mismatch diff areas between Histogram and Myers diff.</td> </tr> <tr> <td>histogram-dp#area</td> <td>Number of mismatch diff areas between Histogram and initial diff.</td> </tr> <tr> <td>myers-dp#area</td> <td>Number of mismatch diff areas between Myers and initial diff.</td> </tr> <tr> <td>dp#candidate</td> <td>Number of feedback candidates of initial diff (similarity distance).</td> </tr> <tr> <td>#insert</td> <td>Number of lines added in the change.</td> </tr> <tr> <td>#delete</td> <td>Number of lines deleted in the change.</td> </tr> <tr> <td>#change</td> <td>#insert + #delete.</td> </tr> <tr> <td>error_Asearch</td> <td>An error occurring during A* search with a non-admissible heuristic.</td> </tr> <tr> <td>#feedback_A</td> <td>Number of feedback actions for A* search with a non-admissible heuristic.</td> </tr> <tr> <td>time_A</td> <td>Time taken for A* search with a non-admissible heuristic (ms).</td> </tr> <tr> <td>RQ1_error_iteration</td> <td>An error when iterations exceed the limit (10,000,000) during A* search with an admissible heuristic.</td> </tr> <tr> <td>RQ1_error_timeout</td> <td>An error when the search time exceeds the limit (1,800 seconds).</td> </tr> <tr> <td>RQ1_error_other</td> <td>Other errors encountered during A* search with an admissible heuristic.</td> </tr> <tr> <td>RQ1#feedback</td> <td>Number of feedback actions for A* search with an admissible heuristic.</td> </tr> <tr> <td>RQ1#iter</td> <td>Number of iterations for A* search with an admissible heuristic.</td> </tr> <tr> <td>RQ1_time</td> <td>Time taken for A* search with an admissible heuristic.</td> </tr> <tr> <td>RQ2_error_exceed</td> <td>An error due to exceeding time or iteration limits in RQ2.</td> </tr> <tr> <td>RQ2_error_other</td> <td>Other errors encountered during RQ2.</td> </tr> <tr> <td>RQ2#children</td> <td>Number of children nodes of the initial state (= similarity distance).</td> </tr> <tr> <td>RQ2#candidate_min</td> <td>Minimum similarity distance among the generated diffs.</td> </tr> <tr> <td>RQ2#candidate_max</td> <td>Maximum similarity distance among the generated diffs.</td> </tr> <tr> <td>RQ2#candidate_ave</td> <td>Average of similarity distance among the generated diffs.</td> </tr> <tr> <td>RQ2#candidate_median</td> <td>Median of similarity distance among the generated diffs.</td> </tr> <tr> <td>RQ2#candidate_sd</td> <td>Standard deviation of similarity distance among the generated diffs.</td> </tr> <tr> <td>RQ2#area_min</td> <td>Minimum number of mismatch diff areas among the generated diffs.</td> </tr> <tr> <td>RQ2#area_max</td> <td>Maximum number of mismatch diff areas among the generated diffs.</td> </tr> <tr> <td>RQ2#area_ave</td> <td>Average number of mismatch diff areas among the generated diffs.</td> </tr> <tr> <td>RQ2#area_median</td> <td>Median number of mismatch diff areas among the generated diffs.</td> </tr> <tr> <td>RQ2#area_sd</td> <td>Standard deviation of number of mismatch diff areas among the generated diffs.</td> </tr> <tr> <td>is_used</td> <td>Indicates whether this data is used in the results of RQ1 and RQ2.</td> </tr> </tbody> </table> </div> </div> </div> </div>
Data Science Tasks used in "AI Support for Data Scientists: An Empirical Study on Workflow and Alternative Code Recommendation"
<p>This entry contains the supplementary files for a scientific article. </p> <p>The dataset contains the necessary files for the two data science tasks used in the experiment study from scientific article "AI Support for Data Scientists: An Empirical Study on Workflow and Alternative Code Recommendation"</p> <p> </p>
Replication package for "An Empirical Study of Q&A Websites for Game Developers"
<p><strong>Replication package for the paper "An Empirical Study of Q&A Websites for Game Developers"</strong></p> <p>This repository contains the datasets and scripts used to replicate the results from the paper "An Empirical Study of Q&A Websites for Game Developers".</p> <p>This is an exact copy of the repository on GitHub: https://github.com/asgaardlab/done-21-arthur-gamedev_qa_websites-code</p> <p><strong>Replication data</strong></p> <p>The datasets used to replicate the results for the paper can be found in the data directory (data/). These are the datasets we obtained after running all of the notebooks in this repository.</p> <p>Two of the studied websites are owned by companies (Epic and Unity) and we are not legally allowed to share the textual contents of the questions and answers as they are considered intellectual property. Therefore, instead of sharing the content of those posts, we included the URLs to all of the pages where the information used in the paper can be found, so that they can be crawled by future researchers.</p> <p>This is not an issue for Stack Overflow and the Game Development Stack Exchange, since that data is provided by Stack Exchange in the Stack Exchange Data Dump (https://archive.org/details/stackexchange).</p> <p><strong>Survey data:</strong> Unfortunately, our University's ethics board only allows us to share the survey responses in aggregated format, which is done in the paper. In this repository, we added the list of communities in which we shared the survey (data/surveyed_communities.csv).</p> <p><strong>Using this repository</strong></p> <p>If you are using the datasets provided in this repository, you just need to run the analysis notebook (code/analysis/paper_results.ipynb) to obtain the results as shown in the paper.</p> <p>Otherwise, if you want to run the whole pipeline from scratch, follow these steps:</p> <p>1. Download the data from Unity Answers and the UE4 AnswerHub from their websites (you can use the URLs provided in our datasets). Parse the HTML pages and extract the required information.</p> <p>2. Download the data from Stack Overflow and the Game Development Stack Exchange from the Stack Exchange Data Dump (https://archive.org/details/stackexchange). Run the notebooks to process the XML files from the Stack Exchange data dump (code/process_xml). For Stack Overflow, run the select_gamedev_posts.ipynb (code/process_xml/stackoverflow/select_gamedev_posts.ipynb) first.</p> <p>3. Run the text processing notebook (code/text_processing.ipynb).</p> <p>4. Run the topic modelling notebook (code/topic_modelling.ipynb).</p> <p>5. Run the topic comparisons notebook (code/topic_comparisons.ipynb).</p> <p>6. Finally, run the analysis notebook (code/analysis/paper_results.ipynb) to get the results as shown on the paper.</p>
Package Quality for Users and Contributors: An Empirical Study of the npm Ecosystem
<p>Dataset for the submission "Package Quality for Users and Contributors: An Empirical Study of the npm Ecosystem"</p>
An Empirical Study of Textual and Structural Statistical Models for Maven-Based Build Systems
<p>Replication package for the manuscript entitled "An Empirical Study of Textual and Structural Statistical Models for Maven-Based Build Systems". See README.md file for details about how to use the package.</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.