- From: Jeen Broekstra <jeen.broekstra@aduna.biz>
- Date: Wed, 09 Nov 2005 10:30:48 +0100
- To: Jagannathan Srinivasan <jagannathan.srinivasan@oracle.com>
- CC: public-rdf-dawg-comments@w3.org
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:alice@work.example> ; > 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
Received on Wednesday, 9 November 2005 09:31:25 UTC