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

> 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.
>

Ok, I see two concrete editorial suggestions in the mails:

1) suggested text (in SD specification) to fix ambiguity on GET without parameters:

> >>> "[...] should return a service description document at the
> >> service endpoint when dereferenced using the HTTP GET operation
> >> without any query parameter strings provided"

PROPOSED: implement this change

2) suggestion to align terminology between protocol and GSP:

> >>
> >> """
> >> 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.
> >> """

PROPOSED: make resolution to publish protocol and GSP contingent to the editors to align
terminology and give them respective actions to cross-review and agree on the changes.

Anything else?
Axel



> -----Original Message-----
> From: Sandro Hawke [mailto:sandro@w3.org]
> Sent: Dienstag, 09. Oktober 2012 15:45
> To: Polleres, Axel; SPARQL WG
> Subject: Re: Ambiguity between SPARQL 1.1 RDF protocol query
> via GET and SD retrieval
>
> 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:55:45 UTC