add alias suggestion #66
Conversation
linkml_model/model/schema/meta.yaml
Outdated
| @@ -1333,6 +1360,15 @@ classes: | |||
| close_mappings: | |||
| - qb:HierarchicalCodeList | |||
|
|
|||
| alias_definition: | |||
There was a problem hiding this comment.
so our naming conventions are a bit odd. Only slot_definition and class_definition inherit from definition... yet schema_definition inherits from element, despite it's name...
How about we reserved Xdefinition for things with identifiers, we can simply call this structured_alias?
linkml_model/model/schema/meta.yaml
Outdated
| slots: | ||
| - alias_name | ||
| - alias_source | ||
| - alias_scope |
There was a problem hiding this comment.
scope: This naming convention is very obo-format esque and not really used elsewhere. I would favor alias_type (perhaps alias_property/predicate/category)
There was a problem hiding this comment.
I removed the 'alias_' convention and this turned into 'type' (and changed 'alias_scope_enum' to 'type_enum').
linkml_model/model/schema/meta.yaml
Outdated
| and its scope (narrow, broad, etc.) | ||
| slots: | ||
| - alias_name | ||
| - alias_source |
There was a problem hiding this comment.
Just added source #62 -- could be reused?
There was a problem hiding this comment.
moved to use 'source' instead of 'alias_source.' I'm a little worried that we won't have uriorcurie for every alias source (eg.: I have sources in the biolink-model that are 'fake' curies to get around this requirement in the mapping objects like 'GAMMA:activator' where GAMMA is a made-up prefix), but, it could be that we change the alias source in this case to an actual source that might be broader than the made-up source.
linkml_model/model/schema/meta.yaml
Outdated
| object that contains meta data about a synonym or alias including where it came from (source) | ||
| and its scope (narrow, broad, etc.) | ||
| slots: | ||
| - name |
There was a problem hiding this comment.
ah, unfortunately this is problematic. The metamodel follows a tradition in logic/linked data in using "name" to designate an identifier - and indeed name is marked as being an identifier, which will cause problems here, e.g. it will be inlined as a dict with the "names" being keys.
A perfectly acceptable alternate would be alias but that is actually slot-specific and used to designate the preferred label for the slot (i.e. unmangled)
Naming things is hard, I might just go with alias_value or label
| @@ -110,9 +110,22 @@ slots: | |||
| in_subset: | |||
| - owl | |||
|
|
|||
| type: | |||
There was a problem hiding this comment.
I suggest alias_type OR keeping type generic and putting the specifics in slot_usage... but in this case I think alias_type and alias_type_enum is the way to go
There was a problem hiding this comment.
I'm not sure what the best approach is here. Could you also have subproperties of alias_type such as:
has narrow aliashas broad aliashas exact aliashas close alias- etc.
From querying standpoint the difference would be:
- Find all alias names where the alias_type = exact
vs. - Find all values of has exact alias
|
@sierra-moxon @cmungall and everyone else ... |
| type StructuredAlias | ||
| { | ||
| name: String! | ||
| source: Uriorcurie |
| type: | ||
| range: type_enum | ||
| description: >- | ||
| The relatedness of an alias to the element it is aliasing. type can be: narrow, broad, exact, |
There was a problem hiding this comment.
Instead of just narrow and broad, do you want is narrower than and is broader than ? It may make it clearer.
No description provided.