Scenario: I have a slot that I map to rdfs:label

slots:
  name:
    slot_uri: rdfs:label

This slot is used by different classes in my model. The semantics are the same regardless of where it is used

Now, I want to provide context-specific documentation on that slot, and perhaps also context-specific constraints. Note I am not changing the semantics, it's still an rdfs:label

e.g.:

 Genome:
    slots:
      - id
      - name
      - taxon
      - build
      - previous_builds
    slot_usage:
      id:
        description: E.g. mm, hg
        pattern: '^\\w+$'
      name:
        description: E.g. Homo sapiens
        pattern: '^\\w+\\W\\w+$'
        required: true

Here I am saying that when rdfs:label is used with a Genome instance, I want to provide additional informative information to the model user, and add a regex and presence check.

When we look at how this gets expanded (using gen-yaml), I get as expected an induced Genome_name slot

  name:
    name: name
    definition_uri: https://w3id.org/biodatamodels/chromoschema/name
    mappings:
    - rdfs:label
    description: Unique human-readable label for the entity
    from_schema: https://w3id.org/biodatamodels/chromoschema
    slot_uri: rdfs:label
    owner: OrganismTaxon
    domain_of:
    - ChromosomePart
    - Genome
    - GenomeBuild
    - OrganismTaxon

  Genome_name:
    name: Genome_name
    description: E.g. Homo sapiens
    from_schema: https://w3id.org/biodatamodels/chromoschema
    is_a: name
    domain: Genome
    slot_uri: chromoschema:name
    required: true
    alias: name
    owner: Genome
    domain_of:
    - Genome
    is_usage_slot: true
    usage_slot_name: name

Although I do not love having these induced slots, I have workarounds for them now. However, in this case it was my intent to provide contextual information, but to retain using rdfs:label as a slot_uri

Currently my options are:

• every single time I use slot_usage (even if only to provide contextual documentation), I redundantly restate the slot_uri, violating DRY
• I write some contorted code that reinjects the original slot_uri... but this is problematic, as I have no way of knowing if the slot_uri field in the induced slot was asserted or put there by the schemaloader

Instead, I think we should change schemaloader:

• when creating an induced slot:
  • first copy/inherit all metaslots of the parent slot
  • write over these if specified by the user