Re: protocol: updated (radically changed) draft

On Mon, Nov 22, 2004 at 02:55:44PM +0000, Seaborne, Andy wrote:
> 
> 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?

Because having something like the abstract protocol makes sense if
someone's going to do anything other than HTTP.

But I forked this simpler version precisely to judge where the WG
consensus will most quickly be found, so I'm open to pushing hard on
the simpler version as a real WG draft.

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

No, I don't think this is correct. At least, not for non-HTTP
bindings, which I still care about. That getGraph is trivial is a fact
about HTTP; it may not be trivial for another protocol and should be
part of the abstract protocol.

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

Yes, I just haven't put that in yet. I agree as to its
utility. Frankly, I'm trying to figure out the big picture first --
which draft should I work on, the simple or the complex -- before
focusing on details like this.

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

I intend to field a server that supports > 1 query language.

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

You've insisted that we drop getTriples, repeatedly. I don't,
therefore, see the point of debating its details...Am I missing something?

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

I don't agree. I give examples of  model and service-centric
implementations for each operation; or I intended to, anyway.

GET /foo.rdf
GET /qsp?g=foo.rdf

and so on.

> We should pick one - service centric is fine.  

I don't agree, as I've said.

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

I don't follow this.

> 2. getGraph
> 
> In these examples, requests are directed to a query processor

No, that's simply false. 2.2 is directed to a graph.

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

I don't agree; and I had different guidance from our chair.

> And the HTTP stuff applies to all operations.

I'm not sure that's correct; at least, there is some interaction
between query forms (ASK, SELECT, DESCRIBE, CONSTRUCT) and con-neg
which I think is worth noting.

> getGraph does have:
> 
> Sparql: distinct,stream,limit=10
> 
> which I don't understand the intention of:

I couldn't decide which header form I preferred, and I agree that's
not the best example.

> - How can getGraph need distinct?

It can't. That's a bug. Can't I get some "gee, this is a v. early
draft" love?! :>

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

Just trying to prompt discussion about our streaming design objective, Andy.

> - What is limit applied to?  Triples?

Another bug. Limit doesn't belong on getGraph operations.

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

or application/x-turtle or text/n3 or ...

> There isn't a media type that identifies a query result.

Correct. That's not clear.

In case it isn't clear, I'm trying to punt on as many details as
possible until it can be determined which draft has the best chance of
consensus. I heard some folks seeming to prefer the first draft (Jos?,
Janne? me), and I've heard some other folks (Andy and Dan) prefer the
second, forked draft. I'm not sure which one Tom Adams or Dave Beckett
or *anyone else* prefers.

Kendall
-- 
Sometimes it's appropriate, even patriotic, to be ashamed
of your country. -- James Howard Kunstler

Received on Monday, 22 November 2004 15:44:59 UTC