RE: [ACTION-33] Trying to sort the SPARQL/Update issues.



> -----Original Message-----
> From: Steve Harris [mailto:steve.harris@garlik.com]
> Sent: 27 May 2009 17:31
> To: Seaborne, Andy
> Cc: Kjetil Kjernsmo; public-rdf-dawg@w3.org
> Subject: Re: [ACTION-33] Trying to sort the SPARQL/Update issues.


> > I don't see the HTTP protocol use as adding operations that can't be
> > done by the language.  They should be aligned.  The language will
> > probably be able to do more.
> 
> I disagree. The language can't take "local" (to the client) data in
> RDF/XML syntax and write it to a remote store. You can do
>    $ sparql-update http://store.example/ 'LOAD <file:///tmp/data.rdf>
> INTO <http://example.com/data.rdf>'

I think pushing rather hard on a design that does not fully exist yet in saying "can't".  You have a suggested requirement.

Not RDF/XML per se, but that's it in the area of INSERT DATA so we might have an operation like LOAD INLINE (and multi part MIME? Bit messy).


> but that's not the same as
>    $ curl -T /tmp/data.rdf
> 'http://store.example/?graph=http%3A%2F%2Fexample.com%2Fdata.rdf'

This requires a service to manage the store service endpoint.  

I see that as putting language into the URI query string 

'http://store.example/?loadInto=http%3A%2F%2Fexample.com%2Fdata.rdf'

> due to the whole client/server thing.
> 
> I suspect that the PUT/POST/DELETE type tuff is a more natural fit
> into the SPARQL Protocol doc, but no strong feelings on that.

But again, what if there is no protocol engine?

A language enables "perform this script (ref file) on that endpoint".  The ability to record, pass around, reply is valuable.

 Andy

> 
> - Steve

Received on Wednesday, 27 May 2009 17:07:32 UTC