Unexplained change of Annotation Property labels also in imports

[allenbaron]

Sometimes Protege will change the label used in the main file being edited. I'm guessing that it's replacing this with a label for the same URI from an import.

Probably easiest to show this with an example from the Mammalian Phenotype Ontology (MP).

In mgijax/mammalian-phenotype-ontology@b705fa6 a number of annotation property labels were replaced:

• has cross-reference --> database_cross_reference
• has exact synonym --> has_exact_synonym
• has narrow synonym --> has_narrow_synonym

For those that were just space to underscore conversions it wasn't a big deal, but for the 'has cross-reference' to 'database_cross_reference' it's made it challenging for MP curators to find the annotation property to add.

Troubleshooting Attempt 1

When initially digging into the change, I noticed that the two prior commits show database_cross_reference as the label when they are checked out and Protege is open and it was not until the third commit back (mgijax/mammalian-phenotype-ontology@263433c) that it showed up as has cross-reference.

Commit order:

I tried to figure out what change was made in commit 9e26d1a that would've prompted the switch but when I tried git reset HEAD~ to make it so I could find out which file changes might have caused this, I closed and reopened Protege to ensure it was the same only to discover that the label now appeared as database_cross_reference. I then wiped that out and re-checked out the original commit 9e26d1a and it was still database_cross_reference.

So Protege's behavior is not consistent even with the same exact data.

---

Troubleshooting Attempt 2

While considering this head scratcher, I noticed that the actual triple for the label in mp-edit.owl has never changed. The triple has always been:

AnnotationAssertion(rdfs:label <http://www.geneontology.org/formats/oboInOwl#hasDbXref> "database_cross_reference")

But if you do a git log search, you'll notice that the label Protege assigns to the header does change.

Use this:

git log -p -S"# Annotation Property: <http://www.geneontology.org/formats/oboInOwl#hasDbXref> (has cross-reference)" -- src/ontology/mp-edit.owl

For example in mgijax/mammalian-phenotype-ontology@20cc865 this is what mp-edit.owl looks like:

And in mgijax/mammalian-phenotype-ontology@1382567 this is what mp-edit.owl looks like:

---

I have no idea what Protege is doing here but it brings up some questions:

• Shouldn't the renderer always use the label as defined in the main file? Is it somehow choosing labels out of import files at random instead?
• How does Protege decide what to write as the label on the Annotation Property header line that starts with #?

This problem is not limited to MP. The same thing happens on occasion with the Disease Ontology.

All labels for these APs (as Protege images)

These are all from mgijax/mammalian-phenotype-ontology@b705fa6

has cross-reference

has exact synonym

has narrow synonym

[gouttegd]

These are two different issues.

Shouldn't the renderer always use the label as defined in the main file? Is it somehow choosing labels out of import files at random instead?

Protégé is not choosing the label “at random“ – it loops over all the available annotations (regardless of whether they are in the -edit file or in imports) and consistently picks up the first label annotation it finds (assuming the option “Render by label” is selected; if other rendering options are selected, the principle remains basically the same, but with whatever custom properties are configured).

Thing is, the order in which annotations are looped over is, from Protégé’s point of view, not deterministic: Protégé has no control upon that order, which is entirely decided by the underlying OWLAPI.

How does Protege decide what to write as the label on the Annotation Property header line that starts with #?

It does not. This is entirely decided by the OWLAPI, to which Protégé completely delegates all writing operations.