Inconsistent query results under SLD, GMS and BFP

[GoogleCodeExporter]

The attached is intended as a first step toward in providing set of FuXi demos. 
 The thought is to provide command line demonstrations of simple queries 
against OWL-based ontologies and facts.  These will later be supplemented with 
demo programs, rule examples, etc.

While the attached inputs produce expected results under third party products, 
results vary under FuXi's different strategies.  

The file attached file, output.txt, reflects the results of the shell script 
Fuxi-bsa.command.   The queries ask who is a man and who is a person given a 
minimal set of facts, i.e., john is a man and jane is a woman.   The classes 
man and woman are subclasses of adult which in turn is a subclass of person--so 
we can infer john and jane are persons.  

Results under various strategies are as follows:
* SLD yields the expected answers to both queries.
* GMS does not report results in either case.
* BFP reports the expected result for who is a man; but aborts with the query 
about who is a person with the exception "TypeError: argument of type 
'NoneType' is not iterable."  

Perhaps the TypeError issue is the same BFP problem as alluded to in the last 
paragraph of Issue 44.

This is entered initially as a single, new, low priority report since the 
issues did not arise in a production environment and also because the single 
set of inputs provide grounds for comparison across strategies.  However there 
appear to be two distinct issues here  (1) missing results for GMS queries and 
(2) a NoneType is not iterable issue, which while mentioned in issue 44 is not 
the main concern of that report.

Original issue reported on code.google.com by onew...@gmail.com on 7 Feb 2011 at 4:45

Attachments:

• Fuxi-bsa.command
• bsa.ontology.n3
• bsa.individuals.n3
• output.txt

[GoogleCodeExporter]

BFP syntax bug fixed
The short of it is that using --why with queries such as 

SELECT ?x WHERE { ?x a ..any URI..  }

will not pass any information to the query engine.  I.e., there will not be any 
constants to pass on to other queries, rather than if the query had been posed 
this way:

ASK WHERE { test:john a test:person }

it would pass the following SPARQL solution:

?X -> test:john

from the (adorned) rule:

Forall ?X ( test:person_f(?X) :- test:adult(?X) )

and so on..

This means that, for example, if you run this with the BFP method using the 
above ASK question, the two following (mediated) queries will be dispatched 
against the bsa.individuals.n3 graph:

1. ASK {  test:john  a  test:woman } -> False
2. ASK {  test:john  a  test:man }-> True

It asks 1, due to the information being passed 'into' this rule from the 
previous one:

2. Forall ?X ( test:adult_b(?X) :- bsa:woman(?X) )

2 gives the answer it needs to conclude the answer and kill the forward 
chaining process:

So, in short the GMS method does not know how to do rule-based rewriting of 
SPARQL and just relies on information from the query to 'fix' the rules so they 
don't do any redundant work when used with the naive method.  Without such 
information it is no better than the naive method.  SLD and BFP , however (with 
the fix) will know how to re-write the SPARQL queries so they can answer the 
query even if no information is passed in.

Original comment by chime...@gmail.com on 2 Apr 2011 at 10:32

• Changed state: Started

[GoogleCodeExporter]

Original comment by chime...@gmail.com on 2 Apr 2011 at 10:35

• Changed state: Verified