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.
:astonished: 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->splitsituation we had a while ago, where an MEG suffix was only defined in an appendix._Originally posted by @sappelhoff in https://github.com/bids-standard/bids-specification/pull/610#issuecomment-702927730_
Indeed a badly defined suffix, it could have been acq-marker instead.
I think this requires input from a Yokogawa/Ricoh MEG user.
Just to improve the information state a bit:
markers suffix is defined in the appendix on MEG datasets, for the KIT/Yokogawa/Ricoh data format_markers.sqd and _markers.mrk, which carry information about 3D sensor positions during acquisitionproblems:
acq-<label> entity)potential solution:
cc @jasmainak @hoechenberger @agramfort
also tagging @teonbrooks because I think to remember that he knows a bit more about kit than other people?
2. the suffix [...] could be easily replaced by an
acq-<label>entity
+1 on doing exactly this.
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?
what would we use as the suffix, just
_meg?
+1
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.
Quickly read the issue but is the proposed solution compatible with multiple marker files? It reminded me of this old issue: https://github.com/bids-standard/bids-specification/issues/45
From what I remember the acq entity would be used to say whether the marker was "pre" or "post"
@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?
@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.
perhaps we should then swallow the bitter pill and properly introduce the markers entity in the spec text?
@sappelhoff, should we update the entity list?
@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
sorry, my bad, I meant suffix, not entity. and cool! 馃帀
Most helpful comment
Indeed a badly defined suffix, it could have been
acq-markerinstead.I think this requires input from a Yokogawa/Ricoh MEG user.