- 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