Re: Some protocol & service description issues

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

Please factor in the caching mechanisms of an application programmer reading a 
spec for the service instance of interest and writing the parameter names into 
the code.

	Andy

> 
> (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.)
> 
> 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, 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
>

Received on Wednesday, 26 January 2005 17:35:32 UTC