we should probably restrict the kinds of "labels" that can be passed to entity: *_space-<label>

[sappelhoff]

We should probably restrict the kinds of "labels" that can be passed to entity: *_space-<label>

Currently, any string can be passed ... this passes the validator, because the validator does not cover this case currently (but may do so in the future).

came up in #677 (comment)

see bids-validator issue: https://github.com/bids-standard/bids-validator/issues/743
see bids spec clarification PR: https://github.com/bids-standard/bids-specification/pull/734/files

note that although I crossreference to a clarification PR in the BIDS spec, the spec always contained the sentence that the label for the *_space-<label> should be taken from a list of permissible keywords.

[sappelhoff]

Our CI is now failing because of extended coverage in the validator https://github.com/bids-standard/bids-validator/pull/1190

https://github.com/mne-tools/mne-bids/runs/1977304655?check_suite_focus=true

[hoechenberger]

So … which space should be added in the concrete (failing) example?
@adam2392 Can you have a look at this?

[adam2392]

I think the issue is that now anything with coordframe == 'mri' in mne-python -> "Other" and one must pass *CoordinateSystemDescription and should pass IntendedFor.

@sappelhoff can you help clarify what the below should be?

For iEEG mne-python -> BIDS:

fs_tal -> ? no idea
mni_tal -> fsaverage?
mri_voxel -> error, needs to convert to mm
ras -> ? no idea
head -> EEG Captrak (or error if it's ieeg)

[hoechenberger]

and one must pass coordinatesystemdescription

HELP, is this supposed to be a keyword argument?? It makes my eyes bleed trying to read this monstrosity 😱 Can we come up with something considerably more concise? :)

[sappelhoff]

Yes, "Other" if the Coordinate System is not "known" in BIDS.

Of course, if it is a well known coordinate system, then it can be added to BIDS without a log of hassle.

However, there is a huge amount of coordinate systems supported, see: https://bids-specification.readthedocs.io/en/latest/99-appendices/08-coordinate-systems.html#standard-template-identifiers

And I suspect that for some of these, the issue just boils down to not knowing the mapping.

fs_tal -> ? no idea

I don't know what that is either ... so probably "Other", and put some meaningful thing in "*CoordsystemDescription"

mni_tal -> fsaverage?

that'd be great if you could find out ... because fsaverage would be supported.

mri_voxel -> error, needs to convert to mm

and if we convert to mm (which should be straight forward), then what would the coord system be from the BIDS list?

ras -> ? no idea

ras is no coordinate system, it just tells you about the direction of the axes, but nothing about the origin of the coordinate system (and nothing about the units, which is a bit less important, but still).

head -> EEG Captrak (or error if it's ieeg)

We could make CapTrak permissible for iEEG as well, ... IF any ieeg people actually use this kind of coordinate system.

[sappelhoff]

HELP, is this supposed to be a keyword argument?? It makes my eyes bleed trying to read this monstrosity scream Can we come up with something considerably more concise? :)

it's actually EEGCoordinateSystemDescription, and may I introduce you to my friend DigitizedHeadPointsCoordinateSystemDescription <3 (not a joke 😢 )

[hoechenberger]

it's actually EEGCoordinateSystemDescription, and may I introduce you to my friend DigitizedHeadPointsCoordinateSystemDescription <3 (not a joke 😢 )

At least this is CamelCased SoItsNotAllThatBadIGuessButInTheEndItsReallyJustAMatterOfTasteRight?

But seriously, if we do decide to use these names, we should at least turn them into snake_case and not simply lowercase them :)

[adam2392]

@hoechenberger apologies. Typing this out on GitHub mobile app heh :p

[sappelhoff]

crossref to mne discoure group: https://mne.discourse.group/t/quick-clarification-on-mne-coordinate-systems-mni-tal-vs-fs-tal/2752