Allow composition of a BIDS dataset (dataset level) from smaller (subj or subj/ses) level

[yarikoptic]

Main goal/use-case: What if we allowed e.g. sub-X[/ses-Y] to be a BIDS dataset on its own!

Use cases

• https://github.com/AllenNeuralDynamics (TODO: ref the issue after failed)
• BIDS apps operation/parallelization across subj/sess -- now requires (eg. for fmriprep) some obnoxious (IMHO) "filtering" way or some tech-specific (git/datalad) way to create "slim down" version of dataset.
  • see references below for more similar use-cases

Analogous developments / already present in BIDS conventions which are generally in line with this:

• https://bids.neuroimaging.io/bep035 (MEGA - Modular extensions for individual participant data mega-analyses) is pretty much a composition of otherwise separate BIDS datasets into higher level at study-/ entity.
• derivatives/{tool}-{version} is also composition of BIDS datasets
• sourcedata/raw (and others) could also contain BIDS datasets
• Add DatasetType="project" and rework existing "layout" example into a proper BIDS dataset bids-specification#1861

Complications/approaches to consider:

• "inheritance principle": (meta)data on above levels might be missing at lower. Could be verified using validator
  • pretty much relates to e.g. participants.tsv (and any other metadata) now needing to be replicated (only relevant subject) from higher levels to lower ones.
  • Need to figure out referencing/reuse of external resources which are typically located on top and reused across subjects (such as stimuli/). Might want to be considered while describing nested subdataset layout in the scope of Make it possible to specify folders layout to be other than sub-{label}/[ses-{label}/] #54
    • may be allow for "explicitly" referencing such resources from a common location (top level BIDS dataset)... todo: review current approach to bids-uri
    • dedicated tooling could help to fill in/populate/sync desired references in subdatasets from the top level one.
  • Replace "inheritance" with "summarization" principle #65 could help to reduce confusion by demanding duplicated metadata being consistent

Other developments/use-cases/approaches this proposal aligns with:

• aligns well with Make it possible to specify folders layout to be other than sub-{label}/[ses-{label}/] #54 which then would allow for the "flat" (no folders) within that dataset -- its dataset_description.json would just say that.

• aligns with the work of @neuromechanist @dorahermes @VisLab on extending formalization of stimuli directory. If that directory starts to follow BIDS principle/organization itself, e.g. following suggested by me stimuli BEP bids-specification#751 (stimuli BEP) but without hierarchy (#TODO issue on alternative hierarchies) then we make it all consistent.

• BEP042 surface electromyography (HDsEMG/EMG) bids-specification#1371 (comment)

• similarish approach is taken by a2cps (attn @patrick....) on converting each subj session into independent bids dataset for processing and then "Collating" them together for the release.

• brainlife.io composes a single "subject/session" BIDS dataset from its internal data types to provide for processing for a BIDS-App which expects a bids-dataset. see bl2bids script . To a degree it also suggests that ability to get a single subject/session is great for scaleable compute.

some notes on edits

edit: previously had "study" in the title but IMHO it is misleading, replaced with "dataset level"