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. Cheers
On 26/03/2010 13:22, "Richard Cyganiak" <rich...@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. >> >> >
