- From: Jorge Pérez <jperez@ing.puc.cl>
- Date: Fri, 16 Jun 2006 10:19:30 -0400 (CLT)
- 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 UTC