[Potential BUG] Task events is modality-specific?

[oesteban]

Describe your problem in detail.

Currently, task events are presented as modality-specific.

Describe what you expected.

That task events are cross-modality.

BIDS specification section

https://bids-specification.readthedocs.io/en/stable/modality-specific-files/task-events.html

[Remi-Gau]

To make sure I understand, you are saying that eventhough an events.tsv file will in most cases be found in a datatype subfolder, the rules that apply to them are the same irrespective of the datatype and that therefore it feels strange to have those in the "modality specific" section if the spec?

[oesteban]

Correct -- the thought process is what kind of modality task events are?

[Remi-Gau]

The fact that task was specific to some datatypes seems less and less true now. So it may be worth moving that up one level.

[VisLab]

I agree with @oesteban. Also I think that task event is a misnomer in that event files contain markers for things that happen during the experiment. Sometimes these are not related to the task but markers on the experimental time line for other things.

[oesteban]

@VisLab - you may be interested in #1750. In fact, BIDS has already _stim.tsv.gz files to do that (albeit, with limitations such as explicitly disallowing non-regular samplings and hence, forcing those markers to be aligned with some sampling reference).

Regarding the asynchronous events that are not task-related, we hit that issue pretty hard in BEP 020 #1128 and are about to propose a _physioevents file.

_stim could be made asynchronous by means of similar mechanisms or allowed to be asynchronous.

Anyways - we are trying to improve these aspects of the spec step-by-step and #1750 is on top of the list.

[oesteban]

Bringing the conversation from #1868.

I think there are two aspects here:

1. Moving "Tasks Events" to the modality-agnostic section. This would keep the "Task" aspect of things, however, make it generalizable beyond fMRI and the few other modalities that mention them (e.g., currently, the validator fails if it finds that "a task" was run during a DWI experiment). This would directly contribute to [ENH] Formalize presence of optional logs/ folder #1962 on the MRI side, and I think it is fairly doable "today"
2. Move "Tasks Events" to become just "Events" (and also become modality agnostic). That's I think what @yarikoptic proposed in [BUG] Should subsection "Task events" be under "Modality specific files" as opposed to "Modality agnostic files"? #1868, and would effectively implement step (1). However, I don't see this so straightforward (e.g., the metadata descriptions are fundamentally for task events and just removing "task" will leave the specs a bit uneven). Also, there could be interest in having the suffix indicate the kind of data encoded, and the reason why we are proposing _physioevents files in BEP020. I think it'd be more clear if we had suffixes like _physioevents, _taskevents, _experimentevents, etc. to get a better understanding of what they contain. I don't think having a single _events file with all these different events encoded would be a good idea.

[VisLab]

I agree with 1. above... However...

2. Move "Tasks Events" to become just "Events" (and also become modality agnostic). That's I think what @yarikoptic
   proposed in [BUG] Should subsection "Task events" be under "Modality specific files" as opposed to
   "Modality agnostic files"? #1868, and would effectively implement step (1). However, I don't see this so straightforward (e.g., the metadata descriptions are fundamentally for task events and just removing "task" will leave the specs a bit uneven). Also, there could be interest in having the suffix indicate the kind of data encoded, and the reason why we are proposing _physioevents files in BEP020. I think it'd be more clear if we had suffixes like _physioevents, _taskevents, _experimentevents, etc. to get a better understanding of what they contain. I don't think having a single _events file with all these different events encoded would be a good idea.

I have strong reservations about a "separation" proposal. In most experiments and analysis that I am familiar with, the experimental markers come out from various places and are merged into a single time line associated with the imaging and put into the _events.tsv (which is not called _taskevents.tsv BTW). In other words --- the _events.tsv already has markers for a lot of things besides items directly related to the task for many datasets. The proposal was just to re-title the subsection for clarity, not to change anything about the specification.

The proposed separation would require people to separate these into separate files. But which things go where is somewhat arbitrary and they would end up being mapped into the same time line for analysis.