W3C home > Mailing lists > Public > public-lod@w3.org > March 2010

Re: A question - use 301 instead of 406?

From: Hugh Glaser <hg@ecs.soton.ac.uk>
Date: Sun, 28 Mar 2010 22:41:08 +0000
To: Richard Cyganiak <richard@cyganiak.de>
CC: Linking Open Data <public-lod@w3.org>
Message-ID: <EMEW3|77a42ef22d623fbb8dda5d173d3a7cdem2RNfa02hg|ecs.soton.ac.uk|C7D59992.112C1%hg@ecs.soton.ac.uk>
I think the answer is yes, but need to ponder.
(And I see Michael Smethurst is of this opinion.)
As people like Tom know, I've never much liked 303, but did it because I
think that fragmenting tiny communities doesn't help!
On the other hand, I find hash pretty ugly.
But perhaps not quite as ugly - looks like TimBL scores again.

On 26/03/2010 13:22, "Richard Cyganiak" <richard@cyganiak.de> wrote:

> Hi Hugh,
> Thinking more about this, I'm resetting to the start of the thread and
> I have a question for you.
> The Cool URIs for the Semantic Web document, which is perhaps the
> canonical reference for the 303/conneg style of linked data
> publishing, lists two different design patterns for using 303
> redirects with slash URIs:
> 1. 303 URIs forwarding to One Generic Document
> http://www.w3.org/TR/cooluris/#r303gendocument
> 2. 303 URIs forwarding to Different Documents
> http://www.w3.org/TR/cooluris/#r303uri
> AFAIK, RKBexplorer, like DBpedia and many other linked data sites,
> implement the second approach. When we tried to get the document
> through the TAG, TimBL insisted that the first approach is better and
> should come first in the Cool URIs document. So we did that. But the
> second approach was already deployed and has captured most of the
> mindshare and still is the default today, and the first approach has
> never really caught on.
> My question for you: Does the first approach solve your problem? By
> always 303ing to a generic document, you'd see a document URL in the
> browser bar that could respond with either HTML or RDF. The variant-
> specific URIs would still be there but not be used in typical HTTP
> interactions. Does this solve the issue that motivated you here?
> Best,
> Richard
> On 23 Mar 2010, at 22:50, Hugh Glaser wrote:
>> I am not sure I even dare ask this, but here goes.
>> (This is prompted by a real application implementation - it is not
>> just a
>> hypothetical.)
>> Assuming that we are in the usual situation of http://foo/bar doing
>> a 303 to
>> http://foo/bar.rdf when it gets a Accept: application/rdf+xml http://foo/bar
>> what should a server do when it gets a request for
>> Accept: application/rdf+xml http://foo/bar.html ?
>> OK, the answer is 406.
>> But is this compatible with the principle of being as forgiving as
>> possible
>> as a server?
>> I think it is clear what the agent wanted:
>> Accept: application/rdf+xml http://foo/bar
>> it is just that somehow the wrong URI got into the system.
>> I know I have made the mistake of for example copying a dbpedia URI
>> from the
>> address bar when I was looking for the LD URI, and ended up
>> wondering for a
>> moment why
>> Accept: application/rdf+xml http://dbpedia.org/page/Tim_Berners-Lee
>> gives me a 406 before I remember I need to right click on the About
>> and copy
>> the link.
>> That's OK if all that happens is I use the wrong URI straight away.
>> But what happens if I then enter it into a form that requires a LD
>> URI, and
>> then perhaps goes into a DB, and becomes a small part of a later
>> process?
>> Simply put, the process will fail maybe years later, and the
>> possibility and
>> knowledge to fix it will be long gone.
>> Maybe the form validation is substandard, but I can see this as a
>> situation
>> that will recur a lot, because the root cause is that the address
>> bar URI
>> changes from the NIR URI. And most html pages do not have links to
>> the NIR
>> of the page you are on - I am even told that it is bad practice to
>> make the
>> main label of the page a link to itself - wikipedia certainly doesn't,
>> although it is available as the "article" tab, which is not the
>> normal thing
>> of a page. SO in a world where wikipedia itself became LD, it would
>> not be
>> clear to someone who wanted the NIR URI where to find it.
>> So that is some of the context and motivation.
>> If we were to decide to be more forgiving, what might be done?
>> How about using 301?
>> <<Ducks>>
>> To save you looking it up, I have appended the RFC2616 section to this
>> email.
>> That is
>> Accept: application/rdf+xml http://foo/bar.html
>> Should 301 to http://foo/bar
>> It seems to me that it is basically doing what is required - it
>> gives the
>> client the expected access, while telling it (if it wants to hear)
>> that it
>> should correct the mistake.
>> One worry (as Danius Michaelides pointed out to me) is that the
>> caching may
>> need careful consideration - should the response indicate that it is
>> not
>> cacheable, or is that not necessary?
>> So that's about it.
>> I am unhappy that users doing the obvious thing might get frustrated
>> trying
>> to find the URIs for heir Things, so really want a solution that is
>> not just
>> 406.
>> Are there other ways of being nice to users, without putting a serious
>> burden on the client software?
>> I look forward to the usual helpful and thoughtful responses!
>> By the way, I see no need to 301 to http:/foo/bar if you get a
>> Accept: text/html http://foo/bar.rdf as the steps to that might lead
>> to this
>> would require someone looking at an rdf document to decide to use it
>> as a
>> NIR, which is much less likely. And the likelihood is that there is an
>> eyeball there to see the problem.
>> But maybe it should?
>> Best
>> Hugh
>> 10.3.2 301 Moved Permanently
>>   The requested resource has been assigned a new permanent URI and any
>>   future references to this resource SHOULD use one of the returned
>>   URIs.  Clients with link editing capabilities ought to automatically
>>   re-link references to the Request-URI to one or more of the new
>>   references returned by the server, where possible. This response is
>>   cacheable unless indicated otherwise.
>>   The new permanent URI SHOULD be given by the Location field in the
>>   response. Unless the request method was HEAD, the entity of the
>>   response SHOULD contain a short hypertext note with a hyperlink to
>>   the new URI(s).
>>   If the 301 status code is received in response to a request other
>>   than GET or HEAD, the user agent MUST NOT automatically redirect the
>>   request unless it can be confirmed by the user, since this might
>>   change the conditions under which the request was issued.
>>      Note: When automatically redirecting a POST request after
>>      receiving a 301 status code, some existing HTTP/1.0 user agents
>>      will erroneously change it into a GET request.
Received on Sunday, 28 March 2010 22:42:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:20:58 UTC