Inverse Domain or Range not Inferred when using 'Class1 or Class2'

[mdebellis]

DomainRangeExample.zip When you define the domain or range of an Object Property to be 'Class1 or Class2' and define an inverse for that property the inverse domain or range are left blank. I reproduced the problem in the attached small ontology. I have a property called hasLocation with domain 'Person or Building' and its inverse is isLocationOf. The range of isLocationOf I would think should be 'Person or Building' but it is undefined. I've noticed this happens in a larger ontology I'm developing for a client right now. I'm using Pellet on Windows 11 Pro with the Protege Desktop 5.6.1

[mdebellis]

Okay. Thanks.

On Sat, Mar 30, 2024 at 11:48 PM sultanifar @.***> wrote:

It is inferred but just not shown in the UI.

DomainRangeExample.zip https://github.com/protegeproject/protege/files/14814409/DomainRangeExample.zip

In the attached file, I added two individuals to your ontology: 'building' and 'location'. 'location' is connected to 'building' via the 'isLocationOf' property and 'building' is defined as an instance of 'not(Person)'. Once you can start the reasoner, it will be inferred that 'building' is an instance of 'Building'. You can click on the ? button to see the explanation and it clearly shows that the domain and range of the inverse property are inferred, though not indicated in the Protégé UI.

— Reply to this email directly, view it on GitHub https://github.com/protegeproject/protege/issues/1197#issuecomment-2028577440, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD7TPBCD7JFHYXN4RAXCT3TY26WUZAVCNFSM6AAAAABFJ3QOVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYGU3TONBUGA . You are receiving this because you authored the thread.Message ID: @.***>

[mdebellis]

What is the appropriate thing to do in cases like this? Should I mark the issue as resolved? On the one hand, knowing that it is inferred works for me but on the other I would think the team would want to fix this in the next version of Protege so perhaps I shouldn't mark as closed?

[sultanifar]

I apologize because I removed my comment a few minutes after I sent it since it was somehow a wrong answer, but it was only removed from the GitHub page and the sent email could not be removed.

Whenever any two individuals get connected using the inverse property ('isLocationOf' in the case of your example), it will be inferred that the main property ('hasLocation' in the case of your example) also exists between those two individuals in the reverse direction. Since the main property's domain and range are defined, any conclusion that can be made using the domain and range of the inverse property can also be made using the domain and range of the main property. There is no case in which the domain and range of the inverse property can give rise to an inference which can not also be given rise by the domain and range of the main property. (Sorry if I couldn't put it in words clearly.) Therefore, there is no need at all to infer the domain and range of the inverse property as it probably puts unnecessary computations in the reasoning process.

On Mon, Apr 1, 2024 at 6:58 PM Michael DeBellis @.***> wrote:

What is the appropriate thing to do in cases like this? Should I mark the issue as resolved? On the one hand, knowing that it is inferred works for me but on the other I would think the team would want to fix this in the next version of Protege so perhaps I shouldn't mark as closed?

— Reply to this email directly, view it on GitHub https://github.com/protegeproject/protege/issues/1197#issuecomment-2029974658, or unsubscribe https://github.com/notifications/unsubscribe-auth/BCDKDH2CP37TQELGHLNGJC3Y3F4JXAVCNFSM6AAAAABFJ3QOVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRZHE3TINRVHA . You are receiving this because you commented.Message ID: @.***>

[mdebellis]

Sultanifar: Either I'm not understanding you or I think you are incorrect. You seem to be saying there is no need for the reasoner to infer the inverse domain/range. If that is what you are saying I don't agree. In fact, that is not the way OWL and Protege usually work, at least for the reasoners I use. It is normal for the reasoner to add the domain and range for the inverse property and to display it in the UI. Moreover, IMO that is absolutely the correct thing to do. Yes, you could make that inference at run time but actually making the inference when you are designing the ontology will help you spot potential errors faster. Also, the same goes for reasoning. You could make the inference about the domain and range at run time but that would be slower (every time you assert a value you need to infer the domain and range of an inverse). Doing it at design time is both faster (you just do it once) and helps people understand the ontology. This is a minor bug, but IMO it is still a bug and it would be better if in the next version of Protege the domain and range were visible in the GUI when you use 'Class1 or Class2' as they are when you just make the domain or range a single class. Actually, I usually try to avoid using "Class1 or Class2" and in most cases where I would use this I take it as a good indication that there should be some common superclass for both Class1 and Class2 (which is what the reasoner does anyway: creates a common anonymous superclass). But that's not always the case and once in a while having two or more classes can be the right way to model things.

[sultanifar]

Sorry for late response. The only important thing I wanted to say was that the example I gave in my first (and removed) comment was not an evidence to deduce that the inference is done and the matter is only about the UI. You can turn off the "Domains" and "Ranges" checkboxes from the "Reasoner" tab in Protégé preferences and see that the example still works and 'building' will become an instance of 'Building'

Assume we have two object properties called r1 and r2 which are the inverses of each other. And we have two classes A and B which are respectively the domain and range of r1. Now if for two individuals like x and y we have "x r2 y" then it will be inferred that "y r1 x" (since r2 and r1 are the inverses of each other) and since A and B are the domain and range of r1, it will be inferred from "y r1 x" that y is an instance of A and x is an instance of B even if the domain and range of r2 are not inferred.

We always have both "x r2 y" and "y r1 x" and if the domain and range of r2 are inferred, there are two ways of inferring that x is an instance of B: One using "y r1 x" and the range of r1 and the other using "x r2 y" and the domain of r2 but one of them is enough. This led to the off-topic talk about redundant computations (my apologies for that).

The thing I'm currently wondering about is that even if you turn off the domain and range inference checkboxes and run the following query in your example ontology (using Snap SPARQL) it shows that "Location" is the domain of "isLocationOf" (Is it still somehow inferred despite turning off the checkboxes?):

` PREFIX owl: \http://www.w3.org/2002/07/owl# PREFIX rdf: \http://www.w3.org/1999/02/22-rdf-syntax-ns# PREFIX rdfs: \http://www.w3.org/2000/01/rdf-schema# PREFIX : \http://www.semanticweb.org/mdebe/ontologies/2024/2/untitled-ontology-392/

SELECT ?p ?d WHERE { ?p rdf:type owl:ObjectProperty . ?p rdfs:domain ?d . FILTER (?d != owl:Thing ) } `

[mdebellis]

I see your point about the inverses.

Is it still somehow inferred despite turning off the checkboxes?

I'm not sure but probably. I've seen this before where I uncheck some box in the reasoning preferences but the reasoner does them anyway. The one I uncheck is reasoning about super properties for data properties. There are times that can be useful but other times when it results in a lot of useless redundant data. I've tried turning it off but many reasoners still infer it anyway. Pellet does. I actually wrote a SPARQL query to get rid of that data. It's not useful for Protege because I run the reasoner so often but it is useful when I use AllegroGraph or other triplestores where I don't run the reasoner as often and when I do it is usually as part of code so it is fairly easy to include the SPARQL query to clean up the extra data afterwards. If anyone is interested I have it in a Github repository where I store a bunch of generally useful SPARQL queries: Delete Super Property Values SPARQL file