Paradoxical SPARQL query?

Hello everyone!

Trying to understand the latest draft SPARQL specification,  I arrived
at the following query, which, as far as I can see, expresses a paradox:

        PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
        PREFIX foaf: <http://xmlns.com/foaf/0.1/>
        
        SELECT DISTINCT ?p ?n ?h
        WHERE { ?p rdf:type foaf:Person . 
                OPTIONAL {?p foaf:name ?n .
                          FILTER ( !bound(?h) ) }
                OPTIONAL {?p foaf:homepage ?h .
                          FILTER ( !bound(?n) ) }
        }

Suppose there are values P, N and H so that the triples

        P rdf:type foaf:Person
        P foaf:name N
        P foaf:homepage H

belong to the model. The question is whether ?p=P, ?n=N, ?h=H is
actually a solution for this query. Based on my (admittedly still quite
intuitive) interpretation of the specification, I think it is impossible
to answer the question. The problem is that as soon as you try to
bind ?n to N and ?h to H, the filter clauses become false, and cause
both optional patterns to not match. As soon as they don't match, the
variables aren't bound, which means the filters are true again, which in
turn would bind the variables.

I tested this query with both ARQ 1.3 and Redland (using the online demo
page at http://librdf.org/query) with http://www.dajobe.org/foaf.rdf as
input data. Both implementations produce different results. With ARQ
also, results are different depending on the order of the optional
subpatterns.

Since I'm new to the SPARQL specification, I realize that I may be
missing some important point that actually clarifies the meaning of
this, and similar, queries. I'd really appreciate people to point me to
any useful resources if I'm just missing the right information.

Thanks a lot,

M. S.
-- 
Martin Soto <Martin.Soto@iese.fraunhofer.de>
Fraunhofer Institute for Experimental Software Engineering (IESE)
Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
Tel. + 49 (0)631/6800-2214 - Fax + 49(0)631/6800-1099

Received on Tuesday, 23 May 2006 17:56:00 UTC