rules behind the limited number of electrodes.tsv per session should be made more explicit

[Remi-Gau]

Unless I missed it, it seems that the rules limiting the number of eletrodes.tsv per session are not explicitly stated.

For example

electrodes (positions) and coordinates (in which they are expressed) are required to remain constant in a session. If not, then the data must be represented over multiple sessions (which can be on the same day). Also, if multiple EEG systems are being used in succession on the same subject (e.g. with dry electrodes), it should be represented in multiple sessions.

Linking to the original thread at the end of this post.

I may be wrong but this feels more then a simple "how to use bids" issue as it adds an extra constraints on the definition of session for EEG and iEEG (as mentioned in the original thread).

Another reason why this may needed is that currently the validator does not enforce this rule and allows many more entities than the spec permits (https://github.com/bids-standard/bids-validator/issues/1198).

The lack of clarity on this point can otherwise lead to user confusion (see bids-standard/bids-matlab#542 (comment))

---

electrodes (positions) and coordinates (in which they are expressed) are required to remain constant in a session. If not, then the data must be represented over multiple sessions (which can be on the same day). Also, if multiple EEG systems are being used in succession on the same subject (e.g. with dry electrodes), it should be represented in multiple sessions.

Different sampling rates and/or filter settings of the amplifier can happen within a session, as (of course) multiple runs of the same task, or different tasks in different (EEG) files.

Electrode positions are (potentially noisy) measurements that can be done multiple times, hence the acq label. The coordinate system is a definition, which only needs to be specified once.

I also do not recall why there is an optional run label for electrodes. I do not see the use case for it. Looking in the draft google doc, I also don't see it there.

Originally posted by @robertoostenveld in #416 (comment)

[robertoostenveld]

A more general question could be whether entities that are not uniquely identifying are allowed to be part of the filename or not. If you consider the following

.
├── sub-01
│   └── eeg
│       ├── sub-01_task-eyesclosed_eeg.edf
│       ├── sub-01_task-eyesclosed_eeg.json
│       ├── sub-01_task-eyesopen_eeg.edf
│       ├── sub-01_task-eyesopen_eeg.json
│       └── sub-01_task-eyesopen_electrodes.tsv
└── sub-02
    └── eeg
        ├── sub-02_task-eyesopen_eeg.edf
        ├── sub-02_task-eyesopen_eeg.json
        └── sub-02_task-eyesopen_electrodes.tsv

then the relation between electrodes and EEG data is confusing for sub-01, but not confusing for sub-02. The confusion would be avoided if in both cases the task entity would not be part of the electrodes.tsv filename.

[robertoostenveld]

in this specific case where electrode positions are required to remain constant in a session (as per definition that "Session =a non-intermittent period in which the subject is wearing the EEG cap" in the google doc), the following is invalid

.
├── sub-01
│   └── eeg
│       ├── sub-01_task-eyesclosed_eeg.edf
│       ├── sub-01_task-eyesclosed_eeg.json
│       ├── sub-01_task-eyesclosed_electrodes.tsv
│       ├── sub-01_task-eyesopen_eeg.edf
│       ├── sub-01_task-eyesopen_eeg.json
│       └── sub-01_task-eyesopen_electrodes.tsv
└── sub-02
    └── eeg
        ├── sub-02_task-eyesopen_eeg.edf
        ├── sub-02_task-eyesopen_eeg.json
        └── sub-02_task-eyesopen_electrodes.tsv

If I look at the online specification, I don't find the definition of the original google doc back. In the BIDS-EEG paper it is also not mentioned. However, figure 1 in the BIDS-EEG paper does give an example of an electrodes.tsv that has the task in its name.

Given these considerations, I think that according to what has been written so far (which I am not judging here), the following would be a correct structure.

.
├── sub-01
│   └── eeg
│       ├── sub-01_task-eyesclosed_eeg.edf
│       ├── sub-01_task-eyesclosed_eeg.json
│       ├── sub-01_task-eyesopen_eeg.edf
│       ├── sub-01_task-eyesopen_eeg.json
│       └── sub-01_electrodes.tsv
└── sub-02
    └── eeg
        ├── sub-02_task-eyesopen_eeg.edf
        ├── sub-02_task-eyesopen_eeg.json
        └── sub-02_task-eyesopen_electrodes.tsv

The specification of task in the electrodes.tsv for sub-02 (who did not complete all tasks) is not required, but allowed here. Personally, I would not do it and make it consistent over subjects without the task entity.

[Remi-Gau]

Just to be clear, I am not trying to argue against the rationale, but more arguing for the rationale to be made more explicit, a bit like in the spirit of some other recent PRs that either clarify and make things more explicit:

• [ENH] Add paragraph about richness versus distinctness in filenames #1392
• [ENH] clarify guiding principles for requirement levels #1444

[robertoostenveld]

I value clarifications!

I think it will be useful to look ahead at the animal ephys and at the NIBS BEPs. They both involve "something" (electrodes and/or stimulation coils) being placed relative to/in the brain. When planning/discussing EEG we considered teh 80/20 principle and wanted to align with the most common measurements (which don't move the EEG cap in a session) and avoid spending time discussing (at that time more experimental) dry and wearable electrode caps. Hence we defined the one-electrodetsv-per-session rule to limit the scope and be able to finalize the BEP. This also aligned with iEEG recordings, using chronic/static electrode positions

With future BEPs we may want to loosen that one-electrodetsv-per-session requirement and engage in the discussion that we postponed back then.

Also for OPM MEG we will have to anticipate changes, although not in the electrodes.tsv, so perhaps not something to worry about here.

[effigies]

@Remi-Gau I think this was addressed by #1722?

[Remi-Gau]

yeah I think so: at least it is clearer to me now

if not we can reopen later or open a new issue