Problem with Pellet reasoner and restrictions

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with Pellet reasoner and restrictions

mareikep@cs.uni-bremen.de
Hello everyone,
I have a weird error with the Pellet reasoner. I created a super class and a couple of sub classes using equivalent_to and some functional data properties which I use to restrict the sub classes, to represent some sort of categorization.
The setting looks similar to this, but contains a couple more properties and sub classes:

with onto:
    prop_x = types.new_class('prop_x', (DataProperty, FunctionalProperty))
    prop_y = ...

    class MySuperClass(Thing):
        namespace=onto

    class SubClassA(MySuperClass):
        equivalent_to = [prop_x.some(ConstrainedDatatype(float, max_inclusive=0.5) & prop_y.some(ConstrainedDatatype(float, min_inclusive=0.0, max_inclusive=13.0) ]

I read data from a csv file to generate instances for the respective classes, which works like a charm. The Pellet reasoner works nicely, everything is fine so far. Now when I change something in the data (or add another ConstrainedDatatype to the restriction)), it may happen, that the Pellet reasoner crashes for no apparent reason. Inspecting the log I get the information that there seems to be a problem with my restriction. The message is similar to this one:
Exception in thread "main" org.mindswap.pellet.exceptions.InternalReasonerException: Adding type to a pruned node "anon(1327)" not(restrictedDatatype(http://www.w3.org/2001/XMLSchema#decimal,[facet(<a href="http://www.w3.org/2001/XMLSchema#minInclusive,literal(0.0,(),http://www.w3.org/2001/XMLSchema#decimal)),facet(http://www.w3.org/2001/XMLSchema#maxInclusive,literal(13.0,(),http://www.w3.org/2001/XMLSchema#decimal">http://www.w3.org/2001/XMLSchema#minInclusive,literal(0.0,(),http://www.w3.org/2001/XMLSchema#decimal)),facet(http://www.w3.org/2001/XMLSchema#maxInclusive,literal(13.0,(),http://www.w3.org/2001/XMLSchema#decimal))]))

The funny thing is, when I now change the 13.0 to 13 in the ConstrainedDatatype (i.e. I change the value from float to int, but WITHOUT changing the base_datatype of the ConstrainedDatatype), the error disappears. I have no explanation for this behavior as there is no apparent reason why this particular value cannot be a float but all the others can, so I expect the problem to be somewhere else. In particular because the error may also re-appear with a class/restriction setting the reasoner was happy with before but with different data for the individuals (in one case the setting worked but failed when I changed the names of the Individuals but nothing else, which should not make any difference..).

Can anyone tell me if there is something problematic with my (schematic) code? Or what kind of Individual could cause my setting to break?
I suspected my restrictions to be somehow unfulfillable but I can't find a problem with it.

Any ideas will be appreciated,

-Mareike
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Pellet reasoner and restrictions

Jiba
Administrator
Hi,

I tried the example below, but it works as expected. Could you give me a small example that I can use to reproduce your problem?

Thanks,
Jiba


---8<----------

from owlready2 import *

onto = get_ontology("http://test.org/t2.owl")

with onto:
    prop_x = types.new_class('prop_x', (DataProperty, FunctionalProperty))
    prop_y = types.new_class('prop_y', (DataProperty, FunctionalProperty))
   
    class MySuperClass(Thing):
        pass
       
    class SubClassA(MySuperClass):
        equivalent_to = [
          prop_x.some(ConstrainedDatatype(float, max_inclusive=0.5))
        & prop_y.some(ConstrainedDatatype(float, min_inclusive=0.0, max_inclusive=13.0)) ]

    MySuperClass(prop_x =0.2, prop_y = 3.0)
                                     
sync_reasoner_pellet()

# => * Owlready * Reparenting t2.mysuperclass1: {t2.MySuperClass} => {t2.SubClassA}
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Pellet reasoner and restrictions

Mareike
Hey, thank you for having a look. The problem only occurs with a certain size of the ontology and it seems to be not deterministic. In particular, running the same inference over and over again sometimes throws a warning but infers anyway, OR it throws the same warning as an error and breaks OR it is happy and infers as requested. There is also to mention that running the pellet reasoner using owlready2 is much more sensitive than running it using protege. I am running protege 5.5.0 with the Pellet plugin version 2.2.0, and owlready2 version 0.2.2. Not sure which Pellet version that is? I just uploaded an example that sometimes works and sometimes doesn't, hoping that you can reproduce the error. You can download it here:
https://spritinio.de/nextcloud/index.php/s/AfTyoMiyJCxYxTP

Thanks!
Mareike
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Pellet reasoner and restrictions UPDATE

Mareike
In reply to this post by Jiba
Hey,
After a hint from a colleague who was wondering about the pruned nodes to be anon(x) and therefore suspected a naming problem, I renamed all classes and individuals to not contain underscores anymore (replaced them by dashes or removed them to use CamelCase) and that seemed to have helped. Is it possible that the class/instance names I used clashed with internal naming conventions in the Pellet reasoner? Even though that does not really make sense and should not happen, my problem seems to be solved (for now). The reasoner is now happy even though I made the ontology a bit bigger and more complex..

Thanks,
Mareike