- From: Dan Connolly <connolly@w3.org>
- Date: Fri, 18 Feb 2005 15:28:31 -0600
- To: Kendall Clark <kendall@monkeyfist.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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