- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Fri, 30 Oct 2009 12:37:06 +0000
- To: SPARQL Working Group Comments <public-rdf-dawg-comments@w3.org>
- CC: Lee Feigenbaum <lee@thefigtrees.net>, Holger Knublauch <yahoo@knublauch.com>
> -----Original Message----- > From: public-rdf-dawg-comments-request@w3.org [mailto:public-rdf-dawg- > comments-request@w3.org] On Behalf Of Lee Feigenbaum > Sent: 27 October 2009 13:28 > To: Holger Knublauch > Cc: SPARQL Working Group Comments > Subject: Re: Missing LET (Assignment) in SPARQL 1.1 > > Holger Knublauch wrote: > >> This example actually is a good example of one thing that concerns me > >> about assignment (and remember that my implementation is one that does > >> support LET expressions): I'm concerned whenever a new SPARQL > >> construct has an order-dependence. SPARQL is already order-dependent > >> in cases involving OPTIONAL, but I prefer to keep as much of SPARQL > >> order-independent as is possible. The above collection of assignments > >> reads OK because of the order they're presented in, but if you switch > >> the order around it's not at all clear to me what the proper algebraic > >> expectations would be. > > > > Yes, LET assignments will (have to) be order dependent. And yes, this is > > a good thing. Sure, it may not be perfect from some theoretical point of > > view, but without ordering the whole approach would not work, and we > > would throw out the baby with the bath water. Even the solution with > > nested sub-selects is order dependent. Giving users the ability to > > specify the order in a reliable way has not been a problem with any > > other mainstream computer language, so why should SPARQL be different? > > SPARQL is a query language, and my understanding of previous discussions > is that there is concern that an assignment construct turns a (mostly) > declarative language into a (somewhat) imperative language, which is (at > least) a different mind set for users. Again, I'm just repeating what I > believe I've heard from WG members. > > Also, for what it's worth, I don't think that LET need be ordered - the > Open Anzo implementation is not, and it's (nevertheless) very useful for us. > > Also, as currently specified in our Working Drafts, subqueries are not > order dependent. Andy or Steve will correct me if I'm wrong, I'm sure. :-) You are right elements in the same group combine with join so they are not order dependent. But the example was wrong - the SELECTs should nested so variables are in-scope. There are two dimensions of order dependency here: The first: ...pattern ... LET (?z := ?y + ?x) LET (?a := 2+?z ) which, practically, is best defined as order dependent but it happens by nesting: SELECT ?z , (2+?z AS ?a) # Projecting ?z is necessary { SELECT (?y + ?x AS ?z) { ...pattern... } } and we don't regard that order dependency as a problem. AS is assignment and the same issues arise in SELECT expressions with AS: Is this SELECT (?y + ?x AS ?z) , (2+?z AS ?a) legal? It can be made to with a left-to-right reading. The second order dependence issue is around: { ?s ?p ?o LET (?o := <x> ) } { LET (?o := <x> ) ?s ?p ?o } This can be made to work (they do the same thing) - a solution is acceptable if an assignment occurs or the variable already has that value. If it's a different value, then the solution is rejected - this is assignment as a necessary constraint. It can be useful in transformations of the algebra for optimization. The other design is that variable names must not have been mentioned beforehand so case 1 is illegal - it can be a static check. Andy See also http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0270.html
Received on Friday, 30 October 2009 12:38:15 UTC