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: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 27 May 2009 17:06:13 +0000
To: Steve Harris <steve.harris@garlik.com>
CC: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>, "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3646C2E0DD3@GVW1118EXC.americas.hpqcorp.net>

> -----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 


> 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.


> - Steve

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:55 UTC