- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Sun, 25 Oct 2009 23:34:00 -0400
- To: Holger Knublauch <yahoo@knublauch.com>
- CC: public-rdf-dawg-comments@w3.org
Hi Holger,
Thanks for the feedback. Unfortunately, assignment is not on the current
Working Group's road map for standardization at this time. Here's how we
got to this point:
From roughly March through May, the WG considered around 40 potential
new features[1] for the SPARQL landscape, including assignment[2]. At
the time, we documented two implementations (ARQ and Open Anzo) and the
support that you expressed for the feature back in March[3].
In going through the features, the WG discussed Assignment in our March,
31 teleconference. You can see the discussion at the time at [4], the
results of which was a straw poll result of 7/6/3, indicating some
support and several notes of concern.
Later in the process, we took a survey of WG member's prioritized
preferences of the proposed features. Steve Harris whipped up the
Condorcet results of the survey which you can see at [5]. Assignment was
in the middle of the pack.
At the group's first face-to-face meeting in May, assignment was
discussed once more[6], with significant concerns expressed from Garlik
and OpenLink Software, strong support from Clark & Parsia, and
expressions ranging from indifference to mild support from other WG
members (as I read the minutes & recollect the conversation). In the
end, the group resolved to accept the list of feature proposals at [7],
and Kendall's concerns about the relationship between assignment and
projected expressions was addressed by Steve H at [8].
Since then, the group has been rechartered with a specific mandate to
work on the features decided during the first phase of the group's
lifetime[9]. It's my hope & belief that if projected expressions do not
end up fulfilling most users' needs, that implementors will extend their
SPARQL implementations with assignment or a similar capability, and we
will then revisit this in the next round of SPARQL standardization.
hope this is helpful,
Lee
[1] http://www.w3.org/2009/sparql/wiki/Category:Features
[2] http://www.w3.org/2009/sparql/wiki/Feature:Assignment
[3]
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Mar/0009.html
[4] http://www.w3.org/2009/sparql/meeting/2009-03-31#assignment
[5] http://plugin.org.uk/misc/votes2.svg
[6] http://www.w3.org/2009/sparql/meeting/2009-05-06
[7]
http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744
[8] http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0231.html
[9] http://www.w3.org/2009/05/sparql-phase-II-charter
Holger Knublauch wrote:
> Dear WG,
>
> reading through the drafts (great to have them already!) I am confused
> about the future of Assignments (LET keyword in Jena) which has proven
> to be absolutely essential for many of our customers projects. The
> SPARQL 1.1 working group seems to have converged in favor of supporting
> Project expressions and subqueries only, but these IMHO fail to address
> the requirements below.
>
>
> Problem 1: How to create new values for CONSTRUCT queries
> Project expressions solve some problems for SELECT queries, but the
> major use cases of LET have been in CONSTRUCT queries. I only see
> subqueries as a (poor) way of creating new values for use in the
> CONSTRUCT clause. Creating a subquery for every LET looks like a very
> user unfriendly mechanism to me.
>
> Problem 2: Verbosity
> We often work with complex transformations such as string operations
> that are best split into multiple steps. Project expressions do not
> allow using intermediate variables, such as below and would force users
> to chain together very long spaghetti expressions such as SELECT (?x
> ex:function3(ex:function2(ex:function1(?y))). Imagine this with some
> more complex expressions and it quickly becomes completely unreadable.
> Also, consider you would want to reuse intermediate values in multiple
> places, to avoid duplicate processing.
>
> *SELECT* ?x ?r
> *WHERE* {
> ?x ex:property ?y .
> *LET* (?helper1 := ex:function1(?y)) .
> *LET* (?helper2 := ex:function2(?helper1)) .
> *LET* (?r := ex:function3(?helper2)) .
> }
>
> The LET keyword has solved both problems nicely and in the most general
> way, and would make project expressions superfluous.
>
> I would appreciate pointers to the discussions that led to the decision
> to not support Assignments at this stage.
>
> Thanks
> Holger
>
> PS: For a parallel thread on jena-dev (with Andy's response), see
>
> http://tech.groups.yahoo.com/group/jena-dev/message/41903
Received on Monday, 26 October 2009 03:34:40 UTC