Extend to allow specification of annotation properties in dict, and their mapping to field names.
Closed this issue · 5 comments
The current spec is OBO-specific in that it has built-in field names for name (label), def and comment. It could be made more generic by allowing specification of annotation properties. It would be good to hide this for usage by the OBO community, so probably best to do in a linked yaml document (URI namespaces for docs important for this)
e.g.
Add field to existing spec:
annotation_style:
Example
<some_base> obo_annotation_style.yaml
pattern name: obo
pattern_type: annotation_style_spec
annotation_properties:
label: http://www.w3.org/2000/01/rdf-schema#label
definition: http://purl.obolibrary.org/obo/IAO_0000115\
comment: http://www.w3.org/2000/01/rdf-schema#comment
field_mappings:
name: label
def: definition
comment: comment
Note: DOS-DP is potentially useful as a simple, generic system for specifying transformation of the output of Webulous spreadsheets into OWL. Making the system more generic for APs is important to this aim.
So we can still have name
and definition
as top-level in the pattern yaml, we just need to specify this using a meta-template?
+1
So we can still have name and definition as top-level in the pattern yaml, we just need to specify this using a meta-template?
Yep
OK, I see in spec/ we have DOSDP_convenience_fields.yaml, which specifies how to handle equivalentTo
Still not sure exactly how this is intended to work. Is the idea to be able to mix and match custom convenience schemas, and compile down to a project specific JSON schema file?
There may be a json-schema mechanism I'm unaware of here
The idea is that the core schema is fully expressive. The mapping schema is a json schema for defining derivations of the core schema. Convenience fields are one such derivation. These are simply fields that can be used to add logical axioms when there is only one axiom of that type in the pattern. It may have been overkill to put these in a derived schema rather than make them core. OBO fields are specified in another file following the mappings schema.
The files themselves still need some work.