Add "titles" to permissible values.

[gouttegd]

• [ ] docs/ have been added/updated if necessary
• make test has been run locally
• [ ] tests have been added/updated (if applicable)
• [ ] CHANGELOG.md has been updated.

If you are proposing a change to the SSSOM metadata model, you must

• [ ] provide a full, working and valid example in examples/
• [ ] provide a link to the related GitHub issue in the see_also field of the linkml model
• [ ] provide a link to a valid example in the see_also field of the linkml model
• [ ] update the "Model changes across versions" (in src/docs/spec-models.md) accordingly
• run SSSOM-Py test suite against the updated model

The sssom_version_enum and mapping_cardinality_enum enumerations contain permissible values (PVs) that by default are transformed into very unwieldy symbol names in many programming languages handled by LinkML generators.

For example, the 1:1 mapping cardinality value yields a symbol named number_1COLON1 (in Pydantic and Typescript) or NUMBER_1COLON1 (in Java). Likewise, the 1.0 SSSOM version value yields a symbol named number_1FULL_STOP0 (Pydantic, Typescript) or NUMBER_1FULL_STOP0 (Java).

This commit assigns to such PVs a title that the generators can use to derive the code symbols. For example, the 1.0 value for sssom_version_enum is assigned the "title" Version 1 0, yielding a much more convenient symbol named Version_1_0 (Pydantic, Typescript) or VERSION_1_0 (Java).

This has no effect on which values are accepted for a given enumeration. This only produces more meaningful symbols in generated code.

This is a workaround until LinkML provides a more explicit way of specifying custom code symbols for weird enumeration values (see linkml/linkml#3826).

[matentzn]

As a workaround its fine, but once your "symbol" suggestion is implemented I would like to change the titles to Version 1.0 etc..

[matentzn]

@cthoyt you are not affected as you are not directly using the generated pydantic classes - the only concern with this PR (which I have weighed and I am fine with) is that people using the old generated symbols directly will get a red wiggle in their IDE and need to change them (if I understand correctly, which I might not)

[cthoyt]

@matentzn I can't judge since this PR doesn't update the artifacts to go along with the schema. But I would guess nobody is using the pydantic classes generated by this. You could check by searching github

I would say just merge it (but also agree that the titles should be Version 1.0 and not Version 1 0, that just feels weird)

[matentzn]

@gouttegd there is nothing my judgement can add to yours in th this case; feel free to go ahead!

[gouttegd]

that people using the old generated symbols directly will get a red wiggle in their IDE and need to change them (if I understand correctly, which I might not)

Depending on which generated code they use, yes.

• people using the “standard” (non-Pydantic) code (notably, that includes us, since SSSOM-Py is using that code) are not impacted, since the standard Python generator does not generate symbols for enums;
• people using the Pydantic, Java, Typescript generators (and possible a few others) may indeed have to update their own code, if they make any explicit use of enums.
  • this does not affect @cthoyt which, I believe, is not using any LinkML-generated code;
  • this also does not affect my SSSOM-Java, which also uses hand-written enums (SSSOM-Java was started long before the Java generator in SSSOM-Py could properly deal with enums).

[cthoyt]

sorry i forgot I had to approve for merge