Re: Some protocol & service description issues

On Tue, 2005-01-25 at 09:40 -0500, Kendall Clark wrote:
> Folks,
> 
> We kicked this issue around in Espoo, especially related to our
> service description language modeling efforts. I'm not sure I
> understand what the best opportunity for consensus is, but presently
> in the protocol document we've published, the design looks something
> like this (in the HTTP binding):
> 
> 1. queries are named by a "query" parameter
> 2. the type of query is named by a "query-lang" parameter, the value
>    of which is a URI that identifies the query language; there is no
>    list of such URIs nor short names in the document presently
> 3. if "query" is present, "query-lang" *must* be present too

As far as I know, nobody is currently doing this query-lang=http://....
bit...

> One of the designs I can remember being proposed or discussed in Espoo
> was to "overload" (for lack of a better term) a single parameter, such
> that it conveyed the semantics of the present "query" and
> "query-lang". In other words, this design proposes a single parameter,
> the name of which indicates the query language type, and the value of
> which is (presumably) a legal sentence of that query language. For
> example, "sparql" or "rdql".

Right... I just got around to sorta writing it up...

 sparqlParam: an approach to QL selection/migration
http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0167.html

It avoids sending a URI to identify the QL in every GET
request, in favor of a slightly more complicated "binding time"
design.

Meanwhile, it's not clear that the "one service that supports
two syntaxes" requirement is still a requirement. Steve seems
to have reconsidered it.

"At the Helsinki FTF I was in favour of supporting single service URIs
that
allowed query with a variety of syntaxes, mainly to prevent duplication of
query service descriptions, but since then I've reconsidered and I now
prefer something where each distinct query URI supports a specific query
syntax."
 -- http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0113.html

The simplest thing might be to just use distinct service URIs for
distinct query syntaxes.


> Further, the identity of this string would be encoded in the service
> description and would have to be discovered (at least once) by
> requesters wishing to convey queries to that service; presumably,
> though we cannot enforce this, it would be a good practice for that
> parameter name to change as infrequently as possible. Further, again
> presumably, the parameter name could be cached by requesters, subject
> to the ordinary caching and resource-freshness issues vis-a-vis HTTP.
> 
> (Putting my WG member hat back on for a second, I'm not sure why
> discovering this *one* parameter name is good, but discovering other
> parameter names is somehow a bad design. Will have to chew on that one
> further, I guess.)

Discovering other parameter names for similar purposes seems fine.
What I argued against was discovering parameter names where
the choice of parameter name had no significance to the protocol.

> I believe the other designs discussed in Espoo are variations --
> different parameter names, as I recall -- of the design in the present
> protocol document.
> 
> Finally, various WG members took ACTIONs to work on (parts of) an RDF
> vocabulary for describing provisioning and service details of SPARQL
> query processors and queryable RDF graphs. I believe there was
> consensus that such a language should be included as part of the
> protocol document. 
> 
> Accordingly, and in order to provide a *bit* of coordination, I'm
> adding a section to my private draft of that document, which I'll
> update publicly by Friday,

I'm looking forward to it.

>  called "SPARQL Protocol Description Language"
> and using the acronym "SPDL" for that vocabulary. YMMV, of course, and
> I welcome other suggestions and feedback.
> 
> Best,
> Kendall Clark
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Friday, 18 February 2005 21:28:33 UTC