From: Seaborne, Andy <andy.seaborne@hp.com>

Date: Mon, 24 Jul 2006 10:03:59 +0100

Message-ID: <44C48CFF.6090600@hp.com>

To: Fred Zemke <fred.zemke@oracle.com>

CC: public-rdf-dawg@w3.org

Date: Mon, 24 Jul 2006 10:03:59 +0100

Message-ID: <44C48CFF.6090600@hp.com>

To: Fred Zemke <fred.zemke@oracle.com>

CC: public-rdf-dawg@w3.org

Fred Zemke wrote: > > > > 2.6 Multiple matches > First sentence: "The results of a query is the set of all pattern > solutions that match the query pattern, giving all the ways a query > can match the graph queried." But sets eliminate duplicates, > and we have the DISTINCT operator as an optional syntactic choice > about whether to eliminate duplicates. Instead, this should say > that the result of a query is a sequence of solutions. See > section 10.1 "Solution sequences and result forms". rq24 : "2.2 Multiple Matches" """ The results of a query is a sequence of solutions, giving the ways in which the query pattern matches the data. The sequence of solutions is further modified by the solution sequence modifiers. There may be zero, one or multiple solutions to a query. """ > > > 2.6 Multiple matches > The semantics of the empty graph pattern has not been defined. > I think the following queries are instructive: > > a) SELECT ?a > FROM graph > WHERE { } > > b) SELECT ?a ?b > FROM graph > WHERE { } > > c) SELECT ?a ?b > FROM graph > WHERE { ?a foaf:verb foaf:noun } > > d) SELECT ?a ?b > FROM graph > WHERE { ?a foaf:verb foaf:noun . > OPTIONAL { ?a foaf:verb2 ?b } } Variables need not be bound in any given solution - and may be bound in some solutions and not others. Added (rq24) "4.2 Empty Group Pattern" > > One's initial impulse is that query a) should result in the set of > all mappings of { ?a } to the scoping set (not the set of all > total mappings of V to the scoping set; see related comment). > Or equivalently, the user might view the result as an enumeration > of the scoping set of the graph. A solution is the requirements for a match. Suggestions for how to say that, in a way that does not mandate the logical reduction of the solution set over the data (too expensive as per a previous discussion), welcome. Something about required terms is noted as needed to be done (an @@ in the doc) - and it would nicely allow different capabilities for different engine and level of entailment. owl:sameAs could be exposed. Andy > > Then query b) would result in the set of all mappings of { ?a, ?b } > to the scoping set, or, naively, the cross product of the scoping > set with itself. > > However, I believe that c) and d) should result in a subset of the > result of b). Now in the case of d) in particular, OPTIONAL is > intended to allow for a result which is a partial binding, ie, one > that binds ?a but does not bind ?b. If it happens that there is > no binding for ?b, then the result would not be a subset of the > cross product of the scoping set with itself. > > My conclusion is that in order to support OPTIONAL and UNION, we > have to permit a result that is a partial mapping. > > Coming back to query b), in order for it to contain query d) as a > subset, the result of b) must be all partial functions from {?a, ?b} > to the scoping set. Alterantively, a naive view might > imagine augmenting the scoping set with a single "missing" element, > distinct from all other elements, in which case the result of b) > is the cross product of the augmented scoping set. > > And as for a), it seems the result must be the set of all partial > functions of { ?a } to the scoping set, or equivalently, an > enumeration of the augmented scoping set. > > As a different approach to this issue, consider these two queries: > > a1) SELECT ?a > FROM graph > WHERE { BOUND (?a) } > > a2) SELECT ?a > FROM graph > WHERE { !BOUND (?a) } > > I believe the following things: > -- the result of a) should be the union of the result of a1) and a2) > -- the result of a1 should be an enumeration of the scoping set, > -- the result of a2 should be a single solution, in which ?a is > not bound. > > Fred >Received on Monday, 24 July 2006 09:04:43 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:00:51 UTC
*