ICA-EGAD / RiC-O

ICA Records in Contexts-Ontology (ICA RiC-O) GitHub repository web pages
https://ica-egad.github.io/RiC-O/
51 stars 16 forks source link

Inconsistent ontology according to Pellet and HermiT #111

Closed LuciaGiagnolini12 closed 3 months ago

LuciaGiagnolini12 commented 5 months ago

I kindly point out that the ontology (downloaded in its latest version and not modified) is inconsistent according to Protégé's reasoners Pellet and KermiT. Pellet, in particular, reports this error: ERROR 15:39:53 An error occurred during reasoning: Unable to execute reasoning with inconsistent ontologies! Reason for inconsistency: There is an anonymous individual X, identified by this path (https://www.ica.org/standards/RiC/ontology#recordResourceHoldingRelation_role X), who is forced to belong to the class https://www.ica.org/standards/RiC/ontology#Appellation and its complement. org.mindswap.pellet.exceptions.InconsistentOntologyException:

williamsonrichard commented 5 months ago

Thank you very much for raising this! I believe that the fundamental reason for the inconsistency is the fact that the object properties involved in rollification, such as rico:positionToGroupRelation_role, are declared to be reflexive. To spell out in detail how this inconsistency arises, or at least one way in which it does:

  1. Reflexivity asserts that everything is related to itself by rico:positionToGroupRelation_role (the bug probably arose because it was thought that assertion of reflexivity of an object property would be restricted to its domain, which, somewhat strangely (though perhaps there is some reason for it), is not the case).
  2. Similarly, due to the reflexivity of rioc:groupSubdivisionRelation_role, everything is related to itself by this property.
  3. The domain of rico:positionToGroupRelation_role is rico:PositionToGroupRelation.
  4. We have that rico:PositionToGroupRelation is a subclass of the restriction class rico:relationHasSource min 1 rico:Position.
  5. The domain of rico:groupSubdivisionRelation_role is rico:GroupSubdivisionRelation.
  6. We have that rico:GroupSubdivisionRelation is a subclass of the restriction class rico:relationHasSource exactly 1 rico:Group.
  7. Let X be an individual whatsoever. It follows from 1., 3., and 4. that there must be an individual Y of type rico:Position for which we have X rico:relationHasSource Y.
  8. By 2., 5., and 6., we must in addition have that Y is of type rico:Group.
  9. But the fact that Y both is of type rico:Position and of type rico:Group is a contradiction of the fact that these classes are asserted to be disjoint (see rico:Group).

[PS: if anyone read this shortly after I posted it initially, I have edited it a little since from here onwards; it took a few attempts, ending up back with what I initially posted (!), but I think/hope it is now correct!]

I believe that this can be fixed by removing the reflexivity assertions for all of the _role classes, and instead doing as follows.

Class: rico:PositionToGroupRelation
  EquivalentTo: 
    rico:positionToGroupRelation_role some Self,
    rico:positionToGroupRelation_role some owl:Thing

Indeed, what is intended is that every individual of type rico:PositionToGroupRelation is related by rico:positionToGroupRelation_role to itself, and that this is the only way to use rico:positionToGroupRelation_role. I think that the equivalence to the restriction class defined by the 'some Self' line above (here 'some Self' is 'self-restriction') achieves the first of these and in addition achieves that no other individual can be related to itself by rico:positionToGroupRelation_role; this line is already in the ontology. The new second line involving 'owl:Thing', specifically the equivalence between the restriction class defined by this line and the restriction class defined by the 'some Self' line, ensures that any use of rico:positionToGroupRelation_role must in fact be a self-restriction.

I can carry out this fix (if it is correct, I have not run a consistency checker on it yet), but @florenceclavaud is on her summer holiday at the moment, and we should wait for her to return to run this by her and see if she agrees with the fix or has a different suggestion. I could also try to add a github action which carries out a consistency check.

In the meantime, if you or somebody else would like to run consistency checks and need a fix, it would hopefully not be very much work to remove the reflexivity assertions everywhere. There is also a pattern of use of RiC-O which stretches quite far which does not use the relation classes, and if this pattern is enough for you, you could simply remove everything pertaining to relation classes.

Thanks again for bringing this up!

florenceclavaud commented 4 months ago

Hi @LuciaGiagnolini12, thank you for raising this! and @williamsonrichard, thank you also for working on this.

Yes you are right, the problem certainly comes from the 48 occurrences of the following line that concern the 48 *role object properties:

<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ReflexiveProperty"/>

as in fact OWL does not directly support local reflexivity (a reflexive property has domain owl:Thing and this cannot be restricted). I generated those lines systematically when I rolified the relations, in addition to a lot of other features; and I should not have done so!

So those lines should be removed. And, in the end, I also think you are right about thinking of adding the second restriction line to the definition of each of the 48 classes.

I would like to test this by myself also, before we do anything: this can be fixed easily as you said, but it would affect 48 properties and 48 Relation classes.

williamsonrichard commented 4 months ago

Sounds great! Just let me know if you'd like me at some point to prepare a PR; of course, completely fine too if you prefer to implement a fix yourself :-).

It is very understandable that you added reflexivity; I do not really understand why it is global in OWL, the natural thing as far as I see would be for it to be local, in which case it would have been the best (simplest, easiest to understand) way to achieve the desired properties!

florenceclavaud commented 4 months ago

Hi @williamsonrichard, yes you could create a branch (please use the new next-version as the source branch) and prepare a PR for the main OWL file. Then if you agree, I will review what you have done, and also regenerate the HTML documentation, CSV lists and modularized version from the file.

florenceclavaud commented 4 months ago

I have done some tests with Pellet and HermiT (as Protege plugins) after removing all the reflexive property axioms. This fixes the bug; the reasoners do not find any issue. So I think we should definitely go this way. We also have to update 3 images in this page: https://ica-egad.github.io/RiC-O/migrating-data-from-RIC-O-v0.2-to-v1.0.html. Also tested the property chain axiom using a RL reasoner, the fixed ontology and some test individuals. Just like before, the RL reasoner does not infer the shortcut unless the instance of the Relation is explicitly connected to itself by the _role property. OWL RL does support neither reflexive properties nor hasSelf, so this is normal. See also this email on this.

williamsonrichard commented 4 months ago

@florenceclavaud Nice! I have made a pull request with the removal of global reflexivity now. I have tested that in fact my suggestion of adding an equivalence of PositionToGroupRelation to

 rico:positionToGroupRelation_role some owl:Thing

and similarly in all the other cases doesn't seem to add anything significant, so I have omitted it, and literally only removed global reflexivity along with a change note. Indeed, local reflexivity is already in place; adding an additional equivalence of classes as above is maybe semantically justifiable for the reason I outlined in an earlier comment, but in practice a reasoner would even in principle only be able to use it to derive a contradiction from

A rico:positionToGroupRelation_role B

under strong assumptions that go rather against the open-world perspective (e.g. if one ensured that PositionToGroupRelation was equivalent to a finite disjoint union of individuals), and I'm not completely sure that it would actually manage it then either. Thus I think it is better to keep things as simple as possible and just omit the extra equivalence, as local reflexivity is really the important thing; a bit of extra 'fluff' doesn't really matter!

florenceclavaud commented 3 months ago

Hi @williamsonrichard, thank you very much! I agree with you, removing the global reflexivity is enough and we should keep RiC-O as simple as possible. I will review this ASAP.

florenceclavaud commented 3 months ago

Closed as completed with PR #115