Not sure about the expected behaviour of OWLReasoner::getEquivalentObjectProperties

[Galigator]

In a case like "https://stackoverflow.com/questions/44788355/remove-object-property-axiom-using-a-reasoner" I am not sure what is the good behaviour for the method "getEquivalentObjectProperties"

when there is a set of axiom like :

        OWLObjectProperty r = factory.getOWLObjectProperty("R");
        OWLObjectProperty inverseR = factory.getOWLObjectProperty("inverseR");
        manager.addAxiom(ontology, factory.getOWLInverseObjectPropertiesAxiom(r, inverseR));

Does the call 'getEquivalentObjectProperties(<inverseR>)' must :
case 1) return '<inverseR>' and 'OWLObjectInverseOf(<R>)'
case 2) return only '<inverseR>' ?

I have show the documentation to a native english speaker and he don't have provide me a real answer.

This point look important because Pellet behave differently than Hermit/Fact++ on this case.
If the case 1 is correct, the simplest way to change it in Pellet the best way could be to make it as a parameter(for the reasoner) to avoid breaking compatibility(then change the tests that enforce the case 2).

[ignazio1977]

I'm not sure myself. The interface methods allow for expressions to be returned, and the javadoc says simplified properties, meaning inverseOf<inverseOf> is R, and so on, but it leaves the question of whether inverseOf should be returned a bit undetermined - when compared, for example, to subclasses and superclasses.

From the question on StackOverflow, I gather both JFact and HermiT assume the inverse should be returned; FaCT++ probably does the same (usually, if FaCT++ does it, JFact does it too - if a bit slower :-)); they were implemented independently, so it sounds like different developers interpreted the interface definition the same way. I would vote for Openllet to do the same.

[Galigator]

Thx Ignazio. The 2.6.2 of Openllet have now the same expected behaviour has Hemit / FaCT++.

[ykazakov]

Sorry for commenting after the issue is closed, but I wanted to clarify the documentation.

As I understood @ignazio1977 suggests that the method getEquivalentObjectProperties does not have to return all (simplified) equivalent object property expressions. This is probably done to account for incomplete reasoners, such as StructuralReasoner. For example, as per documentation, it should be OK to return the empty set in this case. But then what about the part saying that in case the object property is equivalent to top / bottom the reasoner should return the top / bottom node? Does it mean that the reasoner should be complete at least for checking equivalence to top / bottom? Does StructuralReasoner fulfils this contract? I would be interested in clarifying / fixing documentation for these cases.