Allow arbitrary defined annotation properties as qualifier tags in OBO format

[balhoff]

Currently annotation property IRIs for properties used for sub-annotations (e.g., annotating source of a definition) are always mangled into the oboInOwl namespace. These changes will allow using any defined annotation property.

[balhoff]

See owlcollab/oboformat#125

[cmungall]

thank you thank you 🙏 🙏 🙏

[ignazio1977]

looks good to me

[balhoff]

Thanks! I'm going to do a bit more testing on some real ontologies before marking it ready for merge.

[balhoff]

With the implementation so far, one of the differences you see in parsing with the old code vs. the new code is where it would fall back to the oboInOwl namespace for some of the built-in tags. A few of the tags do not have an IRI specified in Obo2OWLConstants.java. You can see that I added one for id, which I think needs to happen since that property is added automatically by the parser. But some are missing, such as created_by and creation_date. The OBO format 1.4 spec maps these to dc properties (but that part of the spec is colored red... uncertain?). In practice these have been getting oboInOwl namespaces when parsed.

If I add these to the constants file, they will always get mapped to what I put in: oboInOwl would be backwards-compatible, or else dc properties to match what the spec was aiming for (or even better, dcTerms). However, if I don't add them, they can be easily mapped with the addition of a Typedef stanza like so:

[Typedef]
id: created_by
name: created by
namespace: external
xref: http://purl.org/dc/terms/creator
is_metadata_tag: true

I think this would be great, since the file would use the built-in tags but map to user-defined properties. In this situation though, if there is no Typedef, rather than going into the oboInOwl namespace, they would end up with an ontology IRI hash IRI (e.g., http://purl.obolibrary.org/obo/go#created_by). Allowing override like that would change the parsed IRIs for ontologies that don't add a Typedef.

[balhoff]

To add on, I guess there are two different questions:

• should we allow any built-in tags to be overridden by typdef declarations?
• if we don't allow override, should we map those two tags to DCterms?

[cmungall]

I agree with your analysis. I think defaulting to oboInOwl is consistent with existing behavior. If people really want to use a shorthand name and a custom URI, they can include a Typedef.

But I think either we would be encouraging people who are mapping there axiom annotations forward to something more interoperable to use a curie, e.g. {dcterms:source=...., with the prefix mapped in the idspaces header

[balhoff]

@ignazio1977 I think this is ready to merge, thanks!

[ignazio1977]

Done, I've rebased it and tweaked the test a bit to fit the style f the rest of the tests.