- 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