slot_usage induces new sub-slots, these should be hidden in many exports #48
Description
blml allows the usage of a slot to be refined (or even defined) on a per-class basis.
E.g The label slot may be generic for any kind of name. For a person class we may add documentation that states this should be a string that is typically first and last concatenated (OK, this would not be a very good rule for many names but you get the idea).
Originally I had conceived of information about a slot always being retrieved via a compound key of (class,slot). If there is a slot usage for a class, use that. Otherwise a superclass. Otherwise generic slot.
In the current implementation rather than compound key, a primary key is synthesized by concatenating class and slot. This is fine as an underlying implementation, but this should be hidden in many cases, as it causes confusion (e.g biolink/biolinkml#228).
here is a test example:
id: https://github.com/biolink/biolinkml/issues/228
name: test228
title: induced slots
types:
string:
base: str
uri: xsd:string
classes:
r1: {}
r2:
is_a: r1
r3:
is_a: r2
c1:
slots:
- s
slot_usage:
s:
description: s in c1
range: r1
c2:
is_a: c1
slots:
- s
slot_usage:
s:
description: s in c2
range: r2
c3:
is_a: c2
slots:
- s
slot_usage:
s:
description: s in c3
range: r3
d:
slots:
- s
slot_usage:
s:
required: true
slots:
s:
description: >-
generic s description markdown changes required:
currently this generates pages for c{1,2,3}_s, as well as s. Only pages for s should be generated. c1,2,3 specific usage can be included in the markdown file for s
All usages of the arrow notation in the generated markdown docs should be removed
owlgen changes required:
currently uris are made for c{1,2,3}_s. We should only have a uri for s.
class-specific ranges can be expressed using an owl subclass axiom
python changes:
reported separately by @wdduncan here: biolink/biolinkml#228 -- but I think current behavior may be ok, if a little confusing
json schema changes:
the current json schema generation is almost correct. There are no induced slots created - only s.
Currently gen-json-schema on the above makes:
{
"$id": "https://github.com/biolink/biolinkml/issues/228",
"$schema": "http://json-schema.org/draft-07/schema#",
"definitions": {
"C1": {
"additionalProperties": false,
"description": "",
"properties": {
"s": {
"$ref": "#/definitions/R1",
"description": "s in c1"
}
},
"required": [],
"title": "C1",
"type": "object"
},
"C2": {
"additionalProperties": false,
"description": "",
"properties": {
"s": {
"description": "generic s description",
"type": "string"
}
},
"required": [],
"title": "C2",
"type": "object"
},
"C3": {
"additionalProperties": false,
"description": "",
"properties": {
"s": {
"$ref": "#/definitions/R3",
"description": "s in c3"
}
},
"required": [],
"title": "C3",
"type": "object"
},
"R1": {
"additionalProperties": false,
"description": "",
"properties": {},
"required": [],
"title": "R1",
"type": "object"
},
"R2": {
"additionalProperties": false,
"description": "",
"properties": {},
"required": [],
"title": "R2",
"type": "object"
},
"R3": {
"additionalProperties": false,
"description": "",
"properties": {},
"required": [],
"title": "R3",
"type": "object"
}
},
"properties": {},
"title": "test228",
"type": "object"
}this is pretty good. C1 and C3 are perfect. the localized use of s is correct. However, C2 is deferring to the generic slot, which is bizaarre