Change modality directories to entity format

[Lestropie]

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 bids-standard/bids-bep016#32.
The rejected bids-standard/bids-specification#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:

	Type	Entity key-value
sub-<label>/	Directory	ONE
ses-<label>/	Directory	ONE
modality/	Directory	NO
sub-<label>_ses-<label>_suffix.ext	File	MANY

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 bids-standard/bids-specification#1280 solution would look like:

	Type	Entity key-value
sub-<label>/	Directory	ONE
ses-<label>/	Directory	ONE
modality/	Directory	NO
model-<label>/	Directory	ONE
sub-<label>_ses-<label>_model-<label>_suffix.ext	File	MANY

, 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.

[yarikoptic]

I think it relates also to

• What to call modality directory vs the modality entity? bids-specification#584
  "confusion" which was resolved by
• [ENH] Define "modality" and clarify "data type" bids-specification#592
  which clarified that the directory modality/ is actually the datatype/ . But also I think it is interestingly relates to
• Question about microscopy data types and modalities INCF/neuroscience-data-structure#18
  since currently datatypes we use are not "modality agnostic" as e.g. func is specifically "fMRI" or to say "fMRI+whateverelse-during-fMRI-scan".

[yarikoptic]

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.

[yarikoptic]

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).