Make "datatype" identical to "modality": in other words use _suffix of the "data modality" as a datatype/ folder

[yarikoptic]

An idea was discussed with @effigies on a recent road trip. ATM it is already somewhat the case for all modalities & data types besides primarily MRI which was born first and acquired all those anat, func, dwi, etc to group files of "similar" modalities into one common datatype. For new modalities which were added later

Here is a full list of suffixes across all files

❯ for r in rules/files/*/*.yaml; do echo $r; yq -r '.[].suffixes' $r | sort | uniq | grep -v -e '\[' -e ']' -e '^null'; done
rules/files/common/core.yaml
rules/files/common/tables.yaml
  "scans"
  "sessions"
rules/files/deriv/imaging.yaml
  "dseg"
  "mask"
  "probseg"
rules/files/deriv/preprocessed_data.yaml
rules/files/deriv/tables.yaml
  "descriptions"
rules/files/raw/anat.yaml
  "angio",
  "Chimap",
  "defacemask"
  "FLAIR",
  "FLASH",
  "inplaneT1",
  "inplaneT2",
  "IRT1"
  "M0map"
  "MEGRE"
  "MESE",
  "MP2RAGE"
  "MPM",
  "MTR"
  "MTRmap",
  "MTS"
  "MTsat",
  "MTVmap",
  "MWFmap",
  "PD"
  "PDmap",
  "PDT2",
  "PDw",
  "R1map",
  "R2map",
  "R2starmap",
  "S0map",
  "T1map",
  "T1rho",
  "T1w",
  "T2map",
  "T2star",
  "T2starmap",
  "T2starw",
  "T2w",
  "UNIT1",
  "VFA"
rules/files/raw/beh.yaml
  "beh"
rules/files/raw/channels.yaml
  "channels"
  "coordsystem"
  "electrodes"
  "optodes"
rules/files/raw/dwi.yaml
  "dwi"
  "sbref"
rules/files/raw/eeg.yaml
  "eeg"
rules/files/raw/fmap.yaml
  "epi",
  "fieldmap"
  "m0scan"
  "magnitude",
  "magnitude1",
  "magnitude2",
  "phase1",
  "phase2",
  "phasediff",
  "RB1COR"
  "RB1map"
  "TB1AFI",
  "TB1DAM"
  "TB1EPI"
  "TB1map",
  "TB1RFM",
  "TB1SRGE"
  "TB1TFL",
rules/files/raw/func.yaml
  "bold",
  "cbv",
  "phase"
  "sbref"
rules/files/raw/ieeg.yaml
  "ieeg"
rules/files/raw/meg.yaml
  "headshape"
  "markers"
  "meg"
rules/files/raw/micr.yaml
  "2PE",
  "BF",
  "CARS",
  "CONF",
  "DF",
  "DIC",
  "FLUO",
  "hipCT"
  "MPE",
  "NLO",
  "OCT",
  "PC",
  "PLI",
  "SEM",
  "SPIM",
  "SR",
  "TEM",
  "uCT",
rules/files/raw/motion.yaml
  "motion"
rules/files/raw/nirs.yaml
  "nirs"
rules/files/raw/perf.yaml
  "asl",
  "aslcontext"
  "asllabeling"
  "m0scan"
rules/files/raw/pet.yaml
  "blood"
  "pet"
rules/files/raw/photo.yaml
  "photo"
rules/files/raw/task.yaml
  "events"
  "physio",
  "stim"

As you can see from above, anat, fmap and micr are the datatypes which are heavy on different suffixes. Some "dataypes" are not really independent datatypes and list suffixes reused in others, e.g. channels lists those used in nirs, ieeg etc. which is declared in their records:

channels:
  suffixes:
    - channels
  extensions:
    - .json
    - .tsv
  datatypes:
    - eeg
    - ieeg
    - nirs
...

So the "raw" idea was to use "data modality" suffix as the folder to group if there is a desire to group files of similar kind, instead of "datatype" and thus in part dissolve "datatype" as a concept.

Where disambiguation is necessary, e.g. separate _events corresponding to different parallel acquisitions in a multimodal experiment (although probably could be a single _events) -- could be using _mod to disambiguate (thus relates to #70).

I see this as an alternative to

• Change modality directories to entity format #55

affecting

• Make it possible to specify folders layout to be other than sub-{label}/[ses-{label}/] #54 as we would need to provision to have a "suffix" not only "entity"s to be potentially used as a directory

and somewhat of an implementation of or relates to

• One directory per modality #28
• Treat associated modalities as independent #45

Complexity: figuring out associated other suffixes/modalities, although I guess not anyhow different from current situation.

[effigies]

In this case it might also be worth formalizing a latent concept in BIDS of "data file", "metadata file" and "associated file". Examples:

dataset/
  sub-01/
    anat/
      sub-01_T1w.nii  # data file
    func/
      sub-01_task-nback_bold.nii  # data file
      sub-01_task-nback_bold.json  # metadata file
    dwi/
      sub-01_dwi.nii  # data file
      sub-01_dwi.bval  # associated file
      sub-01_dwi.bvec  # associated file
    eeg/
      sub-01_coordsystem.json  # associated file
      sub-01_channels.tsv  # associated file
      sub-01_electrodes.tsv  # associated file
      sub-01_task-nback_eeg.fif  # data file
      sub-01_task-nback_eeg.json  # metadata file
  T1w.json  # metadata file
  task-nback_events.tsv  # associated file
  task-nback_events.json  # metadata file

For data files, suffix and datatype would match. For associated and metadata files, they belong alongside (or above) the data files they are associated to.

[yarikoptic]

FWIW, I initiated BIDS 3.0 status column in our BIDS 2.0 project where I think we could move some of the issues we decide to not address in BIDS 2.0 to keep it more tightly scoped. I think this one, along with anything relating to datatype and suffix might be a good candidate for that.