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 <firstname.lastname@example.org> Date: Fri, 24 Jun 2011 13:26:02 +0200 Message-ID: <BANLkTinMx3tJytHUPwCaqNSAamO1ynDxdA@mail.gmail.com> To: email@example.com Cc: firstname.lastname@example.org 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"  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  for an example of the kinds of queries I use. This example uses SELECT (and SparqlTree  to digest the results in to a simple data form , rendered as ). 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  have very similar needs. A clear sign of this can be glimpsed by looking at an example of its usage, . 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 (<email@example.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/> : http://www.w3.org/TR/sparql11-query/#constructWhere : http://service.demo.lagrummet.se/view/publ/sfs/1991:1469?query : http://purl.org/oort/wiki/SparqlTree : http://service.demo.lagrummet.se/view/publ/sfs/1991:1469.json : http://service.demo.lagrummet.se/view/publ/sfs/1991:1469 : http://code.google.com/p/linked-data-api/ : http://education.data.gov.uk/doc/school/126066