Extend to allow specification of annotation properties in dict, and their mapping to field names.

[dosumis]

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

obo_annotation_style.yaml ``` .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 ``` @simonjupp @cmungall

[dosumis]

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.

[cmungall]

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

[dosumis]

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

[cmungall]

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

[dosumis]

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.