Re: Comments on SPARQL: Querying the Dataset [OK?]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Comments on SPARQL: Querying the Dataset [OK?]

Jeen Broekstra-2

Jagannathan Srinivasan wrote:

> I have a question regarding section 8.3 Restricting by Bound Variables:
>
> Is the specification in WHERE clause order-independent? Specifically,
> can I reverse the
> order (as shown below as compared to the example in the document ) and
> still get the same result?
>
> PREFIX  data:  <http://example.org/foaf/>
> PREFIX  foaf:  <http://xmlns.com/foaf/0.1/>
> PREFIX  rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX
> rdfs:  <http://www.w3.org/2000/01/rdf-schema#>
>
> SELECT ?mbox ?nick ?ppd
> WHERE
> {
>  GRAPH ?ppd
>  {
>      ?w foaf:mbox ?mbox ;
>         foaf:nick ?nick  } .
>  GRAPH data:aliceFoaf
>  {
>    ?alice foaf:mbox <mailto:[hidden email]> ;
>           foaf:knows ?whom .
>    ?whom  foaf:mbox ?mbox ;
>           rdfs:seeAlso ?ppd .
>    ?ppd  a foaf:PersonalProfileDocument .
>  } }

First of all, sorry it has taken so long to get back to you. Yes, indeed
you can switch the clauses around without changing the semantics of the
query. You will still get the same result.

Although this is not explicitly mentioned in section 8.3, it follows
from the definitions of how dataset graph pattern matching works.

Section 7 formally specifies the notion of an RDF Dataset and an RDF
Dataset graph pattern (see [1]):

  "Definition: RDF Dataset Graph Pattern

   If D is a dataset {G, (<u1>, G1), ...}, and P is a graph pattern then
   S is a pattern solution of GRAPH(g, P) if either of:

   1. g is an IRI where g = <ui> for some i, and S is pattern solution
      of P on dataset {Gi, (<u1>, G1), ...}
   2. g is a variable, S maps the variable g to <ui> and S is a pattern
      solution of P on {Gi, (<u1>, G1), ...}"

The above two cases cover the examples of Dataset querying given in
sections 8.2 and 8.1, respectively.

The graph pattern in the query in section 8.3 is an example of a group
graph pattern (see [2]), consisting of two separate dataset graph
patterns. As we can see in [2], the definition of a group graph pattern
is such that a solution of the pattern must satisfy all the members of
the group. Notice also that the definition talks about a *set* of
patterns, in other words, the members are not ordered.

I'll attempt to illustrate this. In the specific example of section 8.3,
the first GRAPH clause restricts its set of solutions to the
data:aliceFoaf graph (cf. the definition above, case 1) . It binds the
?ppd variable to a value only if that value is part of a basic
graph pattern match in the data:aliceFoaf named graph (cf. section 2.4).
In the example, the only match found for ?ppd is data:bobFoaf. The
second clause then accesses the named graph data:bobFoaf (cf. the
definition above, case 1 again) and retrieves a set of bindings within
that graph. Any solution of the group pattern and hence the query
solution will thus have ?ppd bound to data:bobFoaf.

If we switch the evaluation order of the dataset graph patterns around,
the (now) first clause is a GRAPH clause as defined in the definition
above, case 2. In the example, ?ppd can be mapped to both data:aliceFoaf
and data:bobFoaf, and since both graphs match the basic graph pattern of
the clause, both of these mappings satisfy the first member of the group
pattern.

However, the (now) second member of the group pattern still restricts
its set of solutions to a single named graph. In other words: still only
those bindings for ?ppd that appear as valid bindings in the
data:aliceFoaf named graph will be part of a query solution. In the
example, the data:aliceFoaf graph only mentions a rdfs:seeAlso that
points to data:bobFoaf, hence this restricts a valid query solution to
only contain data:bobFoaf as a valid binding for ?ppd.

Does this satisfy you that the current design indeed specifies
order-independence wrt. dataset graph patterns?

Regards,

Jeen

[1] http://www.w3.org/2001/sw/DataAccess/rq23/#defn_DataSetGraphPattern
[2] http://www.w3.org/2001/sw/DataAccess/rq23/#defn_GroupGraphPattern
--
Jeen Broekstra          Aduna BV
Knowledge Engineer      Julianaplein 14b, 3817 CS Amersfoort
http://aduna.biz        The Netherlands
tel. +31 33 46599877