Bug regarding property chains and incremental reasoning?

[Christian-D]

Hello everybody,

In context of my model I encountered a problem using propertychains in combination with incremental reasoning. My ontology contains the following property chain:

SubObjectPropertyOf(ObjectPropertyChain(:R_ProperInterval time:hasEnd ObjectInverseOf(timeEvents:equals) ObjectInverseOf(time:hasEnd) :R_ProperInterval) :hasSameEnd)

This basically states that two proper intervals (from the W3C time ontolgy [1], class membership is indicated using the object property R_ProperInterval) sharing the same end (using the equals property from [2] to compare dateTime values) get connected by the object property hasSameEnd. 

When loading the model for the first time using the OWL-API and pellet, the axioms for the property hasSameEnd are inferred correctly when realizing the knowledgebase. However, during this reasoning process the individuals affected by this property chain within the abox of the pellet knowledge base get types like this:

all([http://www.w3.org/2006/time#hasEnd,inv(http://www.intelligence.tuc.gr/2011/timeEvents#equals),inv(http://www.w3.org/2006/time#hasEnd),http://www.semanticweb.org/ontologies/2014/2/untitled-ontology-167#R_ProperInterval],not(value(http://www.semanticweb.org/ontologies/2014/2/untitled-ontology-167#SomeInterval)))

Now when the allValues types of the individuals are checked at a later stage during the same runtime, they lead to errors as their role is of ATermList and not of type ATermAppl:

Exception in thread "main" java.lang.ClassCastException: aterm.pure.ATermListImpl cannot be cast to aterm.ATermAppl

at com.clarkparsia.pellet.expressivity.DLExpressivityChecker$Visitor.visitAll(DLExpressivityChecker.java:202)

at org.mindswap.pellet.output.ATermBaseVisitor.visit(ATermBaseVisitor.java:79)

at com.clarkparsia.pellet.expressivity.DLExpressivityChecker.processIndividuals(DLExpressivityChecker.java:86)

at com.clarkparsia.pellet.expressivity.DLExpressivityChecker.compute(DLExpressivityChecker.java:58)

at com.clarkparsia.pellet.expressivity.ExpressivityChecker.prepare(ExpressivityChecker.java:56)

at org.mindswap.pellet.KnowledgeBase.prepare(KnowledgeBase.java:1820)

at org.mindswap.pellet.KnowledgeBase.consistency(KnowledgeBase.java:1969)

at org.mindswap.pellet.KnowledgeBase.isConsistent(KnowledgeBase.java:2061)

at org.mindswap.pellet.KnowledgeBase.ensureConsistency(KnowledgeBase.java:2075)

at org.mindswap.pellet.KnowledgeBase.classify(KnowledgeBase.java:2083)

at org.mindswap.pellet.KnowledgeBase.realize(KnowledgeBase.java:2111)

at org.mindswap.pellet.KnowledgeBase.getTypes(KnowledgeBase.java:3336)

at com.clarkparsia.pellet.owlapiv3.PelletReasoner.getTypes(PelletReasoner.java:820)

This error can also be experienced in the Protege 4.3 editor using either the incremental mode of pellet or the "synchronize reasoner" option after changing something in the model. The only way around this issue at the moment is to manually call PelletReasoner.refresh() each time when changing the ontology.

I was able to track down the cause for this issue to the "applyAllValuesPropertyChain" function (see the callstack below). 

Individual.addType(ATermAppl, DependencySet, boolean) line: 226

Individual.addType(ATermAppl, DependencySet) line: 222

ContinuousRulesStrategy(CompletionStrategy).addType(Node, ATermAppl, DependencySet) line: 438

ContinuousRulesStrategy.addType(Node, ATermAppl, DependencySet) line: 95

AllValuesRule.applyAllValues(Individual, Role, Node, ATermAppl, DependencySet) line: 175

AllValuesRule.applyAllValuesPropertyChain(Individual, ATermList, ATermAppl, DependencySet) line: 154

AllValuesRule.applyAllValues(Individual, ATermAppl, DependencySet) line: 130

ContinuousRulesStrategy(CompletionStrategy).addType(Node, ATermAppl, DependencySet) line: 469

ContinuousRulesStrategy.addType(Node, ATermAppl, DependencySet) line: 95

RuleAtomAsserter.addEdge(ATermAppl, ATermAppl, ATermAppl) line: 102

RuleAtomAsserter.visit(IndividualPropertyAtom) line: 135

IndividualPropertyAtom.accept(RuleAtomVisitor) line: 37

RuleAtomAsserter.assertAtom(RuleAtom, VariableBinding, DependencySet, boolean, ABox, CompletionStrategy) line: 73

RuleBranch.tryBranch() line: 149

RuleBranch(Branch).tryNext() line: 117

ContinuousRulesStrategy.createDisjunctionsFromBinding(VariableBinding, Rule, DependencySet) line: 433

ContinuousRulesStrategy.applyRuleBindings() line: 224

ContinuousRulesStrategy.complete(Expressivity) line: 331

ABox.isConsistent(Collection<ATermAppl>, ATermAppl, boolean) line: 1423

ABox.isConsistent() line: 1260

KnowledgeBase.consistency() line: 1987

KnowledgeBase.isConsistent() line: 2061

KnowledgeBase.ensureConsistency() line: 2075

KnowledgeBase.classify() line: 2083

KnowledgeBase.realize() line: 2111

The type added to the individual is constructed calling 

ATermUtils.makeAllValues( chain.getNext(), c ); 

As the ATermList representing the property chain has a length greater than 1, the first argument of the function application remains of type ATermList. However only arguments of type ATermAppl are valid in context of DLExpressivityChecker.java:202. 

Is if this is a known issue? In the archives [3] I found a related report but unfortunately no feedback. It would be very valuable for me to take advantage of incremental reasoning in the application I am building on top of my model.As I am normally not modifying the internals of pellet, feedback on the correctness of my analysis and hints regarding options to fix this would be very helpful. Depending on the schedule for bugfixes and maintenance for pellet version 2.3 I consider a local fix, which maybe can be incorporated at a later stage. I guess the focus at C&P is currently on Stardog/Pellet3 (please correct me if I am wrong)? 

Any feedback would be greatly appreciated. If further information is required, please ask for it. Thank you for your efforts.

Greetings,

Christian

[1] http://www.w3.org/TR/owl-time/

[2] Σ. Μπατσάκης, “SOWL: a framework for handling spatio-temporal information in OWL,” 2011.

[3] http://comments.gmane.org/gmane.comp.web.pellet.user/5370

[Evren Sirin]

Not exactly.

> In the archives [3] I found a related report
> but unfortunately no feedback. It would be very valuable for me to take
> advantage of incremental reasoning in the application I am building on top
> of my model.

How are you using the incremental reasoning feature? Is it possible to
put together a minimal example that triggers this exception?

> As I am normally not modifying the internals of pellet, feedback
> on the correctness of my analysis and hints regarding options to fix this
> would be very helpful. Depending on the schedule for bugfixes and
> maintenance for pellet version 2.3 I consider a local fix, which maybe can
> be incorporated at a later stage. I guess the focus at C&P is currently on
> Stardog/Pellet3 (please correct me if I am wrong)?

You are right. Our focus is on Stardog and we don't have too many free
cycles for Pellet2 but we are still using it in several projects and
maintaining the code. We don't have a schedule for a new 2.3 release
we'd like to fix bugs as much as possible. Having a minimal example
that can be used as a unit test helps a lot since many times it takes
longer to create test cases for bugs than fixing the bug itself.

Best,
Evren

>
> Any feedback would be greatly appreciated. If further information is
> required, please ask for it. Thank you for your efforts.
>
> Greetings,
> Christian
>
>
> [1] http://www.w3.org/TR/owl-time/
> [2] Σ. Μπατσάκης, “SOWL: a framework for handling spatio-temporal
> information in OWL,” 2011.
> [3] http://comments.gmane.org/gmane.comp.web.pellet.user/5370
>

> --
> You received this message because you are subscribed to the Google Groups
> "Pellet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pellet-users...@googlegroups.com.
> To post to this group, send email to pellet...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pellet-users/392be3e5-43d3-4f5a-86c2-24b8607580b4%40googlegroups.com.

[Christian-D]

Hello Evren,

please find attached the minimal example you requested. The problem now seems to relate to the combined use of swrl rules and property chains. In the model attached there is one rule left which references property chains with more than two elements. This leads to the construction of an AllValuesRule which has an argument of type ATermList instead of ATermAppl. AllValuesRule.applyAllValuesPropertyChain calls ATermUtils.makeAllValues, which in turn constructs the probematic term. When reasoning for the second time, DLExpressivityChecker visits the term which leads to the exception. 

My initial model and testcase were much more complex so I suspected the incremental reasoning to be the problem. Now it seems more likely the error results from the handling of property chains used in swrl rules with length > 2 during the construction of terms. I use the non-buffering reasoner in the testcase but the error can also be reproduced with the buffering reasoner.

Any suggestions are greatly appreciated. Thank you very much for your efforts.

Greetings

Christian