I am working on BIDSifying a dataset that contains MRI images for both the brain and the spinal cord.
Currently the raw images of a subject/session are split into two subdirectories brain and spinalCord (e.g. sub-XXXX/brain) and the content in each of the two subdirectories respect BIDS standart. (e.g. anat/sub-XXXX_acq-c1c3_run-1_T2w.nii.gz). Ideally users of the dataset would like to keep the body part provenance in the filename so that it is easy to use to launch further processing (e.g. glob or parsing of a key)
You’ll have to change that so everything is in one subject folder (that is, no brain subfolder).
You can use something like acq-brain or acq-sc to differentiate the scans. Keep in mind that for apps such as fmriprep you should use a BIDS filter file to filter out spinal cord images. This should be easy to do if there is a consistent acq- labeling scheme as suggested above.
I’m late to the party, but with the recently introduced chunk in BEP microscopy (BEP031), and later adapted to MRI (see PR#1586) would probably be more appropriate than the acq field, IMHO.
An issue to note, however, is that chunk only accepts numerical index (0-9), hence we loose the human readable information about brain vs. spinal cord.
I realize I’m late to this thread, but it describes exactly the situation we face in a dataset with brain and spine scans of the same modality, and I think it points to a gap in the specification that may be worth addressing.
As I see it, there are actually two distinct use cases that are not separated clearly in the spec:
Tiling the same anatomy — for example, imaging the spinal cord in two overlapping series (upper and lower) that can be stitched together. Here chunk- is semantically appropriate: the integer encodes a spatial sequence, analogous to how it works in microscopy. This use case is well served by the current spec.
Targeting distinct anatomical regions — for example, a brain T1w and a spine T1w acquired in the same session. Here chunk-1 / chunk-2 is not informative: the numbers carry no anatomical meaning, will refer to different things across datasets, and the spec provides no standard mechanism for a lookup table. This use case is as far as I can see not well covered yet.
For the second case, the community seems to informally converge on acq-brain / acq-spine, as suggested in this thread. We use this too, but it feels like a stretching the intent of the entity: acq- is formally for differentiating acquisition parameter sets, not anatomical targets. With chunk- now part of the MRI spec, leaning on acq- feels increasingly like working around a gap rather than following the standard.
I can think of three ways to address this:
Extend chunk to allow labels — permitting for example chunk-brain / chunk-spine alongside chunk-1 / chunk-2.
Formalize acq- for anatomical region — explicitly sanction its use for this purpose in the spec. This has the advantage of legitimizing current practice, but risks muddying the existing semantics of acq-.
Extend voi- to structural MRI — this entity already exists in the MRS extension for the purpose of distinguishing acquisitions localized to different anatomical regions, with user-defined labels like voi-brain or voi-spine. It could fit nicely next to chunk: use chunk for tiling, use voi for distinct anatomical targets.
I imagine more groups are running into this and I’m curious how other people look at this. If more people thing it is worthwile to address this, I would be happy to write up an issue on the github page with a proposal.