Re: Comments on 2.6 "Multiple Matches" (CR 6 Apr 2006)

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