Changing "ends with" prefix to # doesn't stick unless you also manually set prefix in Active Ontology tab

[mdebellis]

I reported this last night on the User Support for Protege mail list.

I've been noticing that the IRIs in my ontologies seem to be inconsistent when it comes to whether the IRI ends in a # or / You set this in File>Preferences>Entity IRI>Followed by

I tried the following experiment on Protege 5.6.1 running on Windows 11 Pro.

First I closed Protege so there would be no issues with existing or previous ontologies. Then I opened it and named the default new ontology that you get when you open Protege to PoundTestOntology. Then I changed the "ends in" to # rather than / Then I created two classes: TestClass1 and TestClass2. Then I looked at the IRI for TestClass2 by selecting it and doing Refactor>Rename Entity and clicking the "show full IRI" box. Looked good, IRI ended in # as expected. See picture:

I saved the ontology in turtle and closed Protege. Then I started Protege and loaded the ontology I just saved. Then I did the same thing, checked the IRI for TestClass2 and now it ends in a slash:

What is worse, though is it remembered my preference. So when I created TestClass3 and looked at its IRI it now ends in a #.

Now I have two inconsistent IRIs so if I do things in Snap SPARQL it won't work. Unless I painstakingly check the IRI of each entity and create two different prefixes any query will miss some IRIs because some end in # and some end in /. So for people like me who like to use Snap SPARQL and commands like Rename Multiple Entities things won't work as expected.

The good news is that when I save the revised ontology and then reload it, as one would expect we are consistent again. All the classes end in /. But new ones will end in # and we won't have a consistent ontology until we save and reload and as soon as we start editing we will again have an inconsistent ontology.

After this I opened another ontology I've been working on where I thought we were ending in # and to my surprise we were ending in # but in this case the ontology seemed fine. I think I realize why. In the ontology I'm working on, I explicitly set the ":" prefix to the ontology IRI ending in #. So that is a good work around. However, my recollection is you didn't used to have to do that, that such a prefix was generated automatically in previous versions.

Michael DeBellis
https://www.michaeldebellis.com/blog

[matthewhorridge]

Reproduced this. The problem seems to be specific to saving and reloading an ontology in Turtle format. I'm not sure whether this is a Protege bug or an OWL API bug. A work around is to use a different format, for example RDF/XML for saving the ontology.

[matthewhorridge]

Another workaround is to make sure the ontology IRI is not a prefix for entity IRIs. So, if the ontology is named http://foo.com make sure entity IRIs do not have the http://foo.com prefix, e.g. http://bar.com won't exhibit this problem. Less than ideal but it's a work around.

[matthewhorridge]

Pasting in this from a user called Hyacinth,

This is one of the many bugs and malfunctions of OWLAPI pertaining to the default : prefix.

The reason why the problem emerges in your file is that the default : prefix is not defined by the # but by the / character:

Once you set the IRI of the new entities to be followed by the # character, every new entity will have a full IRI containing the # character. In this case, if there exists any prefix that abbreviates the ontology IRI followed by a # character, then the new entities will be saved by prefixed name using that specific prefix. But in the case of your file, there is no such prefix (The default : prefix is the ontology IRI followed by / and not #). The logical behaviour in this case is for OWLAPI to save the new entities by full IRI and not by prefixed name. However, OWLAPI incorrectly saves the new entities by prefixed name using the default : prefix which in fact defines the IRI by / character and not the # character. This is the reason why all of the entities will contain / instead of # in their IRIs when you open the ontology next time.

A quick fix is to change the default : prefix to end with # instead of the / character: