RE: A question - use 301 instead of 406?

Hello

Just chipping in from a publisher's perspective. The /data and /page thing on DBpedia always confused me a little. It seemed to make the assumption that there was only one page (desktop html) and only one data view (RDF).

On bbc /programmes we have 2 pages (desktop html using http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd and mobile html using http://www.wapforum.org/DTD/xhtml-mobile10.dtd) as well as numerous data views (rdf xml, ical, json, yaml, vanilla xml, xspf...)

We only ever want users to see and work with the generic document uri. So if a user bookmarks html on a desktop machine they can access that bookmark on a mobile and get an appropriate representation. Similarly if they email a document uri from a mobile to a friend on a desktop machine. And by extension if that friend prefers rdf then we should serve that at the same generic uri

We use hash rather than slash uris so sidestep the 303 problem but still set content location headers to point to the actual document representation uris (.html, .rdf...)

Personally I think the 2nd pattern (303 URIs forwarding to Different Documents) breaks the whole rest / one web thing and I'd much rather see the linked data community promoting pattern 1 (303 URIs forwarding to One Generic Document (with content location headers))

Not sure if this adds anything except there's more to life than desktop html and rdf ;-)


-----Original Message-----
From: public-lod-request@w3.org on behalf of John Erickson
Sent: Fri 3/26/2010 1:49 PM
To: Richard Cyganiak; Hugh Glaser; Linking Open Data
Subject: Re: A question - use 301 instead of 406?
 
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..."

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.
>>
>>
>
>
>



-- 
John S. Erickson, Ph.D.
http://bitwacker.wordpress.com
olyerickson@gmail.com
Twitter: @olyerickson



http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.