Re: The limitations of "CONSTRUCT WHERE" in SPARQL 1.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 

On 24 Jun 2011, at 13:26, Niklas Lindström wrote:

> 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
> 
>

Received on Wednesday, 4 January 2012 22:41:07 UTC