CommentResponse:NL-1

Dear Niklas,

Firstly, thanks for your input and happy new year, as well as apologies for the late response.

Regarding your comment on the CONSTRUCT WHERE shortcut, after internal discussion the WG has decided to keep this on the basic level where the WHERE part can simply be copied "as is" into a CONSTRUCT template. That is, for more complex cases the full form has to be used. Although, that means that for your use case you will need to use the full form of CONSTRUCT, the group still thinks that the shortcut in its current form has useful applications.

We'd appreciate if you could acknowledge that this response adequately addresses your comment.

Axel, on behalf of the SPARQL WG

---------
From: Niklas Lindström <lindstream@gmail.com>
Date: Fri, 24 Jun 2011 13:26:02 +0200
Message-ID: <BANLkTinMx3tJytHUPwCaqNSAamO1ynDxdA@mail.gmail.com>
To: public-rdf-dawg-comments@w3.org
Cc: lee@thefigtrees.net

Dear SPARQL WG,

I am a long term and heavy user (and proponent) of SPARQL, having
worked with it professionally in a swedish government project and
elsewhere. I have long missed the concept of "CONSTRUCT WHERE" [1] in
my queries. I was therefore initially *very* happy to see this new
query form in SPARQL 1.1..

However, due to the heavy restriction of the basic graph pattern ("no
FILTERs and no complex graph patterns are allowed in the short form"),
I am afraid it is basically unusable for any practical use case I
have. :(

My use case outline is to make it possible to pattern match and
extract any kind of subset of a graph, directly as RDF. (It is a
missing feature I've actually wanted even before SPARQL 1.0 entered
the arena.)

A query might say more than a thousand words, so see [2] for an
example of the kinds of queries I use. This example uses SELECT (and
SparqlTree [3] to digest the results in to a simple data form [4],
rendered as [5]). It would be *tremendously* usable to be able to get
all the triples matched by such a query by basically changing the
"SELECT *" to a "CONSTRUCT WHERE". (If the query is intelligible due
to e.g. the swedish terms used, the gist of it is that we have a very
rich and varied set of terms and types describing all kinds of legal
documents, interlinked in different ways and composed of different
constellations of chapters, paragraphs, etc.)

Is there a heavy reason why this restriction is made? Or would it be
feasible to lift or relax this restriction, so that primarily FILTER,
OPTIONAL and UNION would be allowed? I can't emphasize enough how good
that would be.

I expect that the Linked Data API project [6] have very similar needs.
A clear sign of this can be glimpsed by looking at an example of its
usage, [7]. Notice the CONSTRUCT SPARQL query shown at the bottom of
that page. It would without doubt benefit from a "CONSTRUCT WHERE"
with support for FILTER, OPTIONAL and UNION. Unless they're already
involved in this WG process, I'd suggest contacting them
(<linked-data-api-discuss@googlegroups.com>).

Anyway, thank you for your great work on SPARQL 1.1! It is an
impressive achievement.

Best regards,
Niklas Lindström
--
<http://neverspace.net/>

[1]: http://www.w3.org/TR/sparql11-query/#constructWhere
[2]: http://service.demo.lagrummet.se/view/publ/sfs/1991:1469?query
[3]: http://purl.org/oort/wiki/SparqlTree
[4]: http://service.demo.lagrummet.se/view/publ/sfs/1991:1469.json
[5]: http://service.demo.lagrummet.se/view/publ/sfs/1991:1469
[6]: http://code.google.com/p/linked-data-api/
[7]: http://education.data.gov.uk/doc/school/126066