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

Re: OPTIONALs and shared variables

From: Jorge Pérez <jperez@ing.puc.cl>
Date: Fri, 16 Jun 2006 10:19:30 -0400 (CLT)
Message-ID: <50397.146.155.4.12.1150467570.squirrel@mail.ing.puc.cl>
To: "Eric Prud'hommeaux" <eric@w3.org>
Cc: public-rdf-dawg-comments@w3.org

Eric Prud'hommeaux wrote:
> 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.

Ok, (i think that) now I understand completely what you were trying to
explain to me, thank you very much for the responses (and for the patience
:-))

I realize now that my problem is with the *design* of pattern solutions. I
still have a controversy, I was completely convinced that the only one
solution for

   ?a cc:license ?license .
   OPTIONAL { ?a dc11:creator ?c .
              ?c rdf:value ?name }

was the bindings

| ?a |    ?name     |  ?c   |    ?license       |
+----+--------------+-------+-------------------+
| :a | "Joe Bloggs" | _:jb1 | "steal this book" |

but your argument add a *new* solution (new for me, I think that for you
it was always a solution)

| ?a |    ?name     |  ?c   |    ?license       |
+----+--------------+-------+-------------------+
| :a | "John Smith" |       | "steal this book" |

and an infinitely many solutions of the form

| ?a |    ?name     |  ?c   |    ?license       |
+----+--------------+-------+-------------------+
| :a |    any1      | any2  | "steal this book" |

where any1 and any2 are arbitrary elements in the scoping set plus an
special element stating for "unbound".... Am I right? I think that this is
what you were trying to explain to me in an early mail.

>
> Perhaps you are evaluating differently by taking the intersection of
> the solutions to A OPT B and C OPT D.

I was thinking in something like a JOIN, not in an intersection

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

I agree with you that if intersection is used it will never work.

- jorge

>
>> - 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 14:19:47 GMT

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