W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2012

Re: Ambiguity between SPARQL 1.1 RDF protocol query via GET and SD retrieval

From: Sandro Hawke <sandro@w3.org>
Date: Tue, 09 Oct 2012 09:45:13 -0400
Message-ID: <50742A69.9030606@w3.org>
To: "Polleres, Axel" <axel.polleres@siemens.com>, SPARQL WG <public-rdf-dawg@w3.org>
On 10/09/2012 03:29 AM, Polleres, Axel wrote:
> Hi,
>
> @sandro, is it ok to fix editorial things like aligning wording and maybe putting in some anchors
> to cross-references terminology in the last transition from PR to Rec still?

Yes, it's okay to make editorial improvements at every stage.    I think 
we still have time to fix it before PR, though:procedurally, we'll have 
about 10 days between the decision to publish [hopefully today] and 
actually publishing.

I know groups differ in how much they want the document to be frozen 
when they make the decision -- many groups make the decision to publish 
"pending implementation" of specific changes, reviewed by the chairs or 
other chosen people.

    -- Sandro

> Axel
>
>
>> -----Original Message-----
>> From: Gregory Williams [mailto:greg@evilfunhouse.com]
>> Sent: Montag, 08. Oktober 2012 18:41
>> To: Chime Ogbuji
>> Cc: SPARQL Group
>> Subject: Re: Ambiguity between SPARQL 1.1 RDF protocol query
>> via GET and SD retrieval
>>
>> On Oct 6, 2012, at 1:07 PM, Chime Ogbuji wrote:
>>
>>> While porting over my implementation of the SPARQL 1.1 RDF
>> protocol, I noticed that the language in the Service
>> Description specification about how a service description
>> document is dereferenced is a bit ambiguous.
>>> "SPARQL services made available via the SPARQL Protocol
>> should return a service description document at the service
>> endpoint when dereferenced using the HTTP GET operation"
>>> Whereas the SPARQL 1.1 RDF Protocol document says:
>>>
>>> "Protocol clients may send protocol requests via the HTTP
>> GET method. When using the GET method, clients must URL
>> percent encode (http://www.ietf.org/rfc/rfc3986.txt) all
>> parameters and include them as query parameter
>> (http://www.ietf.org/rfc/rfc3986.txt) strings with the names
>> given above"
>>> Under the query string parameters column for this binding
>> it says: "query (exactly 1)".
>>> Unless I've missed text elsewhere that clarifies this,
>> reading both as they are written begs the question about
>> whether a query via GET binding request SHOULD return an SD
>> document. My assumption is that the distinction is between a
>> GET request to the service endpoint *without* a query
>> parameter versus a request *with* this parameter - returning
>> an SD document if the query parameter is not provided.
>>> This distinction should be made explicit. Some suggested
>> text (in SD specification):
>>> "[...] should return a service description document at the
>> service endpoint when dereferenced using the HTTP GET
>> operation without any query parameter strings provided"
>>
>> I agree that the language here could be made better by being
>> more specific. In looking this over, I also noticed that the
>> terminology between the two documents has drifted a bit
>> (which is a bit embarrassing since I edited both). SD says:
>>
>> """
>> A SPARQL [Protocol] service is commonly referred to as a
>> "SPARQL endpoint".
>> """
>>
>> while Protocol has two different definitions for "Service"
>> and "Endpoint":
>>
>> """
>> SPARQL Protocol service
>> An HTTP server that services HTTP requests and sends back
>> HTTP responses for SPARQL Protocol operations. The URI at
>> which a SPARQL Protocol service listens for requests is
>> generally known as a SPARQL endpoint. (Also known as: service)
>>
>> SPARQL endpoint
>> The URI at which a SPARQL Protocol service listens for
>> requests from SPARQL Protocol clients.
>> """
>>
>> Does anyone (esp. chairs) think fixing this before the
>> upcoming publication would be a problem (or perhaps it's
>> something that could be fixed post-publication)? I don't
>> think fixing this is a substantive change as I believe the
>> spec text, examples, and tests are all pretty clear about
>> what is meant, but certainly don't want to cause problems for
>> anyone who thinks otherwise.
>>
>> thanks,
>> .greg
>>
>>
>>
Received on Tuesday, 9 October 2012 13:45:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:49 GMT