Re: Content negotiation for Turtle files

Hi all

While I promised a response, time is never my friend despite best intentions.

+1 to Tim on "crispness", and on a protocol. I note that the
"content-negotiation" error which was at the core of this discussion
hasn't really been talked about, and was where I was planning to provide
comment on.

So noting the latest in the discussion, I'll fast track and suggest that
as an interim measure: (note - this is a drive by comment, and possibly at
the risk of over-simplifying:)

Cannot a lot of this discussion be solved if a server is correctly
configured to return a 300 response in these cases? ("Multiple-choice" or
"there is more than one format available Mr. Client - please choose which
one you'd like").

We can't assume that clients or users will ask for something we have, or
in a correct manner, which is the reason 300 and other responses not-often
used exist.

Cheers

Chris

> I feel we should be crisp about these things.
> Its not a question of thinking of what things kind of tend
> to enhance interoperability, it is defining a protocol
> which 100% guarantees interoperability.
>
> Here are three distinct protocols which work,
> ie guarantee each client can understand each server.
>
> A) Client accepts various formats including RDF/XML.
>   Server provides various formats including RDF/XML.
>
> B) Client accepts various formats including RDF/XML AND turtle.
>   Server provides  various formats including either RDF/XML OR turtle.
>
> C) Client accepts various formats including turtle.
>   Server provides  various formats including turtle.
>
> These may not ever have been named.
> The RDF world used A in fact for a while, but the
> Linked Data Platform at last count was using C.
> Obviously B has its own advantages but I think that
> we need lightweight clients more than we need lightweight
> servers and so being able to build a client without an
> XML parser is valuable.
>
> Obviously there is a conservative middle ground D in
> which all clients and servers support both formats,
> which could be defined as a practical best practice,
> but we should have a name for, say, C.
>
> We should see whether the LDP group will define
> a word for compliance with C.  I hope so, and then
> we can all provide that and test for it.
>
> Tim
>
> On 2013-02 -06, at 11:38, Leigh Dodds wrote:
>
>>> From an interoperability point of view, having a default format that
>> clients can rely on is reasonable. Until now, RDF/XML has been the
>> standardised format that we can all rely on, although shortly we may
>> all collectively decide to prefer Turtle. So ensuring that RDF/XML is
>> available seems like a reasonable thing for a validator to try and
>> test for.
>>
>> But there's several ways that test could have been carried out. E.g.
>> Vapour could have checked that there was a RDF/XML version and
>> provided you with some reasons why that would be useful. Perhaps as a
>> warning, rather than a fail.
>>
>> The explicit check for RDF/XML being available AND being the default
>> preference of the server is raising the bar slightly, but its still
>> trying to aim for interop.
>>
>> Personally I think I'd implement this kind of check as "ensure there
>> is at least one valid RDF serialisation available, either RDF/XML or
>> Turtle". I wouldn't force a default on a server, particularly as we
>> know that many clients can consume multiple formats.
>>
>> This is where automated validation tools have to tread carefully:
>> while they play an excellent role in encouraging consistently, the
>> tests they perform and the feedback they give need to have some
>> nuance.
>
>

Received on Monday, 11 February 2013 00:17:10 UTC