W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > January 2012

Re: The limitations of "CONSTRUCT WHERE" in SPARQL 1.1

From: Niklas Lindström <lindstream@gmail.com>
Date: Mon, 9 Jan 2012 22:06:21 +0100
Message-ID: <CADjV5jdn6czT4mbrNANG3M8wR=GZDZVY6YkZH3Ad6uBVRN9SdQ@mail.gmail.com>
To: Axel Polleres <axel.polleres@deri.org>
Cc: public-rdf-dawg-comments@w3.org, lee@thefigtrees.net
Dear Alex, all,

Thank you for considering this! I see the value of simplicity and
agree that the shortcut form certainly has value in those cases (also,
the "copy as is" is a good conceptual and pedagogical argument).

While I had hoped that OPTIONAL and FILTER could be supported by this
shortcut as well, I won't object to your conclusion. I fully trust the
WG's expertise and appreciate the underlying complexities that you're
considering. Thus I acknowledge that your response adequately
addresses my comment.

(I understand that my use cases are at times quite complex (cf. [1]),
and that there may come along simpler or more succinct options in the
future for some of them. Also, perhaps a future SPARQL version may
include a more advanced CONSTRUCT WHERE, or a more elaborate DESCRIBE.
And maybe alternatives to OPTIONAL and FILTER, more akin to how
property paths work.)

Anyway, I am very glad to see the progress you've made with SPARQL 1.1
overall. I've found the Query Language document a joy to read. Thank
you for the great work!

And a happy new year to you too!

Best regards,Niklas
[1]: https://raw.github.com/rinfo/rdl/d0814f2f10/packages/java/rinfo-service/src/main/resources/sparql/construct_relrev_data.rq


2012/1/4 Axel Polleres <axel.polleres@deri.org>:
> 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 Monday, 9 January 2012 21:07:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 January 2012 21:07:35 GMT