RE: Missing LET (Assignment) in SPARQL 1.1



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