Re: Potential design space of LET/assignment

Andy Seaborne wrote:
> 
> 
> On 11/11/2009 13:46, Lee Feigenbaum wrote:
> ...
>> 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. :-)
> 
> TopQuandrant are using ARQ (and other RDF systems) but their 
> requirements and experiences are theirs alone and I can't answer for 
> them.  They have asked me (on jena-dev) the WG status and I directed 
> them to the comments list.

They've pretty explicitly stated that their requirements are 
standardization of the feature that they use, which is ARQ's assignment 
implementation.

> I had not seen Jeremy's rewrite description before; within this WG, and 
> to them probably, usually on jena-dev, I have talked about it being a 
> syntactic transformation for some time now.  By that, I mean it gets 
> done in the algebra translation step and there is no modification to the 
> algebra to accomodate it.

Well, I still don't understand it, in any case, which makes me wary of 
suggesting that it's a simple thing for us to standardize.

> The term "sophisitic" (sic) has been used.   There is no trickery going on.

? Don't understand.

>>> 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.
> 
> Thanks.
> 
> Because it's a conceptual join, per row, you allow solutions where the 
> same value is already bound to the named variable?

Right.

> (PS But what happens about errors in evaluation?)

If the expr evaluates to a type error, I intended to have that discard a 
solution if the variable were already bound, and act as a no-op 
otherwise. But re-looking now I have a few bugs in the handling there.

>>>>> 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)?
> 
> Yes.
> 
>> 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?
> 
> A solution mapping is a function so there can only be one x binding.
> 
> (x,t) for x in dom(μ) and t != μ(v) is not in the set.
> 
> Better would be:
> 
> { (x,t) |
>   (x in dom(μ) and t = μ(x)) or (x not in dom(μ) and t = term)
> }

So this says that the LET assignment is ignored completely if the 
variable is already bound. That's different from what I do. Am I 
understanding this correctly?

Lee

> The first condition is not needed if there is a syntactic restriction 
> requiring new names but then you loose the relationship to BGP matching 
> and FILTERs, which OpenAnzo has.



> Paul - what do you do?
> 
>>> 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.
> 
> You didn't describe that part - is there a documentation link?
> 
> http://www.openanzo.org/projects/openanzo/wiki/SPARQLExtensions does not 
> say ;-)
> 
> (The F2F discussed errors in SELECT-exprs and concluded they should not 
> pass the current solution. That would be compatible.)
> 
>> 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
> 
>     Andy
>

Received on Wednesday, 11 November 2009 20:16:28 UTC