Raw

First of all a small apology to Kendall, when I mentioned "breaking the Web" in the last post I was using the phrase loosely and for dramatic effect, but it wasn't intended as anti-OWL 1.1 FUD. In fact I'll use the phrase again, in the context of something I strongly favour ( not that I favour breaking the Web...).

Richard and Max have revived discussion about the update side of SPARQL with SPARQL Update Language at the ESW Wiki. (I did try to post a comment at Richard's, but it's not shown up - could well be a miskey on my part).

I think the moratorium on SPARQL was a good idea ( didn't initially) - hold fire on new developments while what there is already is tested in the wild. But a data protocol without update is painfully limited, and in this particular case an extra consideration is the expectation of people familiar with SQL.

A key consideration for SPARQL has to be the protocol angle. If it is to be the query language of the Semantic Web, it mustn't break the Web. As Kendall pointed out, the Web is remarkably resilient, but I still think breakage is an appropriate term for protocol abuse. That isn't to say I believe the current suggestions are wrong - I really don't know. This is what we need fundamentalists for, so I'm pleased to see Mark Baker's already added a note to the Wiki. 

Back in March at SwigAtTp2006 the DAWG joined the SWIG meet and went around the room polling for views on where SPARQL should go. Top of the list was Update. The IRC log captured my opinion on this as " want methods correspoinding to HTTP methods" ( blessed are the scribes...). I was referring really to GET, PUT, POST, DELETE, thinking these should be the starting point in preference to database CRUD. I've been using SPARQL at work and play pretty much all year. The work side hasn't actually needed the protocol, the querying is all done programmatically. But on the play side I've been thinking about a  SemanticWebAgentFramework and there the protocol would be a key part. I suspect that (with a little work on conventions) the 4 HTTP methods above could be applied directly to cover a large proportion of SPARQLs protocol requirements. Whatever happens, I think opaque tunnelling a la XML-RPC/SOAP should be avoided like the plague. Why choose less interop?

Mark mentions HTTP PATCH on the Wiki - golly, I'd completely forgotten about that. I guess that also calls for a re-reading of timbl on RDF Diff/Patch etc, and a bit of play with Reto's implementation.