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
"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 #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.
65 could help to reduce confusion by demanding duplicated metadata being consistent
Other developments/use-cases/approaches this proposal aligns with:
aligns well with #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 https://github.com/bids-standard/bids-specification/issues/751 (stimuli BEP) but without hierarchy (#TODO issue on alternative hierarchies) then we make it all consistent.
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"
Main goal/use-case: What if we allowed e.g.
sub-X[/ses-Y]to be a BIDS dataset on its own!Use cases
Analogous developments / already present in BIDS conventions which are generally in line with this:
study-/entity.derivatives/{tool}-{version}is also composition of BIDS datasetssourcedata/raw(and others) could also contain BIDS datasetsComplications/approaches to consider:
participants.tsv(and any other metadata) now needing to be replicated (only relevant subject) from higher levels to lower ones.stimuli/). Might want to be considered while describing nested subdataset layout in the scope of #5465 could help to reduce confusion by demanding duplicated metadata being consistent
Other developments/use-cases/approaches this proposal aligns with:
aligns well with #54 which then would allow for the "flat" (no folders) within that dataset -- its
dataset_description.jsonwould 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 https://github.com/bids-standard/bids-specification/issues/751 (stimuli BEP) but without hierarchy (#TODO issue on alternative hierarchies) then we make it all consistent.
https://github.com/bids-standard/bids-specification/issues/1371#issuecomment-2051859738
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"