W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Re: Potential design space of LET/assignment

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Wed, 11 Nov 2009 22:18:00 +0000
Message-ID: <4AFB3818.4020105@talis.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
CC: Steve Harris <steve.harris@garlik.com>, SPARQL Working Group <public-rdf-dawg@w3.org>


On 11/11/2009 20:15, Lee Feigenbaum wrote:
>> 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.

ARQ does the same.

Nothing about errors in is the defn of extend for FPWD - that was just 
enough to outline the SELECT-expr design.

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

The assignment is not ignored - the solution is not in the outcome which 
is like your per-row join description.

I will try to rework that part of the FPWD soon.  As well as write down 
the SELECT-LET transformations.

Do you have a formulation to describe what Glitter does?

	Andy

>
> Lee
Received on Wednesday, 11 November 2009 22:18:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:40 GMT