- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Fri, 25 Feb 2005 14:06:31 +0000
- To: Dan Connolly <connolly@w3.org>
- CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Dan Connolly wrote:
> Re "SPARQL Protocol for RDF editor's drft @@to be provided by Wed, 23
> Feb"
> -- http://www.w3.org/2001/sw/DataAccess/ftf5-bos.html#rdl
>
> Kendall called me to let me know that continued illness etc.
> messed up plans to have a new draft for review yesterday.
Kendall - hope you well for the F2F.
>
> He may have some time this weekend. I don't expect everybody to
> read whatever he comes up with overnight, so we'll use the W3C
> Working Draft 14 January 2005 as the starting-page for the
> ftf meeting...
> http://www.w3.org/TR/2005/WD-rdf-sparql-protocol-20050114/
> which is, aside from title page decoration, the same as
> the current editor's draft...
> 1.15 http://www.w3.org/2001/sw/DataAccess/proto-wd/
>
> But in any case... if you have protocol thoughts and
> have been waiting for a new draft before sharing them,
> please don't wait any longer.
>
> In particular, these threads:
>
> Some protocol & service description issues
> Kendall Clark (Tuesday, 25 January)
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0046.html
>
> SPARQL Protocol for RDF / feedback (fwd) Dirk-Willem van
> Gulik (Thursday, 20 January)
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0035.html
>
> ACTION SteveH: Write up a service description of features supported for
> his service
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0113.html
>
> LOAD, FROM, GRAPH and COFFEE
> Eric Prud'hommeaux (Thursday, 27 January)
>
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0067.html
and
http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0128.html
?
>
>
> Andy, EricP, Dave, Steve, you guys have protocol implementations, right?
> I'm particularly interested in
> - any difference between what you've implemented and what's
> in WD-rdf-sparql-protocol-20050114
My implementation is by no means complete and I am expecting to change it,
including it's external appearance.
What I've implemented is "?query=...&lang=..." (paramter order does not matter)
over HTTP, and also plain GET (no query string). I use various HTTP error codes
as I saw a match at the time, including:
400 Bad request
A query parsing error becomes bad request.
405 Method Not Allowed
(attempt to update a model marked immutable - not relevant here)
500 Internal Server Error :-(
501 Not Implemented is used for "No Such Query Language" (hmm - dubious)
This is close to:
http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0046.html
I haven't implemented "graph-uri=" (I intend to and I would if it is in the
protocol) but queries can have WITH/FROM.
"lang=" helps, if its a model-centric view, but I don't have any reservations
with the service-oriented view with service instance implying query language.
i.e. no "lang="
Result formats:
Graphs: Content negotion for RDF/XML, N3, Turtle or N-triples.
Result sets:
Streamed XML.
>
> - anything in your own design/implementation/service that
> feels unresolved
I implement as a servlet inside a standard servlet container and so the "?" and
"&" form is more natural and there is support for this in the servlet API.
Joseki explicitly controls the cache headers in the HTTP response as it's a
query string URL. Not much experince here - usually it runs with no caching.
>
> - what you think is the right amount of service description stuff
> to try to standardize
There are various dimensions: maybe we can separate them:
Invokation of service:
I'd like to see at least a common single invokation use of HTTP
"&query=..." is fine. A more dynamic and more complex one (or extension)
as well is OK providing the basic "this will work anywhere" one is available.
Query Language Capabilities:
e.g. language/syntaxes, what extensions functions ara available.
Data characteristics:
Ontologies used
Definitive for ...
A critical factor for me is what is a necessary requirement on an implementer
and what is helpful. I think the minimum is the minimal case of invokation (a
document that describes how to connect universally). After that, we can propsoe
a vocabulary with all sorts of things (Dublin Core like - nothing too big) -
that's an optional part if invokation does not depend on it - people use it, or
develop their own as they see fit.
Andy
Received on Friday, 25 February 2005 14:07:10 UTC