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 15:34:13 +0000
Message-ID: <4AFAD975.1040903@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 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.

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.

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

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


Because it's a conceptual join, per row, you allow solutions where the 
same value is already bound to the named variable?

(PS But what happens about errors in evaluation?)

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

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)

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

Received on Wednesday, 11 November 2009 15:34:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:58 UTC