Re: Recommendations for serving backlinks when having hash URIs?

Richard Cyganiak wrote:
> Hi Nathan,
> 
> On 10 Feb 2010, at 13:57, Nathan wrote:
>>> I'd recommend:
>>>
>>> <foo27#bar1> rdfs:seeAlso <slashland/foo27/bar1> .
>>>
>>> and then perform standard (non-redirect) content negotiation at
>>> <slashland/foo27/bar1>, with variants at <bar1.rdf>, <bar1.html> etc.
>>>
>>
>> Just wondering about the note on "non-redirect" content negotiation; it
>> was my understanding that you'd have to server the following HTTP status
>> codes under each scenario:
>>
>>  300 (Multiple Choices) if no Accept header is given.
>>  303 (See Other) if an Accept header is given and a match is found.
>>  406 (Not Acceptable) if an Accept header is not matched successfully.
> 
> Not quite.
> 
> See here for details on “normal” content negotiation:
> 
> http://www.w3.org/TR/cooluris/#conneg
> 
> About 300 and 406: A server *may* respond with 300 or 406 under the
> circumstances you describe above, but it *may* also just send a default
> representation back to the client. That's because the Accept header is
> just a statement of preference by the client, and it's up to the server
> wether it wants to consider those preferences.
> 
> About 303: You are conflating two things. Content negotiation is about
> serving *multiple* representations of a resource from a single URI. 303
> redirects are about resolvable URIs for things that have *no*
> representations because they exist outside of the Web. The 303 redirect
> guides the client to a related document that describes the non-Web thing.
> 
> In Linked Data setups, those related documents at the destination of the
> 303 redirect often have multiple representations, and hence content
> negotiation enters the picture. This is described in Section 4.2 of the
> document above. And actually, 303 and content negotiation are sometimes
> combined in just a single step, see Section 4.3 of that document. This
> is the setup that you see for example on DBpedia.
> 
> To see normal content negotiation in action, try requesting
> http://httpd.apache.org/docs/2.1/logs.html
> with different values for the "Accept-Language" header, e.g.
> "en" -- you get English
> "ja" -- you get Japanese
> "de" -- you get English because it doesn't have German
> "en,ja" -- you get English because the server decides so
> no header -- you get English because the server decides so
> 
> Hope that clarifies things.
> 

yup my mistake; was thinking of owl:sameAs to say that the slash uri was
another identifier for a RWO, when the convo was really about a
rdfs:seeAlso where the slash uri was the url or a resource which
described the thing. Thus yeah normal 200 w/ Content-location or 302 w
Location fits the bill.

interested to here more opinions on the "*may* also just send a default
representation back to the client. That's because the Accept header is
just a statement of preference by the client" comment though; because
obviously if people did this for dereferenced URIs and just fired back a
generic html page regardless (or worse) then the whole linked data thing
would fall apart (surely)?

I'd always taken the meaning of sentences in the http 1.1 rfc like:
"if the server cannot send a response which is acceptable according to
the combined Accept field value, then the server SHOULD send a 406 (not
acceptable) response."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
to mean that's what you should do, not "you may do whatever you want"

ps: last sentence may sound a bit like a personal attack, but it's not,
unsure how else to word it! :)

Many Regards,

Nathan

Received on Wednesday, 10 February 2010 17:27:12 UTC