How BIDs and BIDs validator has informed the data aggregation needs of the Stimulating Peripheral Activity to Relieve Conditions, SPARC, consortium.

   The use of the BIDs standard format for research objects (RRID:SCR_016124) is becoming relatively well accepted in the neuro-imaging community as a means to package and describe neuro-imaging studies. The format is simple in that it is essentially a folder with a set of specified files and subfolders where different types of data are expected. Files including dataset_description and readme.txt are standardized and expected in the root folder. These and other files describe the dataset that is contained in the folder, with space for textual descriptions of the study, authors, and other relevant metadata. One of the most powerful features of the BIDs format is that the structure is sufficiently formal to create validation code (e.g., BIDs Validator RRID:SCR_017255), an application that checks for the presence of required files, and required fields inside of those files. The BIDs and BIDs validation code are used in several repositories that store imaging data, including OpenNeuro.org (RRID:SCR_005031).

   The SPARC Program (https://commonfund.nih.gov/sparc), funded by the National Institutes of Health, seeks to anatomically and functionally map the peripheral innervation of select organs, building the science and technology base for the next generation of peripheral neuromodulation therapies. To accomplish this goal, a group of data cores are working together with investigators to aggregate sufficient quantities of high-quality imaging, transcriptomics, electrophysiology and other data to vastly improve our understanding of the nerve to organ connectivity. 

   The data handling cores have equal roles in setting up SPARC, and these include: the DAT core, which allows investigators to upload data and stores those data; the SIM core, which can be used by investigators to simulate nerve to organ function on high performance computational resources; and the MAP core, which is responsible for a myriad of functions aimed at making the data more discoverable and reusable.

   One of the problems faced by the SPARC data cores is the lack of a unified standard for data capture across these diverse types of biological data. While there are well known data repositories for data type specific files such as GEO or EEGBase, and there are ‘generalist’ data repositories such as Dryad, there are no specific data repositories that would handle the diversity of data types in a manner that allows for data integration at a sufficient quality as to easily allow for the building of computational models. Indeed, there are no consistent and community accepted standards for metadata reporting across these different data types (Ferguson et al, 2014; PMID:25349910). Therefore, the SPARC consortium has had a tentative agreement among the data sharing committee to attempt to extend the BIDs specification, to fit the SPARC use case. We must note that this is not a BIDs consortium sanctioned activity, nor has the extension been pushed to the BIDs consortium for ratification. This work represents a preliminary attempt to extend BIDs into a format that would be able to handle the types of data that the SPARC consortium generates and an attempt to ask the question whether the format is sufficient for investigators. Therefore, we have dubbed the newly developed format SPARC-BIDs. 

   The major update to the traditional BIDs structure came from adding the notion of a sample file and sample folder. These follow the same general rules as the BIDs subject file and folder, but allow investigators who break their data down not by subject but by sample to “have a place” to put their data. Currently, the state of this work is that the proposed structure is being stress tested by investigators and curators to determine if compliance with the proposed structure is feasible. We will consider success if investigators can follow the guidelines.

   To enable curators to determine if a rather large, motley group of investigators is aligning data to the SPARC structure, we sought computational help. The BIDs validator code has been adapted by our team to verify that required files and folders are present in the data folder (https://github.com/SciCrunch/sparc-curation). The code checks for unexpected file formats, as well as unexpected data within many of the expected metadata files. For example, it checks for uniqueness of subject and sample identifiers, and that dates are reported in a standard format. We note that the validator is a part of a larger curation pipeline, that enables data synchronization between the DAT core, which is the “oracle” for current state of the SPARC datasets, and the actions that the curation team can take to augment and align these data to ontologies and track the provenance of actions. 

   Currently, the initial upload consists of 65 datasets, including 2284 directories, 6937 files, and 2.5*10^12Bytes of data. These data cover the domains of: anatomy, behavior, electrophysiology, cell counting, microscopy, electrophysiology, models, expression, morphology, genomics, radiology, and cystometry. The body structures covered in the data include: ganglia, nerves, connective and adipose tissues, as well as the major organs. A full list, aligned to UBERON (RRID:SCR_010668), NIFSTD (RRID:SCR_005414), and FMA (RRID:SCR_003379) ontologies, will be available when the public data portal is launched (https://sparc.science/). Of these datasets, 44 currently have fewer than 5 submission errors (out of a possible ~5000) reported by the SPARC-BIDs validator, including errors such as date formatting, violations of uniqueness for identifiers, and missing values. The curation team is evaluating the scientific validity of the code reported errors and making minor modifications to the code or the data, or asking data authors to make modifications to the metadata files. However, given that the vast majority of datasets (44 of 65) are reasonably well aligned within two iterations with the laboratories, the SPARC-BIDs data structure appears to meet most use cases in this rather diverse types of data.