Some protocol & service description issues

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.

(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 Tuesday, 25 January 2005 14:43:31 UTC