W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: SPARQL 1.1 Protocol formats

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Tue, 02 Mar 2010 17:04:23 +0000
Message-ID: <4B8D4517.7000906@talis.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
CC: Gregory Williams <greg@evilfunhouse.com>, dcharbon@us.ibm.com, SPARQL Working Group WG <public-rdf-dawg@w3.org>


On 01/03/2010 4:26 PM, Lee Feigenbaum wrote:
> On 2/27/2010 11:19 PM, Gregory Williams wrote:
>> David,
>>
>> I stumbled upon what I think is an issue with the protocol document
>> while trying to respond to a comment about service descriptions.
>>
>> It would be nice if the protocol doc talked about the serialization
>> format for CONSTRUCT/DESCRIBE queries in a bit more detail. The only
>> construct query example in the draft uses Turtle in the response, but
>> there's no text discussing this. Section 2.1.1.2 indicates that
>> RDF/XML and application/sparql-results+xml are the only explicitly
>> supported formats, but other RDF serializations are also acceptable.
>>
>> Again in section 2.1.1.2, an Out Message is described as optionally
>> being "an equivalent RDF graph serialization" to RDF/XML, but there's
>> no indication whether this ought to align with Accept headers in the
>> HTTP bindings (perhaps this is discussed somewhere that I've
>> overlooked?). I'm left thinking that an implementation could always
>> return RDF in a non-standard, non-RDF/XML format, even if RDF/XML is
>> the only format requested (or if no explicit format is requested),
>> and still be conformant. Have I understood that correctly?
>
> The intention is definitely to follow standard HTTP content negotiation
> processes (i.e. honor the Accept header).
>
> The spec says:
>
> """
> An Informative Note About Serialization Constraints. The output
> serialization of the queryHttpGet and queryHttpPost bindings is
> intentionally under constrained in order to reflect the variety of
> serialization types of RDF graphs. The fault serialization of
> queryHttpGet and queryHttpPost is also intentionally under constrained.
> A conformant SPARQL Protocol service can provide alternative WSDL
> interfaces and bindings with different constraints.
> """
>
> ...which gives a bit of motivation but doesn't directly address Greg's
> concern.
>
> I don't think the protocol spec. specifically says "honor the accept
> header", though I'm wondering if the WSDL HTTP adjunct says this. Let's
> see.
>
> Looking through http://www.w3.org/TR/wsdl20-adjuncts/, I find normative
> text that says that a serialization must be one of the formats specified
> in the WSDL. (we specify SPARQL XML, RDF/XML, and */*, so that's moot
> for our purposes). I do _not_ see anything which gives advice on how to
> choose between multiple serialization formats - i.e. nothing in the HTTP
> binding text says "use content negotiation to choose between candidate
> serialization formats".
>
> So... I think it would be worthwhile to clarify this, at least
> informatively?

Agreed - content negotiation should apply.

	Andy

>
> Lee
>
>> thanks, .greg
>>
>>
>>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
Received on Tuesday, 2 March 2010 17:04:54 GMT

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