- From: Holger Knublauch <yahoo@knublauch.com>
- Date: Sun, 25 Oct 2009 12:30:39 -0700
- To: public-rdf-dawg-comments@w3.org
- Message-Id: <E13DE142-1FE7-423B-93D4-7C8FE3991F36@knublauch.com>
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 Sunday, 25 October 2009 19:31:18 UTC