Does this return same result in Protege ?
On Wednesday, November 27, 2013 at 2:08:06 PM UTC-5, Aaron Jackson wrote:
>
> Hi,
>
> Here is my basic issue:
>
> I am running TBC Free 4.3.1.v20131101-1317R.
>
> I have defined an ontology that describes Einstein's riddle (attached),
> which is solvable by strict DL reasoners (HermiT and Pellet) in Protege. I
> decided to test it out in RL with TopSPIN, importing the owlrl spin rules.
>
> It does not solve initially, so I decided to see what additional rules I
> should create to complete the inferenced solution.
>
> One rule I added was very similar to cls-maxqc3, except that it operates
> on "qualifiedCardinality" of 1 instead of "maxQualifiedCardinality". Here
> is the rule in SPARQL:
>
> CONSTRUCT {
> ?v1 owl:sameAs ?v2 .
> }
> WHERE {
> ?c owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger .
> ?c owl:onProperty ?p .
> ?c owl:onClass ?c2 .
> ?o a ?c .
> ?o ?p ?v1 .
> ?v1 a ?c2 .
> ?o ?p ?v2 .
> ?v2 a ?c2 .
> FILTER (?v1 != ?v2) .
> }
>
> Here's the interesting part:
>
> When I run the reasoner, it correctly infers a new statement, specifically
> that the individual "blue" is owl:sameAs the individual "second". This is
> based the fact the the individual "first" is a subclass of the anonymous
> "qualifiedCardinality" restriction defined above (on the property
> "nextTo"), which points to both "blue" and "second".
>
> So far so good.
>
> But when I execute the exact SPARQL of the rule in the SPARQL query view
> (against the fully realized graph), it returns nothing. I investigated
> this by querying for a bunch of individual relationships and found that
> while "FirstHouse" is correctly identified to be a subclass of the
> anonymous restriction, the individual "first" is not declared to be of the
> anonymous type. Thus the query fails at the "?o a ?c" pattern.
>
> At first it seemed like a possible failure of the cax-sco rule, but like I
> said, it works when executed by the reasoner.
>
> So what I'm wondering is whether TopSPIN may calculate certain "internal"
> triples that it uses to reason without "exporting" those triples to the
> resultant inferred graph. The reason it's an issue is that it makes it
> difficult to test rules/queries when the behavior is different depending on
> how the SPARQL is executed.
>
> Thank you!
>
--
You received this message because you are subscribed to the Google Group
"TopBraid Suite Users", the topics of which include Enterprise Vocabulary
Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live,
TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to topbraid-users@googlegroups.com
---
You received this message because you are subscribed to the Google Groups
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to topbraid-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
