Replacing "task" with "trial"

[tsalo]

https://groups.google.com/forum/#!topic/bids-discussion/mNdO81h28eg

I am looking to implement the BIDS specification for the small rodent fMRI pipelines which me and a number of colleagues use ( https://github.com/IBT-FMI/SAMRI ).

Generally, the specification seems ok for animal data as well, with one big exception: It is highly uncommon for rodents to perform tasks during fMRI. So the task nomenclature would be highly curious and potentially misleading. Would it be possible to update the term to something more generic and species-agnostic in a future release? e.g. "trial". We are currently using "trial" in our pipeline to denote what BIDS is referring to as "task".

The name switch to "trial" would cause no ambiguity other than with the proposed "trial_type" column for the events files:

Another optional column - “trial_type“ - represents primary categorisation of each trial to identify them as instances of the experimental conditions.

If this is a concern, I would propose to update the column name to "condition_type" - which actually makes more sense, and is more accurately descriptive (as seen even in the sentence above, quoted from BIDS-1.0.1).

Original authors: @TheChymera

[tsalo]

Robert Welsh wrote:

Generally, the specification seems ok for animal data as well, with one big exception: It is highly uncommon for rodents to perform tasks during fMRI. So the task nomenclature would be highly curious and potentially misleading. Would it be possible to update the term to something more generic and species-agnostic in a future release? e.g. "trial". We are currently using "trial" in our pipeline to denote what BIDS is referring to as "task".

then if the animal is not doing a task, isn't that the analog to resting state, and thus still consistent with it being labeled with they key of "task" and the value could be "rest", "none", "nothing", etc.

And given that this would cause confusion with "trial_type", seems that should stick with "task" as the key.

Or should I even suggest a new solution. Each experiment could have a dictionary in a json at the top level defining the keys, and for this situation that would have an entry as:

"task" : "task"

for human, and for animal studies could be

"task" : "trial"

and then the APPS would use this dictionary on how to look for information in file names etc.

[TheChymera]

Or should I even suggest a new solution. Each experiment could have a dictionary in a json at the top level defining the keys, and for this situation that would have an entry as: "task" : "task" for human, and for animal studies could be "task" : "trial"

This, I would say, is by far the most problematic resolution, and the one most likely to cause confusion and overhead in coding.

Again, we have (initially) begrudgingly adopted the “task” nomenclature, and the number of raised eyebrows has remained minimal. Further, as we do more and more awake-animal fMRI, I believe it becomes more and more plausible to use the task nomenclature. Differentiating a task from e.g. an optogenetic stimulation protocol at this point I believe is needlessly complicating the issue, since the two are never handled as independent manipulations, and thus far only show up as part of neurofeedback experiments. Therefore, I would propose shelving this issue.