EEG/iEEG suffixes are not listed in the Entities appendix

[chrisgorgo]

https://github.com/bids-standard/bids-specification/blob/master/src/99-appendices/04-entity-table.md

[sappelhoff]

the entity entries (REQUIRED vs OPTIONAL) should be the same as they are for MEG, so we could expand the MEG columns to say something like

• [meg, eeg, ieeg]<br>(channels)
• and [meg, eeg, ieeg]<br>(photo coordsystem headshape)

potentially differing entities such as the space (discussed here) are not yet listed in this appendix.

for eeg and ieeg alone we would then need to add only a column for electrodes files:

• [eeg, ieeg]<br>(electrodes)

Am I missing something? cc @robertoostenveld @choldgraf

[choldgraf]

+1 from me

[robertoostenveld]

I am not sure whether the two columns work: I think that the table should only contain data (i.e. channel-time-series data) and tsv files, and no json files.

coordsystem is a json (sidecar file), not a data file. It would not have key-value pairs in the file name that the corresponding data (electrodes.tsv, or MEG sensor information stored in the MEG data itself) would not have.

photo contains data, and headshape also contains data (i.e. both are experimentally measured/determined). The same goes for electrodes. But photo and electrodes do not have the same key-value pairs in their file names. E.g. photo is not (cannot be) expressed in different coordinate systems, so the space-xxx pair would not apply, whereas it could apply for headshape and electrodes.

[robertoostenveld]

Although I don't know the solution at this moment, I propose to make a table (e.g. google sheet) with initially all types of files in separate columns, and the same rows as here, then start adding the REQUIRED/OPTIONAL, and then check which columns end up the same and then possibly collapse them again. Or even keep them separate: this will make the table wide, but ensures that each file type can be found.

Let me just make a quick start: see the table here.

[sappelhoff]

Thanks for getting started on the table @robertoostenveld, this is much cleaner compared to what I proposed. I made a few comments and will add some work later.

As an additional enhancement it might be good if we turn each row of the first column into links, so that people can directly jump to the description of e.g., proc or ce

[robertoostenveld]

... it might be good if we turn each row of the first column into links, so that people can directly jump to the description of e.g., proc or ce

That would indeed be nice. I find myself spending a lot of time searching for these details. It would require an (invisible) anchor to be added to the text sections. At the end of this page there are some suggestions for anchors in text (as opposed to headings, where they are automatically made)

[sappelhoff]

I was actually only thinking about linking to the nearest heading, but the anchor idea is much better. Let's implement that once we update the entity table with our draft from your google doc