- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Thu, 30 Sep 2010 10:12:29 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
On 9/30/2010 5:15 AM, Andy Seaborne wrote: > > > On 29/09/10 03:45, Lee Feigenbaum wrote: >> When last we talked, we decided we wanted to look at the semantics of a >> proposed LET/BIND/Assignment clause before choosing the keyword and >> proceeding with a decision. >> >> Here are a few test cases; I use KW (keyword) below where LET or BIND or >> whatever might go. >> >> Data: >> >> :s :one 1 . >> :s :two 2 . >> >> >> 1. Simple >> >> SELECT ?sum ?one ?two { >> ?s :one ?one ; :two ?two . >> KW (?sum := ?one + ?two) >> } >> >> Result: >> >> ?sum ?one ?two >> ----------------------- >> 3 1 2 >> >> >> 2. Calculated value matches existing binding >> >> SELECT ?one { >> ?s :one ?one . >> KW (?one := 1) >> } >> >> I believe there are two options here from what I've heard >> >> Option 1 ("join semantics") result: > > Maybe this is more "FILTER semantics" because of the similarity between: > > SELECT ?one { > ?s :one ?one . > KW (?one := 1) > } > > SELECT ?one { > ?s :one ?one . > FILTER (?one = 1) > } > > and the discussion of placement and eliminating rows as below. The > handling of errors in expressions is more FILTER like as is the > expressions form > > KW (?two := ?one+1) > > because ?one is in scope. ...I see what you mean. Under both types of semantics LET/BIND can add new columns, but only with join/filter semantics can it eliminate bindings in the way a filter would. >> >> ?one >> ----- >> 1 >> >> Option 2 ("simple semantics") result: >> >> Error, can't assign to / bind a variable that's elsewhere bindable in >> the same scope >> >> >> 3. Calculated value does not match existing binding >> >> SELECT ?one { >> ?s :one ?one . >> KW (?one := 5) >> } >> >> I believe there are three options here from what I've heard >> >> Option 1 ("join semantics") result: >> >> ?one >> ----- >> >> Option 2 ("simple semantics") result: >> >> Error, can't assign to / bind a variable that's elsewhere bindable in >> the same scope >> >> Option 3 ("assignment semantics") result: >> >> ?one >> ----- >> 5The only way to tell is > >> >> NOTE: I don't believe _anyone_ is advocating or implements assignment >> semantics like this, but I wanted to include it for completeness. >> >> >> 4. Logical order of assignment/binding >> >> SELECT ?sum { >> KW (?sum := ?one + 1) . >> :s :one ?one . >> } >> >> Option 1 ("in place") result: >> >> ?sum >> ---- >> >> (no result as ?one has no binding and so the expression is an error) >> >> Option 2 ("end of group") result: >> >> ?sum >> ---- >> 2 >> >> (assignments/binds are treated as with FILTERs, they occur logically >> after a group's solution set has been evaluated) >> >> >> I believe from the thread at >> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JulSep/0116.html >> that Mulgara implements what I'm calling "simple semantics". Anzo >> (Glitter) implements "join semantics". ARQ implements "simple semantics" >> as well. > > ARQ implements filter/join semantics, but "in place" not "end of group" > > Because of > > SELECT ?one { > KW (?one := 1 ) > :s :one ?one . > } > > SELECT ?one { > :s :one ?one . > KW (?one := 1 ) > } > > have the same results because of the assign-same-value rule. > > So the only way to tell the difference is: > > SELECT ?sum { > KW (?two := ?one+1) > :s :one ?one . > } > > which causes an error evaluating (?two := ?one+1) for > unbound-at-the-time ?one. OK, right, I see. > I'm happy with changing to end-of-group semantics. It's much the same as > processing filter (algebra) and placement is very similar to filter > placement (optimization). Right, I handle assignments and filters basically together in my implementation. Lee > > http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JulSep/0019.html > >> Here was the last time we discussed this at a TC: >> >> http://www.w3.org/2009/sparql/meeting/2010-07-06#LET__2f_Assignment >> >> Please discuss if you'd like, and next week I'd like to decide on >> inclusion or not (strong lean towards include last time) and, if we >> choose to include the feature, the semantics based on these options or >> any other options people suggest and the keyword. >> >> Lee >> > >
Received on Thursday, 30 September 2010 14:20:02 UTC