What to call modality directory vs the modality entity?

[adam2392]

Problem

Currently in the standard, there is this notion of a modality, which I totally assumed meant eeg, meg, ieeg, anat, etc. So therefore they would be the "modality" directories that followed subject and session. For example:

sub-01/ses-01/<modality>/

However, there is also a modality entity which is primarily used in anat sub-directories to differentiate various imaging modalities. This shows up like sub-01/ses-01/anat/sub-01_ses-01_mod-T2w_defacemask.nii.gz.

Anat using modality in different ways:
https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/01-magnetic-resonance-imaging-data.html#anatomy-imaging-data

Entity table:
https://bids-specification.readthedocs.io/en/stable/99-appendices/04-entity-table.html

Expectation

It would be helpful to have the specification explicitly define what to call the directory level names vs. the filename specific modality entity. Since calling them both modality leads to a bit of confusion since there is no good 1-1 matching.

Idk what's the right answer here so would be helpful to get some thoughts and then I can PR if it's feasible :p.

Additional Info

See a problem that surfaced in mne-bids at: mne-tools/mne-bids#519 (comment)

cc @jasmainak @sappelhoff @hoechenberger @agramfort

[jasmainak]

someone with more knowledge of MRIs should probably weigh in. @effigies or @emdupre ?

[emdupre]

sub-01/ses-01/anat/sub-01_ses-01_mod-T2w.nii.gz

Is this BIDS compliant ? I wouldn't expect it to be. My read of the specification is that mod- should only be used if the suffix is defacemask. Otherwise the modality should be indicated by the suffix.

EDIT: I found that section confusing in the last release, so I had a PR a couple of weeks ago to clean it up. I'm biased, but I think the latest version of the spec is a bit easier to parse, specifically on this issue.

[jasmainak]

humm interesting ... but in that specific example above, the folder is not T2w. That is:

sub-01/ses-01/T2w/sub-01_ses-01_mod-T2w_defacemask.nii.gz

Is the modality not what you get after session level? You have "modality agnostic files" and "modality specific files" in the table of contents of the specification. Are T1w and T2w also modalities?

We're just wondering in MNE-BIDS if we can call the folder level directory (meg/eeg/ieeg/anat) "modality" but there is also a usecase where you have mod-<modality>. We'd like to stay close to BIDS terminology as much as possible

[tsalo]

The folders are "data types" and the suffixes are "modalities", although I think the way the specification sections are currently labeled somewhat muddies the distinction between "modality" and "technology" (see #571 for some discussion on this). "Data type", while confusingly named, is separately defined.

[adam2392]

Ah I see, so perhaps on our software end, we can use semantics such as data_type instead of modality, since that seems like it's going through some discussion and on specification end, perhaps there can be an extra section explicitly defining data type as the directory level data types (e.g. eeg, meg, func, anat, etc.)?

[tsalo]

pybids uses datatype (see here). It's under the bids-standard organization and has many of the same devs as the specification, so I think it's fairly close to an official name.

I plan to open an issue about defining "modality" under the Common principles soon. Unless you want to?

[adam2392]

pybids uses datatype (see here). It's under the bids-standard organization and has many of the same devs as the specification, so I think it's fairly close to an official name.

I plan to open an issue about defining "modality" under the Common principles soon. Unless you want to?

Yeah feel free to do it for modality! I think that falls more under the MRI realm, which I'm not as familiar with.

Re datatype: I am not sure if datatype is fully defined explicitly in the specification itself though. Is it? (I'm like intermediate knowledge of the stable spec :p). Is there a consensus here to add some documentation explicitly stating what datatype is defined as in the spec (if there isn't already)?

just kidding found it: https://bids-specification.readthedocs.io/en/stable/02-common-principles.html
Although it makes me wonder if it should also be explicitly defined again under "Modality-Specific Files" because it gives a name to everything like (sub, ses, space, etc.), but doesn't again remind us of the definition of the 'eeg'/'meg'/'anat'/'ieeg'/etc. directories. It seems based on what happened with MNE-BIDS that it might be useful to do so, less ppl mistake those as modality.

[hoechenberger]

@tsalo

the suffixes are "modalities"

Umm, but what about sidecar files like _channels.tsv etc., where the suffix clearly doesn't fall into any understanding of a "modality" that I've ever heard of in the neuroscience context? Is it a lack of education on my end, or do we need to be more specific? 🧐

[agramfort]

To me "data type" and "suffix" are clear BIDS concepts. Modality is not the suffix to me (see example from @hoechenberger ) not sure where this needs to be clarified in the standard but a few sentences like Depending on data modality (MRI, MEG, EEG) data are placed in subfolder that correspond to the data type: Functional MRI are of data type 'func', anatomical MRI are of data type 'anat' etc... my 2c

…

[tsalo]

Yes, @yarikoptic and I have been discussing this very issue in #571. @yarikoptic made the interesting point that he sees the related term "modality_label" as a subgroup of "suffix." To quote him:

while phrasing description of "suffix" in common principles I et al (in #152) tried to stay away from any specific semantic (such as modality) since IIRC some would not fit nicely "into" its semantic IMHO, e.g. _events, _electrodes, _phase1 etc...

Having said that I indeed most often saw _suffix as indicator of a "modality" and text in e.g. 04-modality-specific-files/01-magnetic-resonance-imaging-data.md indeed uses word "modality" to refer to those suffixes, not the conceptual data types (anat, dwi, ...) and indeed we have one off _mod- (only for _defacemask) to "absorb" modality_label but it is about "modality" since suffix in those files is modality_label

In my opinion, the next step is to define modality under Common principles, whether as a subgroup of suffix or as a synonym.

EDIT: I ended up opening #586.

[effigies]

Will #592 close this as well?

[tsalo]

I believe so. I think the original question has been answered here, but #592 answers it in the specification.