search

INCATools / dead_simple_owl_design_patterns

A simple system for specifying OWL class design patterns for OBO-ish ontologies.
http://incatools.github.io/dead_simple_owl_design_patterns/
GNU General Public License v3.0
40 stars 5 forks source link

Define how identifiers are expanded to IRIs #21

Closed balhoff closed 7 years ago

balhoff commented 7 years ago

Patterns I have seen use a mix of ID styles including both e.g. GO_0016020 and GO:0016020. Templates could contain a prefixes key containing mappings. This would be more straightforward than a full-blown JSON-LD context. Non-CURIE IDs such as GO_0016020 could be supported by also having a base key. Example:

pattern_name: oba/patterns/entity_attribute
classes: []

prefixes:
  RO: http://purl.obolibrary.org/obo/RO_

base: http://purl.obolibrary.org/obo/

relations:
  part of: BFO_0000050
  inheres in: RO:0000052
  inheres in part of: RO_0002314

Since there are no literals I don't know that we need to wrap in <> to distinguish unprefixed IRIs from CURIEs.

cmungall commented 7 years ago

See also #5

I generally use a separate prefix map yaml file, e.g. this one for ecto. This could be derived from JSON-LD, but doesn't require the overhead of JSON-LD.

I think having the option of having the prefixes in the pattern yaml is a good one (just as in jsonld you can have both external reused contexts and ones in the file). However, in general I prefer having a single place to make the change rather than multiple.

balhoff commented 7 years ago

I can add an option to dosdp-scala to pass the prefix yaml file to use.

balhoff commented 7 years ago

dosdp-scala now accepts a yaml prefix map like the one @cmungall linked to, via --prefixes=. Also, there is an OBO option, --obo-prefixes=true, which has rdf, rdfs, and owl predefined, and all other CURIEs are expanded as OBO ontologies (no need to pass mapping file if this suffices). These can be used at the same time, with the explicit mappings taking precedence.