- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 21 Feb 2005 13:36:27 +0000
- To: Dan Connolly <connolly@w3.org>
- CC: Kendall Clark <kendall@monkeyfist.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
Dan Connolly wrote: > 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... Joseki does - I don't see this a reason to include it though and the "one service - one syntax" is adequate. I currently see Joseki2 => Joseki3 as migration - not compatibility. A minimal, simple widespread service, one that can easy to built into code, would be valuable to the semantic web - I am not convinced that a more complex design, which may well reduce the similarity in different services, outweighs that. Andy > > >>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
Received on Monday, 21 February 2005 13:42:37 UTC