Adding an OPTIONAL _task-<label> to structural MRI acquisitions?

[melanieganz]

Dear all,

I would like some input on the following suggestion. Can we add an OPTIONAL _task- to structural MRI acquisitions as well?

I am currently converting a dataset to be shared in BIDS and can't quite get it all to fit with the available tags for structural MRI.

In my study setup, which is about different prospective and retrospective motion correction techniques for clinical structural MRI acquisitions, I had subjects perform different types of controlled motion (STILL,NOD, SHAKE) during the structural acquisitions. Besides this I also acquire two conditions, MOCO_ON and MOCO_OFF (meaning prospective motion correction on or off; note, during propsective motion correction the acquired k-space data is changed during acquisition since the actual acquisition is changed). Finally , I can reconstruct the data using extra TRs I tag onto the acquisition or without (_RR).

This leads only for the MPRAGE (I have 5 more sequences) to names like this for the same session(!):

MOCO_OFF_STILL_T1_MPR MOCO_OFF_STILL_T1_MPR_RR MOCO_ON_STILL_T1_MPR MOCO_ON_STILL_T1_MPR_RR MOCO_OFF_NOD_T1_MPR MOCO_OFF_NOD_T1_MPR_RR MOCO_ON_NOD_T1_MPR MOCO_ON_NOD_T1_MPR_RR MOCO_OFF_SHAKE_T1_MPR MOCO_OFF_SHAKE_T1_MPR_RR MOCO_ON_SHAKE_T1_MPR MOCO_ON_SHAKE_T1_MPR_RR

Now onto the available labels (from https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/01-magnetic-resonance-imaging-data.html#anatomy-imaging-data or even https://bids-specification.readthedocs.io/en/stable/99-appendices/09-entities.html):

_acq- "This is a custom label the user MAY use to distinguish a different set of parameters used for acquiring the same modality." Now my parameters of the sequence don't change, but the actual sequence does if I consider MOCO ON/OFF a parameter, so I could stuff MOCO_ON/OFF in there.

_ce- - not applicable, contrast doesn't change

_rec- The only mentioning of motion correction is under the reconstruction _rec-. That makes sense to me in the case of retrospective motion correction, where you have the same k-space data, but reconstruct it differently aka using motion data. Hence, to me the reconstruction label does not cover that I am doing prospective motion (MOCO_ON/OFF). I'll use -acq for this. Same goes for _RR - by adding extra TRs, I do add stuff to my k-space, so it feels strange to put it under -rec, but it could maybe be used here.

_run- I could misuse run to now take care of STILL,NOD and SHAKE, but the problem is that I can only sort run numerically.

So here exactly my question comes in. Can we add an OPTIONAL _task- to structural MRI acquisitions as well?

And yes, this is probably a total violation of the 80/20 rule in terms of tasks in sturcturla MRI; my study is quite specific. But looking at the ISMRM MoCo community there's lots of studies out that could be shared and I am trying to make mine an example for that.

Let me know your thoughts!

[Remi-Gau]

Can't think of something that would speak against using it from the top of my head. But it is currently an underslept and under caffeinated head so I may be missing something obvious.

May need to see if this should be applied to all types of anatomical data.

Also adding this to the spec should probably go with an explicit example along the one you described, because it would otherwise lead to a certain range of behaviors from the reader (from eyebrow raising to utter confusion).

[CPernet]

should work

sub-xx_acq-MPRAGEMOCOOFF_task-STILL_T1w.nii.gz sub-xx_acq-MPRAGEMOCOOFF_rec-RR_task-STILL_T1w.nii.gz sub-xx_acq-MPRAGEMOCOON_task-STILL_T1w.nii.gz sub-xx_acq-MPRAGEMOCOON_rec-RR_task-STILL_T1w.nii.gz sub-xx_acq-MPRAGEMOCOOFF_task-NOD_T1w.nii.gz sub-xx_acq-MPRAGEMOCOOFF_rec-RR_task-NOD_T1w.nii.gz sub-xx_acq-MPRAGEMOCOON_task-NOD_T1w.nii.gz sub-xx_acq-MPRAGEMOCOON_rec-RR_task-NOD_T1w.nii.gz sub-xx_acq-MPRAGEMOCOOFF_task-SHAKE_T1w.nii.gz sub-xx_acq-MPRAGEMOCOOFF_rec-RR_task-SHAKE_T1w.nii.gz sub-xx_acq-MPRAGEMOCOON_task-SHAKE_T1w.nii.gz sub-xx_acq-MPRAGEMOCOON_rec-RR_task-SHAKE_T1w.nii.gz

got to see how the validator behaves?

[Remi-Gau]

By the way @melanieganz i am really tempted to take snippet of your top message to highlight the reasoning on how to use bids entities when naming files.

[melanieganz]

That's totally fine with me, @Remi-Gau!

[bendhouseart]

@melanieganz you make a good point as the alternatives to barring the use of the task label seem hacky and a bit forced. I know you're cognizant of 80/20, but task already exists in the spec and this is a very small extension of its use. I'm trying to poke holes or find reasoning against, but this seems like the most elegant solution short of some other tag or label being added.

Feels like the omission of the task label to structural is just that, unless there was a specific reason for not including it?

[melanieganz]

Also, it seesm other people on openneuro e.g. https://openneuro.org/datasets/ds002087/versions/1.0.0 in the case of dwi have used the run key wrt deliberate motion tasks during acquisition, but then defined what the runs mean. But this seems like an unnecessary confusion given the existence of the _task key.

[Remi-Gau]

@agahkarakuzu do you see some reasons why we could not add a task entity to some of the qmri Anat files?

I could not think of one but you know this better than I do.

[agahkarakuzu]

Short answer is, I agree with @bendhouseart's reasoning. If using task entity outside the context of paradigm design does not violate its definition, it could be allowed for the anat data.

The long answer primarily depends on how much is BIDS willing to accommodate conventions for MRI technical development datasets.

As @melanieganz noted, the rec entity is useful for defining what kind of reconstruction has been performed, but does not necessarily inform us about how the k-space was sampled.

As allowing task for anat falls into the MRI physicists universe, that'd be cool to do the following for the sake of completeness:

• To introduce an entity to define k-space sampling relevant information (such as _ks-). This would make it possible to capture sampling information that cannot be always captured from the rec entity. For example ks-spiral can have a multitude of _rec values.

With these, the data in question would look like:

sub-xx_acq-MPRAGE_task-STILL_ks-MOCOOFF_T1w.nii.gz
sub-xx_acq-MPRAGE_rec-RR_task-STILL_ks-MOCOOFF_T1w.nii.gz
sub-xx_acq-MPRAGE_task-STILL_ks-MOCOON_T1w.nii.gz
sub-xx_acq-MPRAGE_rec-RR_task-STILL_ks-MOCOON_T1w.nii.gz
...

Using ks + task for anat data is akin to setting the log level to debug, whereas the default is info. Question is, should we overload info-level entities, or introduce debug-level entities for those interested :)

Decisions along these lines would be useful in building a semantic bridge between ISMRM-RD and BIDS at the file-naming level.

[CPernet]

oh ks :-) we could do a PR to the MRI spec there is plenty of physics there now with ASL so adding ks wouldn't look odd.

Would that go under spatial encoding although got to be renamed spatial-encoding rather than in-plane spatial encoding to accommodate e.g. ks-spiral

[Remi-Gau]

Thanks @agahkarakuzu for the reply.

My hunch is that we have enough :+1: on this to add it in the spec.

So now...

Who wants to open a PR?

[CPernet]

the one who needs it! @melanieganz :-; ahahah

[melanieganz]

Ok, ok, will do it. :-) I will split up the task and ks parts in two though and consult with @agahkarakuzu on the ks part.

[melanieganz]

@agahkarakuzu I double checked now and if you look at the description of the _rec- it actually mentiones moco:

Similarly, the OPTIONAL rec-<label> entity can be used to distinguish different reconstruction algorithms (for example ones using motion correction).

Do we agree that I should clarify this to mean retrospective motion correction? And for the _ks- I mention prospective motion correction or spirla sampling as examples?

[TheChymera]

@bendhouseart

I assume the purpose of this study design is to determine the susceptibility of acquisition to head movement and the capability of different reconstruction parameters to account for it.

One way to look at this is to say that this is indeed an unforeseen use case, for the accommodation of which the applicability of “task” needs to be expanded. The reason we didn't have this in already, is simply that the lens through which we generally look at BIDS is primarily studying the brain, not studying the equipment — so this was a blind spot all along which we can now take care of.

Another way to look at it is that since the matter of this study is not the brain, but the acquisition, this is indeed not a task. It is equivalent to looking at the effects of some bluetooth device being next to the scanner or other interfering parameters. Therefore this is indeed a facet of the acquisition and should be put under acq-.

I think the latter interpretation is a considerably better description of what is going on here. The fact that the acquisition string is long I do not think counts as an issue, since acquisition is already an agglutinative parameter.

Another reason why I would encourage putting this information under acq- is that in principle there can be tasks for anatomical scans, just that this is not one. Example of anatomical tasks would be inspecting the effect of physiological stress on brain structure (which can be varied ON/OFF within the same session). So while I agree with the extension in principle, I don't think the example at hand leverages it correctly, and perhaps the description in the associated PR should be changed to reflect that.

[bendhouseart]

@TheChymera thanks for answering my question about this not being in from the start. I think that while one may be able to apply the acq- parameter in this case it would require a broader update of the definition of parameters w/ regards to the spec. Parameter is already doing a lot of work within the spec and using task- takes some of the load off of it. But, it sounds like you're on board with this so long as task- is better defined to account for non-scanner specific inputs/parameters/events.

I should also mention, that I will (almost) always default to adding more key-pair descriptors over just concatenating/agglutinating (had to look that one up) without them. To me at least, task- seems easier to grep/eyeball and get meaning out of then some very long string following acq-.

[bendhouseart]

My knee jerk reaction was to ask why not justgen- or misc- tag, but I think it's my better nature's desire that I advocate for using something already existing such as task-.

[TheChymera]

easier to grep/eyeball and get meaning out of then some very long string following acq-

I don't know that it's particularly hard to grep (or rather find, since it's a filename) the string under acq-, but yes, in principle you could get false positives if substrings are repeated in acq-, and it's visually clearer to have a new key... One issue with bringing up this argument is that it makes the need for moving this information under task contingent on how many things you already have under acq-. Would this issue come up if movement was the only thing varying between acquisitions? I don't think so. So this information might end up under different keys depending on what else is going on.

But, it sounds like you're on board with this

After some thought I agree that anatomical scans can be performed in conjunction with tasks, though whether a task truly impacts anatomy is a daring hypothesis. I just don't think that this is what's going on here. My concern is that this blurs the scope of task which thus far was a pretty strictly understood concept. If the movement is involuntary/extraneous, is that also supposed to be a task? Ultimately it is equivalent regarding the physical reality of the measurement...

acq- is already a fuzzy parameter, and that is not in and of itself a problem, but if we have another fuzzy parameter, that leads to a conflict of scope. Which is why I commented on the PR that I'm fully on board with adding this, but we need to delineate the distinction better. Whether or not movement happens I don't think is a good enough differentiator, neither is whether or not it's voluntary. My proposal was to draw the line at whether or not it's a modulator of biological structure or of acquisition quality...

[satra]

there is a section of bids that covers instructions given to the participant: https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/01-magnetic-resonance-imaging-data.html#fmri-task-information . do note that eyes open vs eyes closed is not encoded in the task name, but in the metadata. at least @melanieganz initial use case sounds similar to instructions.

[melanieganz]

Thanks @TheChymera for the thoughtful discussion! I see what you mean with task and I didn't think of task being restricted to evoke/influence brain acticity, but I guess that was the original intention for fMRI? Following this line of thought I agree with your intention that another label would fit better. But I am just a bit confused wrt which one.

Thanks @satra for digging this out. And yes, the instructions would be kind of the place, but again the problem is that it is hidden in the meta data.

My problem is that I have always two or even three completely identical sequences that were ran with all the same parameters, just with the participant being still, nodding or shaking his/her head. I need to indicate the difference between those images somehow in the filename. So what label should I use for it? Like mentioned above some people have used runs, but since it can only be numeric and non-descriptive that seems dangerous to do.

So what do you think, should I try and allows the task label for anat, but then reflect that it can be any kind of task and could be a task that in principle has nothing to do with brain activity but could be of a rather technical nature? Or should we advocate in cases like this to use runs? Putting it just in the .json is also problematic because people would be confused to see fMRI task information parameters in an anat .json file.

Any ideas? I will wait with changing/adapting the PR until we have sorted this out a bit more.

[melanieganz]

P.S.: To make tis more graspable here are the kind of names I currently have. _acq- is indicating which sequence (since I have several t1w sequences) and pmc status (which is basically related to if the kspace acquisition is changing, since I am using prospective motion correction) -> this is already pretty overloaded _rec- indicates if selective reacquisition was used or not -> since this to me has something to do with how I reconstruct the existing k-space data -task- is then right now the motion paradigm used and I have full motion tracking data that could go into an events.tsv

sub-01_acq-mpragepmcoff_rec-wore_task-nod_T1w.nii sub-01_acq-t1tirmpmcon_rec-wore_task-nod_T1w.nii sub-01_acq-mpragepmcoff_rec-wore_task-shake_T1w.nii sub-01_acq-t1tirmpmcon_rec-wore_task-still_T1w.nii sub-01_acq-mpragepmcoff_rec-wore_task-still_T1w.nii sub-01_acq-t1tirmpmcon_rec-wre_task-nod_T1w.nii sub-01_acq-mpragepmcoff_rec-wre_task-nod_T1w.nii sub-01_acq-t2starpmcoff_rec-wore_task-still_T2starw.nii sub-01_acq-mpragepmcoff_rec-wre_task-shake_T1w.nii sub-01_acq-t2starpmcoff_rec-wre_task-nod_T2starw.nii sub-01_acq-mpragepmcon_rec-wore_task-nod_T1w.nii sub-01_acq-t2starpmcon_rec-wore_task-still_T2starw.nii sub-01_acq-mpragepmcon_rec-wore_task-shake_T1w.nii sub-01_acq-t2starpmcon_rec-wre_task-nod_T2starw.nii sub-01_acq-mpragepmcon_rec-wore_task-still_T1w.nii sub-01_acq-t2tsepmcoff_rec-wore_task-nod_T2w.nii sub-01_acq-mpragepmcon_rec-wre_task-nod_T1w.nii sub-01_acq-t2tsepmcoff_rec-wore_task-still_T2w.nii sub-01_acq-mpragepmcon_rec-wre_task-shake_T1w.nii sub-01_acq-t2tsepmcoff_rec-wre_task-nod_T2w.nii sub-01_acq-t1tirmpmcoff_rec-wore_task-nod_T1w.nii sub-01_acq-t2tsepmcon_rec-wore_task-nod_T2w.nii sub-01_acq-t1tirmpmcoff_rec-wore_task-still_T1w.nii sub-01_acq-t2tsepmcon_rec-wore_task-still_T2w.nii sub-01_acq-t1tirmpmcoff_rec-wre_task-nod_T1w.nii sub-01_acq-t2tsepmcon_rec-wre_task-nod_T2w.nii

[Remi-Gau]

sub-01_acq-mpragepmcoff_rec-wore_task-nod_T1w.nii sub-01_acq-t1tirmpmcon_rec-wore_task-nod_T1w.nii sub-01_acq-mpragepmcoff_rec-wore_task-shake_T1w.nii sub-01_acq-t1tirmpmcon_rec-wore_task-still_T1w.nii sub-01_acq-mpragepmcoff_rec-wore_task-still_T1w.nii sub-01_acq-t1tirmpmcon_rec-wre_task-nod_T1w.nii sub-01_acq-mpragepmcoff_rec-wre_task-nod_T1w.nii sub-01_acq-t2starpmcoff_rec-wore_task-still_T2starw.nii sub-01_acq-mpragepmcoff_rec-wre_task-shake_T1w.nii sub-01_acq-t2starpmcoff_rec-wre_task-nod_T2starw.nii sub-01_acq-mpragepmcon_rec-wore_task-nod_T1w.nii sub-01_acq-t2starpmcon_rec-wore_task-still_T2starw.nii sub-01_acq-mpragepmcon_rec-wore_task-shake_T1w.nii sub-01_acq-t2starpmcon_rec-wre_task-nod_T2starw.nii sub-01_acq-mpragepmcon_rec-wore_task-still_T1w.nii sub-01_acq-t2tsepmcoff_rec-wore_task-nod_T2w.nii sub-01_acq-mpragepmcon_rec-wre_task-nod_T1w.nii sub-01_acq-t2tsepmcoff_rec-wore_task-still_T2w.nii sub-01_acq-mpragepmcon_rec-wre_task-shake_T1w.nii sub-01_acq-t2tsepmcoff_rec-wre_task-nod_T2w.nii sub-01_acq-t1tirmpmcoff_rec-wore_task-nod_T1w.nii sub-01_acq-t2tsepmcon_rec-wore_task-nod_T2w.nii sub-01_acq-t1tirmpmcoff_rec-wore_task-still_T1w.nii sub-01_acq-t2tsepmcon_rec-wore_task-still_T2w.nii sub-01_acq-t1tirmpmcoff_rec-wre_task-nod_T1w.nii sub-01_acq-t2tsepmcon_rec-wre_task-nod_T2w.nii

FYI @melanieganz

you may want to check the entity order for those filenames :-p

task will come before acq and rec

https://github.com/bids-standard/bids-specification/blob/master/src/schema/rules/entities.yaml

[Remi-Gau]

Couple of remarks of why I think the example suggested here is in my opinion a perfectly valid example of a use case for a task entity and NOT for acq.

variations in acquisition quality (be they extraneous sources of noise or just head movement) are specifics of acquisition and not tasks in the context of a biological response My proposal was to draw the line at whether or not it's a modulator of biological structure or of acquisition quality

I think that the presence or absence of a putative biological effect should not be a determining factor in the vast majority of cases when it comes to the thought process around file naming.

I for one would be perfectly fine if the authors of this study wanted to name their file:

sub-deadSalmon_task-watchingMovie_bold.nii

More generally, file naming should probably strive to be agnostic regarding the actual goal of the study: whether we are studying the equipment or some specific activations related to some behavior or whether there is any activity at all.

Imagine that the example proposed here was for regular fMRI: would we argue to make the task entity optional because we are not interested in the brain activity but in the equipment and that therefore the label that would usually go under task should now go under acq? And by the same logic we should probably make the task entity optional for all modalities?

Also if this piece of information went in different places depending on the hypothesis of the original researcher who created the dataset, this could potentially affect dataset findability as you would now need to know the intention of the data curator to maximize your chances to find a dataset that matches your needs.

I don't know that it's particularly hard to grep (or rather find, since it's a filename) the string under acq-, but yes, in principle you could get false positives if substrings are repeated in acq-, and it's visually clearer to have a new key...

Yes let's remember that for a lot of users (the majority IMHO) the distinction between find or grep will be lost on them because they will use a GUI and a file browser. So having the entity-label is likely to be helpful and to be used that way.

Also more helpful when browsing / working several datasets who have this common task feature. Imagine a mega-analysis that wants to see what T1w is associated with more artifacts across several datasets and that returns files like this

sub-01_task-nod_acq-pmcoff_rec-wore_T1w.nii
sub-02_task-rest_T1w.nii 
sub-12_T1w.nii 
sub-04_task-rest_acq-TapeON_T1w.nii 
sub-03_task-listeningToClassicalMusic_acq-highRes_T1w.nii 
sub-05_task-headBangingToHeavyMetal_T1w.nii 
sub-06_task-watchingDocumentary_acq-1pt5_T1w.nii 
sub-06_task-watchingJumpScareMovies_T1w.nii 

One issue with bringing up this argument is that it makes the need for moving this information under task contingent on how many things you already have under acq-. Would this issue come up if movement was the only thing varying between acquisitions? I don't think so.

Actually yes I would still argue to have a task entity even if there was no acq in question in this example.

As long as some instructions have been given to the subject to do something (or not do anything), I think this is enough to use the task entity.

A set of structured activities performed by the participant. Tasks are usually accompanied by stimuli and responses, and can greatly vary in complexity. For the purpose of this specification we consider the so-called "resting state" a task.

My concern is that this blurs the scope of task which thus far was a pretty strictly understood concept. If the movement is involuntary/extraneous, is that also supposed to be a task? Ultimately it is equivalent regarding the physical reality of the measurement...\n\nacq- is already a fuzzy parameter, and that is not in and of itself a problem, but if we have another fuzzy parameter.

Actually I think that the task definition of task is quite fuzzy too.

Its second part says:

Therefore, even if during one acquisition the subject performed multiple conceptually different behaviors (with different sets of instructions) they will be considered one (combined) task.

So in principle we could have several "tasks" under the same label because they are all performed during the same acquisition.

[melanieganz]

Dear all, I agree with @Remi-Gau's reasoning, that's also why I had proposed the _task label in the first place.

So are there any further objections before includign _task- as a general label, irrespective of it's intention by the user in terms of evoking brain acticity, for anat?

[satra]

before this is added, perhaps we can consider a couple of things that have so far been used in bids. there are two pieces, i think:

1. the addition of the task label - it does seem that addition of the label would be a useful thing, broadly speaking.
2. the notion of variants of a key (fuzz-factor in @Remi-Gau comment above) - this is the place where there are a few approaches used: sequences, indexes, and strings/labels. to be consistent, wherever there is extended multiplicity or variation of labels, sequences and indexes are used rather than strings/labels.

the multiplicity point comes out in both @melanieganz and @Remi-Gau examples above, that task now could become one of those areas where it's just another string label with anything included without structure. the original reason i brought up that notion of instructions is that at least for resting state scans eyes-open and eyes-closed was discussed and then put in instructions rather than in the label. the filename instead uses run1, run2, etc.,. this has always been a tension in bids, what to include for search in a filename and what to index. in the naturalistic imaging datasets in openneuro, the movie name is used for task, with no direct indications of the task. thus the use of task has already diversified a lot.

most tools reading/manipulating/using bids datasets index both filenames and json metadata. therefore before adding a potential avenue for a crazy string to the filename, we could consider the implications.

in many studies participants watch videos or listen to music or rest/sleep during anatomical acquisitions (diffusion, fieldmaps, various T*scans). it sounded for a moment that the intent of task here could be a lab notebook that encoded this per participant, and this could be different from a task being asked to be done by the experimenter, which i think is what @melanieganz started with. given the foray of bids into animal studies, the notion of task could become more complex. is anesthesia a manipulation of the task or an acquisition parameter?

as you consider a change, thus it may be helpful to clarify:

• what is a task? instructions, stimuli, self-choice ?
• what is a task value? i.e. how is it encoded: string vs index
• are there multiple parameters to such a task? where should they be encoded ? in the name?
• what guidance and availability of validation exists or could exist ?

[Remi-Gau]

@satra are you asking those questions specifically for task in anat or are they broader ?

is anesthesia a manipulation of the task or an acquisition parameter?

as you consider a change, thus it may be helpful to clarify:

* what is a `task`? instructions, stimuli, self-choice ?

the original reason i brought up that notion of instructions is that at least for resting state scans eyes-open and eyes-closed was discussed and then put in instructions rather than in the label. the filename instead uses run1, run2, etc.,

hence why I am asking to add Instructions as metadata in the PR, because it is one of metadata that is always associated with task anyway.

* what is a `task` value? i.e. how is it encoded: string vs index

Task entity use labels:

https://github.com/bids-standard/bids-specification/blob/c24835c4a865043ba1b6a38af52b717c0c742a2b/src/schema/objects/entities.yaml#L357

https://github.com/bids-standard/bids-specification/blob/c24835c4a865043ba1b6a38af52b717c0c742a2b/src/schema/objects/formats.yaml#L10

* are there multiple parameters to such a `task`? where should they be encoded ? in the name?
* what guidance and availability of validation exists or could exist ?

I am not opposed to having some sort of extra specification or validation for tasks

Especially if it can avoid task labels to get too long: (see this bids-example)

But I think this is beyond the scope of this issue and its associated PR, no?

[satra]

@Remi-Gau - if task is being extended, i don't mind the scope limited to anat for now, but i suspect at least @melanieganz use case could apply to any modality almost. what is the impact of head motion in imaging broadly speaking. hence considering that use case, it may be worthwhile to consider whether task gets added more broadly.

but also according to the current definition of task, movie tasks should have just been called movie, with instructions indicating what movie, but that i don't think has been followed in datasets on openneuro. therefore clarifying the definition of a task may be in the scope of the PR.

[melanieganz]

Dear all, in case you weren't aware of it, @Remi-Gau made some updates previously to the PR and now I updated it further, so please check it out to see if the task description as well as meta data make sense to you the way we have added it.

[Remi-Gau]

closed by #1185