W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2005

Re: preparing for protocol discussion

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Fri, 25 Feb 2005 14:06:31 +0000
Message-ID: <421F30E7.9080109@hp.com>
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
>  Eric Prud'hommeaux (Thursday, 27 January)
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0067.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:

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.

Received on Friday, 25 February 2005 14:07:10 UTC

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