task entity for electrodes in eeg_face13?

[Remi-Gau]

Starting to use the bids-schema (thanks again @tsalo for this!) in bids-matlab to parse datasets.

By doing so, my code threw a warning for the electrode files that have a task entity even though they are not supposed to according to the spec.

Is that normal?

[sappelhoff]

nope, probably a shortcoming of the validator. I think it was decided that electrodes are typically not applied on a task basis (more on a session, or acq basis), thus the task entity is currently "wrong".

Seems like we'd need to fiddle with the validator regexps

[sappelhoff]

as discussed in the maintainers meeting we maybe should re-open the discussion on whether allowing/disallowing a task entity for electrodes is warranted. --> before working on a validator PR

[sappelhoff]

copying the discussion from the maintainers mattermost here, in order not to forget:

electrodes.tsv and "task" entity

I thought Chris' argument was as follows:

• if you have a session and several tasks in that session, ...
• but for one task in the session, the electrode cap was removed, ...
• then you wouldn't be able to tell from the BIDS folder+file layout, as task is disallowed.

Some situation like:

sub-01/
    ses-01/
        eeg/
            sub-01_ses-01_electrodes.tsv
            sub-01_ses-01_coordsystem.json
            sub-01_ses-01_task-nback_eeg.edf
            sub-01_ses-01_task-rest_eeg.edf  <-- electrode cap was removed
            ...     

In this example, software would think that sub-01_ses-01_task-rest_eeg.edf has the electrode positions from sub-01_ses-01_electrodes.tsv, when in fact, it doesn't.

With a task entity, this could be solved easily.

---

--> that's how far I understood the point.

I might have misunderstood (please correct me).

Having thought about this 2 minutes longer, I think this is not an issue and we don't need to allow task.

In the above case, users should just organize as such:

sub-01/
    ses-1elec/
        eeg/
            sub-01_ses-1elec_electrodes.tsv
            sub-01_ses-1elec_coordsystem.json
            sub-01_ses-1elec_task-nback_eeg.edf
            ...
    ses-1noelec/
        eeg/
            sub-01_ses-1noelec_task-rest_eeg.edf
            ...     

[robertoostenveld]

The EEG cap being removed and later replaced, makes it similar to a participant getting out of the MRI scanner and back in again. See https://bids-specification.readthedocs.io/en/stable/02-common-principles.html#definitions which mentions that. However, with the MRI scanner the images can be easily realigned, whereas with EEG not. Not only positions, but also impedances will be different. Or consider the gel that might be left in the hair after the first half, which interferes with the measurements in the 2nd half. Imagine that the 2nd half if the experiment is done with another cap. Or even with another amplifier.

All of this is technically possible to document by adding a task entity to the electrodes, but personally I would recommend that to be represented in different sessions (not necessitating task in the electrodes). That makes it more explicit.

If it were a dataset acquired with different dry electrode systems, or by taking the dry electrode cap off in between, then I would in first instance be fine with it being represented in a single session (hence necessitating task for electrodes). But task is what the subject does, whereas that might be actually the same before and after the break. The main difference in the two recordings is recording-technical, not task-wise or behavioral. So I still don't think that task is the right metadata element to describe this, and I would still go for separate sessions.

[Remi-Gau]

@robertoostenveld @sappelhoff

This kind of information should be mentioned somewhere, no? What would be the best place for that kind of "practical" information?

[sappelhoff]

I think if someone could manage to condense Roberts explanation into a few sentences, then the section in the spec directly would be a good place:

https://bids-specification.readthedocs.io/en/latest/04-modality-specific-files/03-electroencephalography.html#electrodes-description-_electrodestsv

[robertoostenveld]

I think it should go in the starter kit (or similar), and I think that much more should go there. The starter kit is the closest that we have to the user documentation, whereas the specification is more like the reference documentation. Ideally we would also have many more people contribute to the user documentation, and the process there does not have to be that formal, whereas the specification should be relatively static and well-guarded (a.o. you first have to pass your git exams, and there are N positive reviews required, etc).

[robertoostenveld]

I see this a bit similar as statutory law versus case law (or "jurisprudentie" as we call it in Dutch). See https://en.wikipedia.org/wiki/Case_law or look it up in your native language.

[Remi-Gau]

I see this a bit similar as statutory law versus case law (or "jurisprudentie" as we call it in Dutch). See https://en.wikipedia.org/wiki/Case_law or look it up in your native language.

Good analogy. I was also thinking that this is a bit too practical but was not sure to go in the specs.

[sappelhoff]

okay, consider me outvoted then - I agree with the general idea from Robert's #244 (comment)

then perhaps a starter kit entry would be more suitable

[sappelhoff]

this was closed in #289