Post

Author

Password

URI Delete Entry?

Title

Content

<div>First of all a small apology to Kendall, when I mentioned
"breaking the Web" in the last 
<a href="http://dannyayers.com/2006/11/20/owl">post</a> 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...).

<a href="http://dowhatimean.net/2006/11/sparql-update-language-at-esw">Richard</a>
and 
<a href="http://www.aifb.uni-karlsruhe.de/WBS/mvo/">Max</a> have
revived discussion about the update side of SPARQL with 
<a href="http://esw.w3.org/topic/SparqlUpdateLanguage">SPARQL
Update Language</a> 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 
<a href="http://ianfoster.typepad.com/blog/2006/11/the_web_thought.html">fundamentalists</a>
for, so I'm pleased to see 
<a href="http://www.markbaker.ca/blog/">Mark Baker</a>'s already
added a note to the Wiki.Â 
Back in March at 
<a href="http://esw.w3.org/topic/SwigAtTp2006">SwigAtTp2006</a> the

<a href="http://www.w3.org/2001/sw/DataAccess/">DAWG</a> joined the
SWIG meet and went around the room polling for views on where
SPARQL should go. Top of the list was Update. The 
<a href="http://chatlogs.planetrdf.com/swig/2006-03-02.html#T12-39-47">IRC
log</a> 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 
<a href="http://en.wikipedia.org/wiki/CRUD_(acronym)">CRUD</a>.
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Â  

 <a href="http://esw.w3.org/topic/SemanticWebAgentFramework">SemanticWebAgentFramework</a>
 
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 
 <a href="http://www.w3.org/Protocols/HTTP/1.1/spec.html#PATCH">HTTP
 PATCH</a> on the Wiki - golly, I'd completely forgotten about
 that. I guess that also calls for a re-reading of timbl on 
 <a href="http://www.w3.org/DesignIssues/Diff">RDF Diff/Patch</a>
 etc, and a bit of play with Reto's 
 <a href="http://wymiwyg.org/2005/12/22/announicing-rdf-utils">implementation</a>.
@en
</div>