https://groups.google.com/forum/#!topic/bids-discussion/TjxOKEB1DD4
Right now I would say that BIDS is "experiment" centric, where experiment is some collection of data from many participants from a single site that is somehow defined by the experiment (or other justification) that was used to collect the data (openfmri calls these datasets, but that word can be applied at many scales so I am avoiding it). As a consequence, much of the data is "bunched" together at the experiment level, for example participant.tsv and the inheritance principle allowing scan parameters at the highest level. In the future, I would expect that more and more users of shared data will be aggregating data across many different datasets, which is a very common mode for FCP/INDI data. When they do this, it is unlikely that users will want to download all of the data for every experiment, but rather cherry pick the data that they want from the many experiments. I think that this would be much easier to accomplish if we changed the focus of BIDS from the experiment bundle to the lowest denominator - the participant/session level.
This would entail requiring that sidecar JSON and task description files be stored adjacent to the nifti file that they complement and get rid of inheritance. Also, this would involve moving the participant pheno, demo, and assessment data into the session folder. The result of this would be that ALL of the information that is necessary to analyze the dataset is available in the sub/session folder. This enables a more flexible file structure, where users can access only the data that they want.
Inheritance is the weakest part of BIDS and opens the door to a host of problems. I understand that it has the potential of considerably reducing the number of files, but comes at a large cost in complexity and inflexibility. If we do decide to maintain inheritance in the future, it would be much better to explicitly list the inheritance structure in the JSON files, rather than relying on the file structure. This will also make it much more efficient to find meta data (less time probing file systems for files that may or may not exist).
Another reason to remove inheritance is that, while it may be clear how to inherit values in a JSON file, inheriting values in other meta-data file types may be more complex and ambiguous. As raised in bids-standard/bids-specification#337, a single named TSV column requires other columns to be interpreted (i.e. onset and duration, likely event_type) and so certain rows of other columns will also have to be inherited.
Perhaps a practical way forward is to limit the meta-data file types that can participate in inheritance.
Original authors: @ccraddock