lestropie / bids-specification

Brain Imaging Data Structure (BIDS) Specification

The Brain Imaging Data Structure (BIDS) is an emerging standard for the organisation of neuroimaging data.

In this repository, we develop the BIDS specification.

When to use BIDS

To organize your data in BIDS, all you need is neuro data, a computer, and the BIDS specification.

BIDS currently supports the following data modalities with more to come in the future:

• MRI
• MEG
• EEG
• iEEG
• behavioral
• physiological
• PET

Formatting your data with BIDS

As a dataset curator, the GitHub repository and all files therein can be safely ignored. Users should focus on the rendered content. The specification is provided in the form of a webpage, built using MkDocs and Read the Docs.

Want to learn more about working with BIDS? Have a question, comment, or suggestion?

1. Read some introductory material, most likely the very basic problems have already been addressed!

• BIDS Starter Kit for tutorials, wikis, templates, ...

2. Post your question in one of several channels where BIDS members are active

• the NeuroStars discourse forum
• the BrainHack Mattermost, for instant messaging (see also this news item)
• the Google group, for broader discussions surrounding BIDS
• the specification repository issue page, if you found inconsistencies, typos, or other issues with the BIDS specification itself

Contributing to BIDS

BIDS is a community-driven standard, and it depends on contributions from its members. We welcome new contributors, and we appreciate all contributions to the project!

For a current list of our contributors, please see our Contributors appendix.

When you're ready to get started, check out our contributing guidelines.

We ask that all contributions to BIDS across all project-related spaces (including but not limited to: GitHub, the Google group, and newsletter emails), adhere to our code of conduct.

bids-specification's Issues

Programmatic utilisation of inheritance principle

This is a proposal for development of a new piece of software that would reside within the BIDS ecosystem.

---

There is debate about the utility of the inheritance principle. Some are pushing to make the principle even more generalised and powerful (eg. bids-standard#1003, #5), others think that the entire principle should be removed from the specification. And it seems that many users struggle to understand the concept itself adequately in order to take advantage of it.

Further, it could be argued that existing software tools fail to properly make use of it, therefore relying on manual interaction:

• For BIDS Raw data (using MRI as an example since it's familiar to me), one typically uses DICOM to NIfTI conversion software that produces one sidecar JSON alongside each NIfTI image, but each of these conversions is essentially independent of all others. So if there is common content across the DICOM data of multiple series, these data will be duplicated across multiple sidecars.

• For BIDS Derivatives data, such data would typically be generated by processing each participant individually. There may be metadata geenrated by the BIDS App that is consistent across all participants, but that content is duplicated across all participants.

  (You do not want a BIDS App to be writing metadata from a participant-level analysis at a higher level in the filesystem hierarchy than the participant itself in order to be inherited by data from all participants, since this could lead to race conditions in the scenario where multiple participants are processed in parallel.)

---

What I propose here is that in both of these scenarios, optimal exploitation of the inheritance principle could be achieved programmatically. A new software tool would be executed upon completion of generation of a dataset (eg. conversion of all DICOM data for all participants in the case of BIDS Raw, processing of all participants in the case of BIDS Derivatives). For each unique metadata key-value pair, it would find the highest possible level in the filesystem hierarchy and the minimal set of entities by which that metadata key would still be associated with all data files to which it is applicable, and still not be associated with all data files to which it is not applicable. The metadata files of the dataset would then be re-written in such a way that no metadata key-value pair is unnecessarily duplicated, and interpretation of the dataset is unaffected as long as the inheritance principle is obeyed (and this would likely depend on software packages making use of BIDS APIs that themselves properly load metadata in a manner faithful to the inheritance principle).

This wouldn't be a BEP, but a piece of software that is intended for utilisation within experiments that themselves utilise BIDS. So similar to BEP015, which became the File Mapper utility.

I can potentially create a toy example demonstrating what such a tool would do to an exemplar dataset if there is adequate interest in the concept. I'll hold off on investing that effort for now, in part because the scope of the inheritance principle is right now under debate as part of the BIDS Connectivity project.