W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2009

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

From: Steve Harris <steve.harris@garlik.com>
Date: Wed, 27 May 2009 17:31:08 +0100
Cc: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>, "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-Id: <62074C1C-AF44-401B-AC07-D644AB12A8B8@garlik.com>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
On 27 May 2009, at 16:25, Seaborne, Andy wrote:
>>> I have been trying to find groups of operations so we can be clear
>> about
>>> what does what:
>>> Tentative suggestion:
>>> 1/ Graph store management: Create/removal of graphs (names of  
>>> graphs)
>> from
>>> the graph store.
>>> 2/ Whole graph operation (graph exists - may have implicit
>> create/delete):
>>> clear, replace contents
>>> 3/ Changes to (nameable) graph: load data into (add triples), delete
>> data,
>>> insert data, delete by pattern, insert by pattern (this seems less
>>> significant)
>> Good. Also, HTTP protocol use, I don't to what extent we should view
>> that as
>> separate?
> 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>'
but that's not the same as
   $ curl -T /tmp/data.rdf 'http://store.example/?graph=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.

- Steve

Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
Received on Wednesday, 27 May 2009 16:31:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:56 UTC