Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SCHEMA] Refactor channel types #1126

Closed
sappelhoff opened this issue Jun 14, 2022 · 1 comment
Closed

[SCHEMA] Refactor channel types #1126

sappelhoff opened this issue Jun 14, 2022 · 1 comment
Labels
schema Issues related to the YAML schema representation of the specification. Patch version release. schema-structure Changes to the fundamental organization/structure of the YAML schema. Minor version release.

Comments

@sappelhoff
Copy link
Member

  • We have lists of coordinate systems for different modalities

  • For example: MEG, EEG

  • Coordinate systems from EEG may also be used in MEG

  • This is nicely expressed in the schema, see the $ref items:

    AnatomicalLandmarkCoordinateSystem:
    name: AnatomicalLandmarkCoordinateSystem
    description: |
    Defines the coordinate system for the anatomical landmarks.
    See [Appendix VIII](SPEC_ROOT/99-appendices/08-coordinate-systems.md)
    for a list of restricted keywords for coordinate systems.
    If `"Other"`, provide definition of the coordinate system in
    `"AnatomicalLandmarkCoordinateSystemDescription"`.
    anyOf:
    - $ref: _MEGCoordSys
    - $ref: _EEGCoordSys
    - $ref: _StandardTemplateCoordSys
    - $ref: _StandardTemplateDeprecatedCoordSys

  • The situation is similar for channel types: we have types defined in different modalities (search for type__ieeg_channels, type__eeg_channels, type__meg_channels)

  • For example types like "EEG", "RESP", or "PUPIL" -- these are the same, regardless for which modality they are used (that is, specifying PUPIL in an EEG dataset is the same as PUPIL in an MEG dataset)

  • Currently these are organized as such:

    type__eeg_channels:
    name: type
    description: |
    Type of channel; MUST use the channel types listed below.
    Note that the type MUST be in upper-case.
    type: string
    enum:
    - AUDIO
    - EEG
    - EOG
    - ECG
    - EMG
    - EYEGAZE
    - GSR
    - HEOG
    - MISC
    - PPG
    - PUPIL
    - REF
    - RESP
    - SYSCLOCK
    - TEMP
    - TRIG
    - VEOG
    type__meg_channels:
    name: type
    description: |
    Type of channel; MUST use the channel types listed below.
    Note that the type MUST be in upper-case.
    type: string
    enum:
    - MEGMAG
    - MEGGRADAXIAL
    - MEGGRADPLANAR
    - MEGREFMAG
    - MEGREFGRADAXIAL
    - MEGREFGRADPLANAR
    - MEGOTHER
    - EEG

  • Meaning we have lots of duplication

Should we just have a single type__channels metadata entry? that is shared across the spec?

Or should we keep them modality specific in "overarching variables", but then have a type__channels defined as

type__channels:
  name: ....
  description: ...
  anyOf:
  - $ref: _type__meg_channels
  - $ref: _type__eeg_channels
  - $ref: _type__ieeg_channels
  - $ref: ...
@sappelhoff sappelhoff added schema Issues related to the YAML schema representation of the specification. Patch version release. schema-structure Changes to the fundamental organization/structure of the YAML schema. Minor version release. labels Jun 14, 2022
@sappelhoff
Copy link
Member Author

closed in #919

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
schema Issues related to the YAML schema representation of the specification. Patch version release. schema-structure Changes to the fundamental organization/structure of the YAML schema. Minor version release.
Projects
None yet
Development

No branches or pull requests

1 participant