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

Re: Potential design space of LET/assignment

From: Paul Gearon <gearon@ieee.org>
Date: Wed, 11 Nov 2009 16:14:56 -0500
Message-ID: <a25ac1f0911111314l620f828fye420ae992756fe26@mail.gmail.com>
To: Andy Seaborne <andy.seaborne@talis.com>
Cc: Lee Feigenbaum <lee@thefigtrees.net>, Steve Harris <steve.harris@garlik.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
On Wed, Nov 11, 2009 at 10:34 AM, Andy Seaborne <andy.seaborne@talis.com> wrote:
>>> 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?
> (PS But what happens about errors in evaluation?)


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

Pretty much the same thing that Lee describes for OpenAnzo. It uses
almost identical code to FILTER, only instead of reducing a result set
to fewer rows, it widens the set by one variable.

Due to the simple nature of my implementation, I've simply disallowed
assignment to existing variables. I guess it wouldn't be too hard to
change that, but I was going for minimal effort.  :-)

Errors result in an unbound variable.

Paul Gearon
Received on Wednesday, 11 November 2009 21:15:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:57 UTC