- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Tue, 25 Jan 2005 09:40:59 -0500
- To: public-rdf-dawg@w3.org
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