Open Lestropie opened 1 year ago
I think it relates also to
modality/
is actually the datatype/
. But also I think it is interestingly relates todatatype
s we use are not "modality agnostic" as e.g. func
is specifically "fMRI" or to say "fMRI+whateverelse-during-fMRI-scan". FTR to clarify the "terminology", in the schema those folders are not "modalities" which are a higher level concept, e.g. as mri
but "datatypes": see https://github.com/bids-standard/bids-specification/blob/master/src/schema/rules/modalities.yaml . For any modality other than mri
there is one-to-one correspondence ATM between "modality" and "datatype". I guess it was devised so to address the historical aspect that initially BIDS was solely for MRI modality.
But the point of confusion that we also have modality entity (_mod-
) and a common principle which are not that "high level modality", uff:
So the actual "thing" this issue is concerned is really some datatype
for which we do not have an entity devised yet.
So for the bids v2 we might want to clarify this a little messy situation indeed.
Just a note: an interesting aspect/PoV @effigies brought up in a road-trip discussion is that this modality
(AKA datatype
) directory for many (everything non-MRI? e.g. eeg
, meg
) corresponds to the _suffix
of the files, hence somewhat/partially consistent as it is not an entity thus does not have entity-
prefix in the folder name. Sure thing it doesn't work for MRI where we have a list of dedicated subfolders (func
, anat
etc) which do not correspond to suffixes, although in some cases could easily do (e.g. would be ok to have bold/
IMHO).
Related to the recent #54. Relates to many issues I've encountered with BEP016 https://github.com/bids-standard/bids-bep016; maybe best reference is https://github.com/bids-standard/bids-bep016/issues/32. The rejected https://github.com/bids-standard/bids-specification/pull/1280 is also somewhat relevant.
Embedded in the current BIDS structure is a very specific hierarchy of directory structure, with very specific use or non-use of one (sometimes exclusively) "entity" key-value pairs. We might summarise as something like this:
sub-<label>/
ses-<label>/
modality/
sub-<label>_ses-<label>_suffix.ext
What I've encountered in BEP016 (and I fully expect to arise in other derivatives) is that there are circumstances in which the derivatives specific to some modality aren't just an unstructured set of data / sidecar file pairs; there can be further hierarchical structure.
In contemplating the various potential structural solutions to that, which I've probably written too much about and discouraged engagement by doing so, one factor that shows itself as an annoyance quite frequently is the modality level. Unlike subject and session, it doesn't possess the key-value formatting. So for instance, the https://github.com/bids-standard/bids-specification/pull/1280 solution would look like:
sub-<label>/
ses-<label>/
modality/
model-<label>/
sub-<label>_ses-<label>_model-<label>_suffix.ext
, which is inconsistent in terms of entity key-value formatting across directories.
For complete flexibility of sub-directory structure as per #54, which would go a long way to solving the BEP016 issues, it would make far more sense if sub-directories separating data corresponding to different brain imaging modalities were to follow the entity key-value naming standard.