[SCHEMA] Apply schema rules to entity values

[tsalo]

Closes #809.

The goal of this PR is to move toward applying the rules that govern metadata values (in #774) to entity values as well. Those rules support a wide range of possible values and restrictions, but the most important one right now is type: string combined with enum, which lets us list specific acceptable values for the part and mt entities.

Changes proposed:

• Add type: string to all entity definitions in the schema.
• Replace format: label with enum: <list> for the part and mt entities.
• Add an "Allowed values" subsection to entity sections in the Entities appendix for those entities with restricted values.
• Default to format = label when format is not defined in entity schema definitions (just to work around the new enums).

Pending questions:

1. Should I use type: integer for any of the index-format entities? I kept type: string because of the leading zeros issue, although I'm not sure if that applies to all entities or just run.
   • Answered. They should be strings but we'll ultimately have an index-specific format to validate against.

[tsalo]

I'm thinking it might also be a good idea to create a new formats.yaml that defines the different formats used in the schema. Something like:

label:
    description: |
        Freeform labels without special characters.
    pattern: ^[0-9a-zA-Z]+$
index:
    description: |
        Non-negative, non-zero integers, optionally prefixed with leading zeros for sortability.
    pattern: ^[0-9]+$
unit:
    description: |
        A unit.
    pattern: ^[0-9a-zA-Z]+$

Unfortunately, I don't actually know how most of those patterns would look. Units, for example, can be freeform text if necessary, but optimally they should be valid combinations of the values in the Units appendix. Plus we have relative paths of multiple flavors, along with URIs. I think uri, at least, is offloaded to JSON Schema in the validator.

[sappelhoff]

Should I use type: integer for any of the index-format entities? I kept type: string because of the leading zeros issue, although I'm not sure if that applies to all entities or just run.

I think the leading zeros is recommended for each index-format entity ... to make sorting more reasonable: That's nothing run-specific. Perhaps we can say it must be a string of digits? So that a conversion to "int" of the string does not result in a ValueError, as in this Python example:

int("0001")  # 1
float("0001")  # 1.0
float("0001a")  # ValueError, could not convert string to float: '0001a'

[tsalo]

Sounds good. I'll leave it as string then.

EDIT: With the potential for an index-specific format, of course.

[effigies]

LGTM.

[sappelhoff]

LGTM

For future reviewers, you can look at:

• https://bids-specification--792.org.readthedocs.build/en/792/99-appendices/09-entities.html#mt
• https://bids-specification.readthedocs.io/en/stable/99-appendices/09-entities.html#mt

[tsalo]

Thanks! The second approval triggers the five-day waiting period and I'll merge next Thursday if no one raises any concerns.

Regarding formats.yaml... I think I'll open a new issue about it rather than try to shoehorn it in here.

[sappelhoff]

I think you can merge starting from today, as it's been 5 days :-)