Slots, slot_usage and attributes

[hsolbrig]

We are thinking about backing off on "lone" slot_usage entries as they have some unpleasant side effects as they are currently implemented. Example:

id: https://example.org/slot_usage
name: slot_usage
description: An example of two slot usages that clash in the global space

prefixes:
  biolinkml:  https://w3id.org/biolink/biolinkml/

imports:
  - biolinkml:types

classes:
  c1:
    slot_usage:
      slot_1:
        required: true
        range: integer

  c2:
    slot_usage:
      slot_1:
        multivalued: true
        range: string

Produces the following:

slots:
  slot_1:
    name: slot_1
    from_schema: https://example.org/slot_usage
    range: integer
    slot_uri: https://example.org/slot_usage/slot_1
    required: true
  c1_slot_1:
    name: c1_slot_1
    from_schema: https://example.org/slot_usage
    is_a: slot_1
    domain: c1
    range: integer
    slot_uri: https://example.org/slot_usage/slot_1
    required: true
    alias: slot_1
    owner: c1
    domain_of:
    - c1
    is_usage_slot: true
    usage_slot_name: slot_1
  c2_slot_1:
    name: c2_slot_1
    from_schema: https://example.org/slot_usage
    is_a: slot_1
    domain: c2
    range: string
    slot_uri: https://example.org/slot_usage/slot_1
    multivalued: true
    required: true
    alias: slot_1
    owner: c2
    domain_of:
    - c2
    is_usage_slot: true
    usage_slot_name: slot_1

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 the slot_1 slot.

Comments?

[hsolbrig]

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?)

[cmungall]

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

[hsolbrig]

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.

[hsolbrig]

(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...)

[hsolbrig]

This has been implemented in the attributes branch of biolinkml. Examples can be found in https://github.com/HOT-Ecosystem/tccm/tree/master/model

[hsolbrig]

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.