Closed hsolbrig closed 3 years ago
Note: we may want to consider some sort of lexical convention to prevent:
slots:
c1_slot_1:
from colliding. I'd been thinking that the class name made it unique because the first character was in Caps, but, apparently the slot name mangling takes precedence. Maybe c1__slot_1
(double underscore between them?)
I'd like some time to think about this. I find the lone slot_usage convenient. I'm not sure I fully grok the problem.
I've never been keen on the injection of new slot IDs, my original idea was to have a single slot ID, and to treat slot_usage as declarations about a compound key / blank node see #231
Using slot_usage to define a new slot results in the namespace pollution shown above.
The following:
class C1:
attributes:
slot_1:
range: int
Would be shorthand for:
slot c1__slot_1:
alias: slot_1
range: int
class C1:
slots:
- c1__slot_1
With the exception that:
class C2:
is_a: C1
slot_usage:
slot_1:
range: int
Would override c1__slot_1
as expected.
If you're strongly committed to using slot_usage
to introduce new slots, we can leave the behavior as is, with the understanding that:
a) A typo in a slot_usage
that is intended to override a parent slot will (likely) go undetected and
b) You will have to manage the namespace pollution issue described above or change the behavior to be identical to the proposed attributes
entry above.
(Also, FWIW, attributes
will speed some of our demo's as we won't have to explain that slot_usage
exhibits exactly the same behavior something called attribute
does in most modeling language as long as you don't name an existing slot, where, at that point it acts as a constraint...)
This has been implemented in the attributes
branch of biolinkml. Examples can be found in https://github.com/HOT-Ecosystem/tccm/tree/master/model
We are beginning to incorporate the attributes
elements in examples and other implementations. If you still object to this feature, now would be a good time to speak up.
We are thinking about backing off on "lone" slot_usage entries as they have some unpleasant side effects as they are currently implemented. Example:
Produces the following:
What we would like to do is: 1) tighten up "slot_usage" so that it HAS to be a specialization of an inherited slot ('inherited' == from is_a, mixins or applies_to) 2) declare a new class slot,
attributes
, which would behave exactly as above with the exception that it wouldn't emit theslot_1
slot.Comments?