Add allow_unknown_designator slot.

[gouttegd]

This PR implements the idea proposed in linkml/linkml#3701 (and refined after a meeting with the core devs as outlined here).

That is, it adds a new slot (applicable to a slot definition) to alter the behaviour of a type designator slot.

If a slot is marked with both:

designates_type: true
allow_unknown_designator: true

then the constraint that the value of the slot must match the name/URI/CURIE of a known subclass of the class defining the slot (standard constraint for a type designator slot) is relaxed.

While we are at it, the description of the designates_type slot is also updated to make its meaning hopefully clearer. We also warn against the use of multi-valued type designators, as per linkml/linkml#1681.

[gouttegd]

Alternatively, we could decide that the mere presence of allow_unknown_designator is enough to imply that the class carrying the type designator slot is allowing extra slots (this is a possibility that was discussed in the aforementioned meeting).

If we wanted to do that, then (i) the last comment above should be removed, and (ii) the description should be amended to add:

Additionally, when this slot is set to True, the class carrying the type designator slot should be implicitly considered to allow extra slots (as if it was defined with extra_slots.allowed=True), unless the class definition has an explicit extra_slots configuration.

(For what it’s worth, I am not convinced this would be a good idea, if only because it creates “long range effects”: a class could be implicitly allowing extra slots even if nothing in the class definition says so, just because it has a slot – defined elsewhere in the schema – that has allow_unknown_designator: True. Better in my opinion to be explicit.)

[niegrzybkowski]

My unprompted 2 cents: skip the "allow_unknown_designator => extra_slots" implication. The subclasses could have the same slots as the base class, but may define different behaviors in their slot_usages, like expressions or rules.