- From: Niklas Lindström <lindstream@gmail.com>
- Date: Mon, 9 Jan 2012 22:06:21 +0100
- 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 UTC