I was really pleased to see that the charter for the SPARQL Working Group is now public. Having made heavy use of SPARQL in a number of personal and commercial projects there have been a number of pain points which, to date, I’ve only been able to address by resorting to vendor specific extensions. The key ones for me have been support for aggregates as well as handling of collections and containers. These are all on the list of candidate issues for the Working Group to address, so this is good news as far as I’m concerned.
Recently I’ve been thinking about ways to improve DESCRIBE queries, e.g. by adding a “USING” keyword to specify the description algorithm. Like others, I’ve found Concise Bounded Descriptions and similar algorithms to be extremely useful when building semantic web applications. Being able to select amongst those algorithms from within a query would be a Good Thing. As improvements to DESCRIBE may also be on the Working Group’s agenda, this might save me a bit of work!
Of the other example topics lists in the charter document, the exploration of an XML syntax for SPARQL left me shrugging my shoulders, while the insert/update/delete capability gives me a small bit of concern: its obviously an essential part of the language and the issue does need to be addressed, but there’s more than one way to do it. Have the various options been explored? Could SPARQL support more than one update mechanism, just as it supports multiple query forms? After all, all of those forms have valid use cases and, to my mind, there are some useful trade-offs in the different approaches to handling updates too. However I do acknowledge that SPARQL shouldn’t become too unwieldy, so maybe this is just wish fulfilment on my part.
Oh, and I still think that query by reference is a good idea.
While we’re going to have to wait over a year (based on current estimates) for an updated recommendation, I hope that we’ll start to see some alignment between SPARQL implementations before then. Especially around the extension mechanisms and filters.
But this is one area where the semantic web community could really be doing more to help itself: the lack of, say, support for querying collections, would be less of an issue if the community co-ordinated on defining how these extensions might work; have a standard namespace for them; create implementations for the common processors; etc. This worked perfectly well for the XSLT community which addressed similar issues through the EXSLT project. With a degree of community spirit we could have more portable SPARQL queries now, and also encourage some further exploration around extensions, without having to wait for the rubber stamp of the working group. I’ve been wondering how best to try and foster that. If you’re interested then drop me a mail or a tweet (@ldodds).
Lost Boy 