Re: protocol: updated (radically changed) draft

Kendall Clark wrote:
> 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.

Fine - but that is not the same to me as a "must have" abstract protocol (i.e. 
rec track, normative).  A "being informed by" document (a note?) could be fine.

There is more deployment experience with query than with update.  We have not 
undertaken a use case/requirements analysis for update so the balance is "remote 
(read) access" now or a long wait for something grander.  I'd prefer to split up 
the part that is better understood - as you will have gathered by now :-)

 From my own personal work, the experience users have had with Joseki and update 
has not been clear cut that it is the right approach.  Indeed, most usage seems 
to be for locally distributed applications, not web scale usage and their have 
been difficulties using it for storage and editting of large ontologies.

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

Yes! - two things

1/ My comment is directed at the use of "g=" being different in different cases 
regardless of the agruement for or against getTriples.  I was noting that uses 
are different.

2/ I am not insisting on dropping getTriples.  I'm proposing that it is handled 
for HTTP by "lang=getTriples" in the case of directing a request to a service 
processor and the fact that "GET /graph" is a plain HTTP.

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

I have retrofitted the paramater semantics from the examples.  I'm guessing what 
exactly is happening.

> 
> 
>>2. getGraph
>>
>>In these examples, requests are directed to a query processor
> 
> 
> No, that's simply false. 2.2 is directed to a graph.

Sorry - missed that.

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

I had to read it to see where it was the same and where, if anywhere, it was 
different or specialized.  Give me (the reader) a clue that I can skip it.

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

I have lots of details comments as well :-)

	Andy

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

Received on Monday, 22 November 2004 16:14:44 UTC