Re: protocol: updated (radically changed) draft

Kendall Clark wrote:
> Folks,
> 
> I've decided to pretend as if I believe that doing something too
> simple in the protocol space will result in something *actually useful
> and interesting* much sooner than trying to do something interesting
> right now. 

Good idea.  How about turning the HTTP concrete part into a working draft as 
quickly as possible and working on the overall abstractions on a different 
timescale?

> 
> I don't actually believe this, but I'm going to try it on for size.
> 
> So I've published a new draft of my protocol document that:
> 
>    - removes 5 of the 7 methods, leaving on query and getGraph

I still have a concern about getGraph: either its plain GET and does not need 
specifying (case where the graph is at the location of its name; modelcentric 
view of teh world)) or it is a query language request just like any other 
(servic centric view of the world).  More below.

I also have an issue about multiple query languages served by one query service. 
  There is no way to differentiate incoming requests a to what language there 
are in without the request dispatcher needing to understand each and every 
parameter.

I'd like a "lang=" parameter to allow one service to be able to handle requests 
in different query languages.  The service can receive a request, decide which 
(internal) processors it is for and dispatch it without the service handler 
needing to grok the contents of the q= string, for example.  And some queries 
are syntactically legal SPARQL and RDQL.

It may well be more normal to have one service per query languge but a 
non-mandatory parameter would be helpful.

>    - removes all talk of discovery, advertisement, and WSDL
>    - hardcodes (gag!!!) query parameters

The parametrs aren't listed:  I found:

"g"       uri of the data graph ; may be repeated
"q"       query string
"q-uri"   the query is a document somewhere.
   Pesumable should be a URL as this is the HTTP binding.

but there are other parameters in the HTTP header:
   distinct, stream, limit.

I propose that there is one place for parameters - in the query string.  Only 
limit seems to serve a purpose.


The use of "g" is overloaded: in getTriples it results in a multi-part MIME 
retrune, one part per graph, which is like a query over each of the named 
graphs.  But in the SPARQL example, there is a single query over the named 
collection.

The document talks about being neutral to service-centric and model-centric 
viewpoints but I don't think it is - I think (the HTTP binding at least) is 
purely service-centric.  We should pick one - service centric is fine.  What 
distinguishes the two cases are:

+ a plain GET on the processor URL
+ whether a graph URI is often found in the request URL.

The examples would all require a "g=" parameter but the data graph may be 
implicit in some services - can still be a named collection of graphs at the 
service access point.


Section 7, examples:

1.4 example of ASK query:

Shouldn't that return something in the body?  Using Return code 200 for ASK=>yes 
does not work well as 200 means operation executed successfully, with no 
reference to the outcome data at the operation level.  An ASK of "no" is a 
successful operation with answer "no".

2. getGraph

In these examples, requests are directed to a query processor - this makes GET a 
query language like any other.  if theer is a "lang=", its just a query language 
in requests as well.


It would be better to defer to normal, regular HTTP documentation here and not 
examine the use of content negotation, encoding or charset - it really should be 
regular, off-the-shelf HTTP here.  Nothing worth noting surely?  And the HTTP 
stuff applies to all operations.


getGraph does have:

Sparql: distinct,stream,limit=10

which I don't understand the intention of:

- How can getGraph need distinct?
- RDF/XML does not stream by default - or it does, what does it mean and isn't 
it a significant burden on the implementer of the serializer.
- What is limit applied to?  Triples?

- - - - - -

One thing did jump out:

"""
Query Result IMT
     The Internet Media Type of a Query Result.
"""

Isn't it that the media type is application/xml or application/rdf+xml?  There 
isn't a media type that identifies a query result.

	Andy


> 
> In other words, I've forked myself -- a sure sign of insanity. :>
> 
> If nothing else, having 2 v. different but obviously related drafts
> should give the WG something to straw poll, so that we can figure out
> where the hell we are.
> 
> Hence, the new version (1.7) of the protocol is available at
> 
>        http://monkeyfist.com/kendall/sparql-protocol-simplex/
> 
> While the older, fuller (and more interesting!) version of the
> protocol is (and will remain) available at
> 
>        http://monkeyfist.com/kendall/sparql-protocol/
> 
> Best,
> Kendall Clark

Received on Monday, 22 November 2004 14:56:33 UTC