- 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