Re: A question - use 301 instead of 406?

John Erickson wrote:
> Thank you Richard for that email; I think in making this
> observation/asking this question you've pointed out the subtle role
> that the "generic document" plays, esp (from
> http://www.w3.org/TR/cooluris/#r303gendocument):
>
> "...This has the advantage that clients can bookmark and further work
> with the generic document. A user having a RDF-capable client could
> bookmark the document, and mail it to another user (or device) which
> then dereferences it and gets the HTML or the RDF view..."
>   
I think most important of all, we now have a Generic Document URL (a 
kind of URI) and a Generic HTTP URI (an pure Identifier).

The Identifier is what Identifies the Subject of a Description.  A 
Generic URL can act as a place holder location for accessing a Subject's 
description in a variety of  data representations or formats.

All in all, we are getting closer to coherently explaining that the Web 
of Linked Data tweak is all about: Structured Documents  that explicitly 
Describe "Things", unambiguously.  You have a Document, an unambiguously 
identified Subject (its primarytopic), and a constellation of 
characteristics that coalesce around the Subject via Attribute=Value 
pairs (basically making a 3-tuple or triple once you align the pairs to 
Subject).

Kingsley
> John
>
> On Fri, Mar 26, 2010 at 9:22 AM, 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.
>>>
>>>
>>>       
>>
>>     
>
>
>
>   


-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Friday, 26 March 2010 15:11:49 UTC