Re: Some protocol & service description issues

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