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

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.

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.

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. 🚀