W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2006

Re: OPTIONALs and shared variables

From: Eric Prud'hommeaux <eric@w3.org>
Date: Fri, 16 Jun 2006 09:21:35 +0200
To: Jorge Adrián Pérez Rojas <jperez@ing.puc.cl>
Cc: public-rdf-dawg-comments@w3.org
Message-ID: <20060616072135.GB24910@w3.org>

On Wed, Jun 14, 2006 at 02:00:25PM -0400, Jorge Adrián Pérez Rojas wrote:
> Eric Prud'hommeaux wrote:
> > 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.
> 
> I think we are approaching to the conflictive point. The spec
> [[
> An optional graph pattern is a combination of a pair of graph patterns
> ]]
> dos not allow us (i think) to interpret an OPTIONAL in a "unary" way as
> your are interpreting it above, so, i think it makes no sense to ask if
> the mapping
> 
>   | ?a |    ?name     |  ?c   |
>   +----+--------------+-------+
>   | :a | "John Smith" |       |
> 
> matches the pattern
> 
>   OPTIONAL { ?a dc11:creator ?c .
>              ?c rdf:value ?name }
> 
> because this pattern does not even appear in the query, one must ask if
> the above mapping matches the pattern
> 
>   ?a cc:license ?license .
>   OPTIONAL { ?a dc11:creator ?c .
>              ?c rdf:value ?name }
> 
> that does appear in the query... Another question is if the mapping above
> matches this last pattern, and I think it does not...

Indeed, I was trying be, perhaps, too terse, by eliding the two
non-optional parts as I assumed they matched. If we mechanically test
this solution, following the semantics 2.4, 2.5, (3.3), 4.1, and 5.4,
we must, by 4.1, evaluate the two patterns:.
  ?a dc10:title "thing" .
  OPTIONAL { ?a dc10:creator ?name }
and
  ?a cc:license ?license .
  OPTIONAL { ?a dc11:creator ?c .
             ?c rdf:value ?name }

4.1
[[
A solution of Group Graph Pattern GP on graph G is any solution S such
that, for every element GPi of GP, S is a solution of GPi.
]]

I believe we are in agreement that
  | ?a |    ?name     |  ?c   |
  +----+--------------+-------+
  | :a | "John Smith" |       |
matches the first one. Testing the second, we see
  ?a cc:license ?license
matches with ?a bound to :a (should be _:a, but I will preserve my
earlier typo) and ?license to "steal this book". However, we are, at
the same time, testing the OPTIONAL pattern immediately
following. There is no ?c for which
  { :a dc11:creator ?c .
    ?c rdf:value "John Smith" }
is in our data so we fall back to the "otherwise" in 5.4
[[
If Opt(A, B) is an optional graph pattern, where A and B are graph
patterns, then S is a solution of optional graph pattern if S is a
pattern solution of A and of B otherwise if S is a solution to A, but
not to A and B.
]]
and see that the pattern matches, but does not provide any bindings.

Perhaps you are evaluating differently by taking the intersection of
the solutions to A OPT B and C OPT D. I don't think that will ever
work for any OPTIONALs unless you include all the solutions where the
OPTIONALs did not match and add something to implement the preference
for binding everything possible.

> - jorge
> 
> >
> > 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.
> >
> >
> 

-- 
-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 Friday, 16 June 2006 07:20:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:50 GMT