Revise stripping of annotation properties in imports

[gouttegd]

The ODK 1.5 forcefully introduced a new feature in which almost all annotation properties, except rdfs:label and IAO:0000115, are forcibly removed from the import modules.

I say “forcefully” because, unless I missed something, that feature is not deactivatable. The only thing a user can do is amend the list of annotation properties that are not removed, to preserve more properties than just rdfs:label and IAO:0000115.

This was intended to reduce the size of the import modules, and based on the premise that annotation properties are never “significant” (especially from a reasoner’s point of view) anyway.

However that premise is blatantly false, as annotation properties loaded with a “logical meaning“ are certainly not unheard of. (One can argue about whether this is a good idea or not, but that’d be beside the point.)

In particular, it is a relatively common practice to use annotation properties as “shortcuts” to be replaced by more complex logical axioms. That idea has been around for example with OWLTools’ macros for more than a decade (Mungall, Ruttenberg, and Osumi-Sutherland, 2010), and while the use of OWLTools is being phased out, ROBOT’s expand command merely continues on the same principle, the only difference with OWLTools being the language used to express the expanded form of the “macro” (OWL Manchester for owltools --expand-macros, SPARQL for robot expand).

Examples of annotation properties with a “logical meaning” include:

• mutually spatially disjoint with
• present in taxon
• never in taxon
• has no connections with

All that to say that removing almost all annotation properties from imports is not something that should be done lightly because it can definitely have drastic consequences for the ontologies that use the ODK to manage their imports. As an example, the entire check for violation of taxon constraints in Uberon has been completely neutralised by this “feature” (obophenotype/uberon#3336).

So what should the ODK do now?

A. Nothing. It’s up to the users to know that they depend on some specific annotations in the ontologies that they import, and to declare said annotations in the import_group.annotation_properties option of their ODK configuration file so that they are not removed.

Why not, but then this needs to be thoroughly documented somewhere. As far as I know, the only “documentation” for now is this line in the description of the ODK Project Configuration Schema:

annotation_properties (list)(: Define which annotation properties to pull in. Default: [rdfs:label, IAO:0000115]

I believe this is woefully insufficient. At no point do we actually explain that the ODK does not “pull” all annotation properties from imports, only those that are listed here. Combined with the fact that the feature was introduced without any announcement in the release notes, users have had no chance at all to know that from now on they should declare the annotation properties they need.

B. Revert the feature entirely.

That’d probably be too much. There is no doubt the feature is useful.

C. Leave the feature as it is, but make it optional.

Simply add an option to enable it (if disabled by default) or disable it (if enabled by default).

D. Leave the feature as it is, but preserve more annotation properties by default than just rdfs:label and IAO:0000115.

At the very least, we should preserve:

• expand assertion to (used by OWLTools’ --expand-macros command);
• expand expression to (likewise);
• defined by construct (used by ROBOT’s expand command);
• all annotation properties under RO’s logical macro assertion.

Also, I believe that preserving a given annotation property should automatically preserve all its subproperties. That is, users should not have to declare that they want to preserve both present in taxon and always present in taxon – just declaring the former should automatically preserve the latter.

[matentzn]

My current preference:

1. We do C
2. We do D partially by adding the properties you suggest to the "default list to preserve"

Also, I believe that preserving a given annotation property should automatically preserve all its subproperties.

I am slightly critical of this as it

1. Is actually not that easy to implement
2. Creates either a runtime dependency on some ontology like OMO or RO, or a design time dependency on ODK (that queries the property and adds the children to the default list at release time).

I am not totally opposed to (2), but I currently doubt the effort is worth it.

[gouttegd]

Also, I believe that preserving a given annotation property should automatically preserve all its subproperties.
I am slightly critical of this as it

1. Is actually not that easy to implement

I am stating the desired behaviour. Whether it is easy or not comes after.

And I am not sure about it being “not that easy”. ROBOT’s remove command includes a descendants selector which should do the job. So, at least when the “merged imports” system is used, it should be quite feasible – assuming the ontology that defines the relation(s) you want to preserve is among the ontologies you are importing, but in most scenarios that should be the case. After all, if you know you depend on relations defined in a given source ontology, chances are that you are doing something with that ontology and importing it.

That can even be an explicitly documented requirement for the feature to work: ”To preserve an annotation property, list it in the import_group.annotation_properties option. Note that the subproperties of any property listed there will only be preserved as well if (1) you use merged imports and (2) the subproperties are defined in one of the imports. Otherwise, only the declared property itself will be preserved.”

So for example, if you want to preserve all properties below RO’s logical macro assertion (RO:0002416), you can either:

• explicitly list all the descendants of RO:0002416 in import_group.annotation_properties, or
• list only RO:0002416 and make sure you import RO.

[matentzn]

What if you for some reason do not want the children to be included?

[gouttegd]

What’s the likelihood of that?

Until 6 months ago, all annotations were kept. Removing all annotations except those listed in import_group.annotation_properties and their children would still be an improvement.

If you really, really need to preserve only one specific AP and specifically exclude all its children, just add a custom step in your workflow to remove the children.

[matentzn]

Examples:

• OBI/IAO and Friends use IAO:0000118 and not oio:hasSynonym. IAO:0000118 is the parent of oio:hasSynonym in OMO. So you can at least imagine how someone may want to keep IAO:0000118 while not wanting any of the others.
• Similarly, there is some odd combination where you want to keep the general synonym type or subset properties, but none of its children (which are often custom, embedded by any ontologies including RO for no reasoner other than local metamodelling).

If we go this way I would advocate for a exclude_annotation_property_children flag which is set to "true" by default.

[gouttegd]

If we go this way I would advocate for a exclude_annotation_property_children flag which is set to "true" by default.

Still unconvinced that this is a real need, but I’d have no objection to that. :)