[SCHEMA] Add remaining enum definitions

[sappelhoff]

• Addresses part of Leftover tasks for shared channel types #1529

specifically, I intend to add definitions for those "enums" that don't have one yet.

See @tsalo and my discussion here: #919 (comment)

• add todo comments to enums that have not yet been worked on
• address all todo comments that are deemed relevant
  • answer this questions: should we add definitions for something like this?

  type: string
  # TODO: Add definitions for these values.
  enum:
    - left
    - l
    - L
    - LEFT
    - Left

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (8dc5221) 87.83% compared to head (ff604e6) 87.97%.
Report is 7 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1640      +/-   ##
==========================================
+ Coverage   87.83%   87.97%   +0.14%     
==========================================
  Files          16       16              
  Lines        1356     1356              
==========================================
+ Hits         1191     1193       +2     
+ Misses        165      163       -2     

see 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sappelhoff]

I think we don't have to add anything for:

• units of length and time (m, nm, um, etc. and s, sec, etc.)
• abbreviations for left/right/ambidextrous and male/female/other (L, left, LEFT, etc. and m, M etc.)

What do you think @effigies @Remi-Gau @tsalo ?

EDIT: If you clone my branch (this PR), you can search the repo (src/schema) for # TODO: Add definitions for these values. to get a good overview. The definitions that I think we should leave without entries in enums.yml have the appendix: (perhaps don't specify)

[sappelhoff]

Okay, I have added all definitions that I think could potentially make sense to have.

That said, this doesn't mean that all the definitions I added are meaningful beyond what the "value" says. But that's up to add for people who work with this data -- with this PR we at least:

• have added all sensible definitions and thus the infrastructure to improve the descriptions more easily (no more digging, just one search and edit the description)
• have tracked the enums for which a definition would probably not make a lot of sense with inline comments (see [SCHEMA] Add remaining enum definitions #1640 (comment))

I'd be happy for input and for help solving the CI issue 🙂

[sappelhoff]

Thanks @effigies! what is your general take on this PR?

[effigies]

Sorry, I don't have a general take. At this point I was just trying to get it working. Please bug me to think about this again next week.

[sappelhoff]

Sorry, I don't have a general take. At this point I was just trying to get it working. Please bug me to think about this again next week.

cc @effigies

[effigies]

This seems fine as-is. I don't think we need to define meter, mm and cm and mass replace those. I think the ultimate end-point of these would be to turn this into an actual ontology, with relationships between fields and values, and we need to be careful about reinventing wheels. The more we elaborate the schema, the more we're going to need to reconsider our "lightweight" custom approach versus some existing effort.

Not sure if you're looking for anything more specific in a general take.

[sappelhoff]

Thanks @effigies that's the granularity I was expecting for the take I asked for 🙏