Re: OPTIONALs and shared variables

On Wed, Jun 14, 2006 at 05:58:29PM +0200, Eric Prud'hommeaux wrote:
> On Tue, Jun 13, 2006 at 11:12:28AM -0400, Jorge Adrián Pérez Rojas wrote:
> > Eric Prud'hommeaux wrote:
> > > On Mon, Jun 12, 2006 at 05:52:52PM -0400, Jorge Pérez wrote:
> > >> Hi Eric,
> > >>
> > >> I've been following the development of SPARQL for a couple of months and
> > >> I've a comment about your last mail on public-rdf-dawg (I've no access
> > >> to
> > >> this list so I'm writing only to you).
> > >>
> > >> You say that a query like
> > >>
> > >> ...
> > >> WHERE {
> > >>    ?a dc10:title "thing" .
> > >>    OPTIONAL { ?a dc10:creator ?name }
> > >>    ?a cc:license ?license .
> > >>    OPTIONAL { ?a dc11:creator ?c .
> > >>               ?c rdf:value ?name }
> > >> }
> > >>
> > >> must be evaluated as two patterns with OPTIONALs in them. What I
> > >> understand from what yo say is that we have a group graph pattern with
> > >> two
> > >> OPTIONAL patterns inside:
> > >>
> > >>    ?a dc10:title "thing" .
> > >>    OPTIONAL { ?a dc10:creator ?name }
> > >>
> > >> and
> > >>
> > >>    ?a cc:license ?license .
> > >>    OPTIONAL { ?a dc11:creator ?c .
> > >>               ?c rdf:value ?name }
> > >>
> > >> is that correct? If this is the case the spec says that the solutions
> > >> are
> > >> the ones that are solution simultaneously to both patterns,
> > >
> > > I disagree with the "simultaneously" part. That is, I think the "any" in
> > > [[
> > > There is no implied order of graph patterns within a Group Graph
> > > Pattern. Any solution for the group graph pattern that can satisfy all
> > > the graph patterns in the group is valid, independently of the order
> > > that may be implied by the lexical order of the graph patterns in the
> > > group.
> > > ]]
> > > means that it's a union of all of the possible interpretations.
> > 
> > Im ok with the *any* part, but the *simultaneously* part in my argument
> > refeer to the **all** part in
> > [[
> > There is no implied order of graph patterns within a Group Graph
> > Pattern. Any solution for the group graph pattern that can satisfy **all**
> > the graph patterns in the group is valid, independently of the order
> > that may be implied by the lexical order of the graph patterns in the
> > group.
> > ]]
> > 
> > so, from my point of view, the mapping
> > 
> > |    ?name     |  ?c   |
> > +--------------+-------+
> > | "John Smith" |       |
> > 
> > is not a solution because it do not satisfy **all** the graph patterns in
> > the group (it do not satisfy the second OPTIONAL graph patter in the
> > group).

AndyS made me look at this and I must confess that I am unable to come
up with an example that illustrates your point. At issue is whether
the following binds match the above query:
  | ?a |    ?name     |  ?c   |
  +----+--------------+-------+
  | :a | "John Smith" |       |
I believe that it matches both 
  OPTIONAL { ?a dc11:creator ?c .
             ?c rdf:value ?name }
and
  OPTIONAL { ?a dc10:creator ?name }
by your rules; the former because the first one is optional, and the
later simply because it matches.

We can do the same exercise to prove that
  | ?a |    ?name     |  ?c   |
  +----+--------------+-------+
  | :a | "Joe Bloggs" | _:jb  |
matches all of the constraints. If we take the pattern in order:
  ?a dc10:title "thing" .
  OPTIONAL { ?a dc10:creator ?name }
  ?a cc:license ?license .
  OPTIONAL { ?a dc11:creator ?c .
             ?c rdf:value ?name }
We see that OPTIONAL { ?a dc10:creator ?name } doesn't match, but it's
optional. It does match the next OPTIONAL, which in effect, justifies
the bindings of ?name and ?c.

The problem with this restrictionist logic is that there is an infinte
set of things like
  | ?a |    ?name      |  ?c  |   ?foo   |         ?bar             |
  +----+---------------+------+----------+--------------------------+
  | :a | "Joe Bloggs"  | _:jb | "Hi mom" | "I'd rather be sailing"  |
  | :a | "Mr Contrary" | _:jb | "Hi dad" | "I'd rather be drinking" |

that match. The latter is particularly interesting as it looks like
a solution as it binds variables that are mentioned in the query (in
OPITONALs). I assume that our crack team of logicians has an answer
to this. I'm not smart enough to read the 2.4 Pattern Solutions and
convince myself that we've ruled out either of those fallacious
solutions.


> Interesting. That's certainly a valid interpretation of "all". My
> interpretation had been that a solution satisfies all of the
> constraints when evaluated in any given order. Yours appears to be  <-+
> that a solutions satisfies all the constrains when evaluated in all   |
> possible orders.                                                      |
>                                                                       |
> There are some folks who are working on clarifying the formal         |
> semantics right now; I'll ask them to look at this.  Hey AndyS, PatH, |
> FredZ, look at this:--------------------------------------------------+
> 
> > Acording to your argument the query
> > 
> > SELECT ?name
> > WHERE
> > {
> >   { ?a dc10:creator ?name }.
> >   { ?b rdf:value ?name }
> > }
> > 
> > will also be a union of all of the possible interpretations, and then will
> > have as solution the mappings
> > 
> > |    ?name     |
> > +--------------+
> > | "John Smith" |
> > | "Joe Bloggs" |
> > 
> > is that correct?
> > If the **all** is changed for **any of** in the spec I would read the spec
> > in the same way as you do.
> > 
> > I understand the center of your argument now, thanks for the clarification.
> > 
> > - jorge
> > 
> > >
> > >>                                                             so I think
> > >> the
> > >> above query agaisnt the following data
> > >>
> > >>   :a dc10:title "thing" .
> > >>   :a dc10:creator "John Smith" .
> > >>   :a cc:license "steal this book"
> > >>   :a dc:11:creator _:jb .
> > >>   _:jb rdf:value "Joe Bloggs" .
> > >>
> > >> has empty solution. For example, the mapping
> > >>
> > >> |    ?name     |  ?c   |
> > >> +--------------+-------+
> > >> | "John Smith" |       |
> > >>
> > >> could not be a solution because although it is a solution for the first
> > >> pattern it is not a solution for the second pattern. Similarly the
> > >> mapping
> > >>
> > >> |    ?name     |  ?c   |
> > >> +--------------+-------+
> > >> | "Joe Bloggs" | _:jb1 |
> > >>
> > >> is not a solution because it is not a solution for the first pattern. Am
> > >> I
> > >> misreading something about your arguments?
> > >>
> > >> Greetings,
> > >> Jorge Perez
> > >
> > > --
> > > -eric
> > >
> > > home-office: +1.617.395.1213 (usually 900-2300 CET)
> > > cell:        +81.90.6533.3882
> > >
> > > (eric@w3.org)
> > > Feel free to forward this message to any list for any purpose other than
> > > email address distribution.
> > >
> > >
> > 
> 
> -- 
> -eric
> 
> home-office: +1.617.395.1213 (usually 900-2300 CET)
> cell:        +81.90.6533.3882
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.

-- 
-eric

home-office: +1.617.395.1213 (usually 900-2300 CET)
cell:        +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Wednesday, 14 June 2006 17:40:19 UTC