Potential design space of LET/assignment (was: Re: Views on the outcomes of F2F)

Andy Seaborne wrote:
> 
> 
> On 10/11/2009 21:45, Lee Feigenbaum wrote:
>> Andy Seaborne wrote:
>>>
>>> I believe Holger is asking for nothing more than syntactic sugar.
>>> Jeremy's syntactic conversion from LET to SELECT expressions shows
>>> what they want and it's a syntactic rewrite even SPARQL syntax to
>>> SPARQL syntax.
>>
>> I couldn't follow the transformation. Can you explain it, please? I'm
>> trying to figure out if it matches what is implemented in Open Anzo or 
>> not.
> 
> If that would help the WG; I'll write a separate email.  The 
> clarification should come from the commenter, rather than my 
> interpretation, but I'm sure we can ask them to comment on the description.

It would definitely help me in trying to figure out the cost of adopting 
this work; it seems particularly relevant to me whether the existing 
implementations that we think all implement assignment are actually 
implementing the same thing or not, to know whether we're talking about 
an obvious syntactic rewrite or whether the potential design space is 
larger (and therefore more fraught).

Also, the commenters are using ARQ and have mentioned that the rewrite 
interpretation comes from you, I believe, so it would probably be best 
for you to provide it. :-)

> It would also be helpful if you describe what OpenAnzo does. (ditto 
> other impls).  I hope that Steve will provide the concrete example of 
> what he thinks Holger is asking for and any examples that concern him.

Open Anzo attaches LETs at the group level (a la FILTERs) and applies 
them to the solution set that results from evaluating the group. It 
applies them in the lexical order that they're found. It (conceptually) 
evaluates each assignment to get a new one row, one column solution set, 
and joins that solution set with the the group's solution set. Rinse and 
repeat for the rest of the assignments attached to the group.

>>> We know LET->SELECT and SELECT->LET as syntatic transforms.. There is
>>> no new functionality (it does not change the algebra at all); it's all
>>> in the syntax to algebra translation step, which is what I consider
>>> syntactic suger.
>>>
>>> I understand the comment as a request to make it easier to use by
>>> exposing the assignment part of AS without the project interactions -
>>
>> Is this the "Extend" operator in the FPWD? I'm having trouble
>> understanding the definition (and, again, checking if this is consistent
>> with my implementation).
> 
> Yes - "Extend" is the thing that does the AS part.
> 
> The message 2009OctDec/0270.html tries to explain that - if anything is 
> not clear, then ask away on that thread.
> 
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0270.html

The explanation in that message doesn't really get at the details of the 
3-argument algebraic forms in the document, which is what I'm most 
interested in. The def'n there says:

extend(μ, var, term) = { (x,t) | x in dom(μ) and t = μ(v) or x = var and 
t = term }

First, I assume mu(v) should be mu(x)? Second, I don't understand how 
this definition treats the case in which mu already binds var to a value 
different from term. Best I can read is that you end up with solution 
that has 2 bindings for x, but I'd be surprised if that's the intention, 
so I imagine I'm reading it wrong?

> See also:
> C.J.Date, "An Introduction to Database Systems", 8th edition, p197
> 
> (which I have just found - the use of the same name is co-incidence or 
> my subconscious).
> 
>> One of the things that I'm trying to evaluate in looking at
>> TopQuadrant's request is whether this is as simple as they and you
>> claim. Part of trying to evaluate that is seeing if the various
>> implementors really have implemented the same thing. Another part is
>> figuring out if different people have different expectations about what
>> LET would do. (Easy case, do people expect to be able to do LET ?y := ?y
>> + 1 with any other effect besides returning no solutions.)
> 
> I know of no one expecting that.  I would argue against it and anything 
> that replaces one value with another.
> 
> Don't know if you saw, someone asked about this
> http://tech.groups.yahoo.com/group/jena-dev/message/42041
> 
> My implementation is described at:
>   http://www.openjena.org/ARQ/assignment.html
> where the assignment rules align pattern matching and assignment.

The rule there about how you handle expressions that evaluate to type 
errors does not match what Open Anzo does. Again, I mainly bring this up 
to determine how small the design space for this suggested feature 
actually is, how much it actually is purely a syntactic rewrite, and how 
much there is existing consensus from implementors and users around the 
expectations of the feature. My desire to reconsider the feature (or 
not) depends largely on these things.

Lee

> e.g.
>   { ?x :p ?v . LET (?v := <uri>) }
>   { ?x :p ?v . FILTER (?v = <uri>) }
>   { ?x :p 123 . } except ?v records <uri>
> 
> but I am not advocating solely that design and will see what others have 
> done.
> 
> The alternative of new name introduction provides much of the useful 
> functionality without aligning with setting a variable through BGP 
> matching.
> 
> That is,
>    { ?x :p ?v . LET (?v := <uri>) }
> is illegal as the "?v" in LET is not a new name.
> 
> Incidently, my optimizer rewrites
>   { ?x :p ?v . FILTER(?v = <uri>) }
> to
>   { ?x :p <uri> . LET(?v := <uri>) }
> 
>     Andy
> 
>> The Chairs do believe that this pretty clearly falls outside the scope
>> of our charter, but we're considering it nevertheless given the new
>> information.
>>
>> Lee
>>
>>> i.e. less verbose than SELECT *, (?x+?y AS ?z) without the pain of
>>> needing to get the "*" right; better appearance for usse when there
>>> are several assignments.
>>>
>>> What do you think Holger is asking for?
>>> In what way does it fall outside syntactic sugar?
>>> I would find a concrete example we can discuss helpful.
>>> Do you have a different definition of syntactic sugar?
>>>
>>> Andy
>>>
>>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>

Received on Wednesday, 11 November 2009 13:46:52 UTC