markers suffix for MEG only referenced in Appendix VI

[tsalo]

The _markers suffix for MEG data is present in Appendix VI and the Entity Table, but there is no definition for it anywhere, as far as I can tell. @bids-standard/raw-electrophys-meg does anyone know what this suffix refers to and can we define it in the main text?

Stems from #610:

What are MEG _markers files? They're in the schema but I don't know where they came from.

😲 did you find a spot in the spec that yields more information?

I just found this in https://bids-specification.readthedocs.io/en/latest/99-appendices/06-meg-file-formats.html#kityokogawaricoh

Seems like a badly defined suffix ... reminiscent of the part -> split situation we had a while ago, where an MEG suffix was only defined in an appendix.

Originally posted by @sappelhoff in #610 (comment)

[robertoostenveld]

Indeed a badly defined suffix, it could have been acq-marker instead.

I think this requires input from a Yokogawa/Ricoh MEG user.

[sappelhoff]

Just to improve the information state a bit:

• the markers suffix is defined in the appendix on MEG datasets, for the KIT/Yokogawa/Ricoh data format
• it's intended to capture two kinds of files: _markers.sqd and _markers.mrk, which carry information about 3D sensor positions during acquisition
• The bids-validator accepts these files, see regex in file level rules
• at least some software supports this (for example mne-bids in this unit test where kit/yokogawa/ricoh is tested)

problems:

1. the suffix is only defined in the appendix, and could use some more information
2. the suffix seems to be specific for only one data format (kit/yokogawa/ricoh), and seems to be "unnecessary" at that (could be easily replaced by an acq-<label> entity)

potential solution:

1. define the suffix in the main text of the spec, and provide more information
2. properly add the suffix to the schema (@tsalo would probably gladly help)

cc @jasmainak @hoechenberger @agramfort

also tagging @teonbrooks because I think to remember that he knows a bit more about kit than other people?

[hoechenberger]

2. the suffix [...] could be easily replaced by an acq-<label> entity

+1 on doing exactly this.

[teonbrooks]

2\. the suffix seems to be specific for only one data format (kit/yokogawa/ricoh), and seems to be "unnecessary" at that (could be easily replaced by an `acq-<label>` entity)

I also agree that acq-marker would be an adequate and aligned entity. what would we use as the suffix, just _meg?

[hoechenberger]

what would we use as the suffix, just _meg?

+1

[sappelhoff]

Removing the _markers suffix would be a backwards compatibility breaking change. The impact would probably be low ... we could assess how many KIT meg datasets are out there in BIDS format.

However the alternative that we probably should go with is to deprecate the _markers suffix, and start advertising/documenting the acq-<label> route.

[jasmainak]

Quickly read the issue but is the proposed solution compatible with multiple marker files? It reminded me of this old issue:

• naming multiple marker files for KIT MEG systems #45

[jasmainak]

From what I remember the acq entity would be used to say whether the marker was "pre" or "post"

[teonbrooks]

@jasmainak is correct, I forgot about that.

I was looking through the spec and couldn't find a full list of suffixes anywhere. is there a list of them as there are for the entities? Is there a place where we should be surfacing suffixes?

[tsalo]

@teonbrooks The primary location is the relevant "modality-specific files" page(s) where the suffix can be used, but I am also working on a schema version of the specification wherein suffixes should all be represented.

[sappelhoff]

perhaps we should then swallow the bitter pill and properly introduce the markers entity in the spec text?

[teonbrooks]

@sappelhoff, should we update the entity list?

[sappelhoff]

@sappelhoff, should we update the entity list?

yes! That'll be done automatically in #610

"markers" are added to the BIDS schema here --> https://github.com/bids-standard/bids-specification/blob/84fdf30c2c011c2928f2d78085f603772b9c82df/src/schema/datatypes/meg.yaml

and the entity table will be created automatically from the schema

EDIT: I just assumed you meant "entity table" with your "entity list" --> the actual entity list would not list markers, because it's not an entity

[teonbrooks]

sorry, my bad, I meant suffix, not entity. and cool! 🎉