feat(openenum): add is_open boolean slot to enum expressions

[noelmcloughlin]

Wait for #265 and #266

This PR adds is_open boolean slot to enum expressions in the meta model.

See linkml/linkml#127 and linkml/linkml#3712

[sneakers-the-rat]

The basic idea makes total sense to me. I just wonder if we want to have a single way of declaring this across the few places we want similar behavior - e.g. extra_slots allows for a boolean "yes others are allowed"/"no others are forbidden" as well as specifying an expression that other values must match. Do we want that here? We also need to add a similar thing at the SchemaDefinition level to specify openness of the whole schema/specify class/slot expressions to match extra members as well.

extra_slots as a name is too specific, I like is_open for a bool, the most generic name might just be extra.

Basically I am in favor of this but just wondering if we want to have a similar mechanism/pattern across all "openness" specs, or if there is a reason this one should be a boolean only

[noelmcloughlin]

I am just now thinking maybe is_open is bad name - I recall other discussions where someone (Chris?) worried it might get conflated with "open world" .. if push back comes then allow-other has precedent in Oscal Metamodel.

But issue linkml/linkml#127 proposes 'open enums' via is_open meta slot.

I noted linkml/linkml#1595 discusses extensible meta slot also - kinda related.

[sneakers-the-rat]

This has been a general naming tension between how I normally think and how linkml does names - I generally tend towards more general names whose meaning varies by context, and linkml tends to have specific names and only use them in one or a few contexts in which is has a single meaning. So where I would probably gravitate towards a single extra: term that could be used for slots, classes, enum items, etc., I think the linkml way would have a term per type of extra thing, extra_classes, extra_enum_items, etc.

is_open is probably the name I would reach for too for a boolean name, but it sort of doesn't have an obvious corrolary for the "middle" switch - true is "allow all," false is "allow none," but what would you call "allow some" (I.e. expressed in some subschema). open_to maybe? This was a consideration I remember finding tricky when landing on extra_* and having sub-terms within it, which is not the most elegant solution.

But anyway, need to decide if we want to have common mechanism/pattern for declaring "all/none/some" openness, or if sometimes binary and sometimes trinary is fine. That also narrows down which names work.

[matentzn]

As this issue is slightly beyond my current ability to judge, @amc-corey-cox has volunteered to thinking through the implications and presenting a short version of this at the next developer call in one week. Sorry for the delay - please keep pushing if we slow you down; I can find more aggressive alternative review processes. 🚀

[amc-corey-cox]

The shape looks right to me. is_open as a boolean fits the metamodel: it mirrors id_prefixes_are_closed — one slot builds the value set, another says whether it's exhaustive. is_open: true just demotes the permissible values from MUST to SHOULD; it doesn't collapse the range.

@sneakers-the-rat on binary-vs-trinary: I don't think enums need the all/none/some shape that extra_slots has. extra_slots had to be trinary because it has no set-construction of its own. Enums already do that via permissible_values/reachable_from/matches/include/minus. And per-value constraints already work: a slot pattern holds independently of enum membership, so "extras must be well-formed" needs nothing new.

If a real case for open_to: shows up, that will need more definition than we're ready to do here and we should design around the live case.

[noelmcloughlin]

Changes done. Raised #265 and #266 due to test failures.

[amc-corey-cox]

This shouldn't merge ahead of #265 — the pre-commit config currently rides in on a merge commit and deserves its own review. Otherwise all five of my comments are addressed: ifabsent is gone, the description no longer contradicts itself, and the example plus round-trip tests go further than I asked for.

[sneakers-the-rat]

on binary-vs-trinary

OK cool, makes sense to me, then in general we are not going for naming consistency for openness across the different places that we want to declare it? We should probably make some kind of grouping/subset for openness terms then, or else make sure they are documented together. E.g. we might sprout an extra_classes at the schema level, and then we have

• is_open - on enums
• extra_slots - on classes
• extra_classes - maybe, on schema (name undecided)
• open_world - I'm actually not quite sure how this works, but its confusable by name and should be differentiated

I think just having a listing like that on each that refers to the others as part of a set in the docs would be enough. Main concern I have is being confusing/hard to discover if similar concepts are named differently.

These were resolved above.