Re: A question - use 301 instead of 406?

(Sorry, I should have given the URI of the document I quoted from:
http://tools.ietf.org/html/rfc2616.)

Yes.
Many thanks.
I had looked for just the response you describe from dbpedia, and decided
that the (since it didn't suggest the rdf URI), it probably wasn't something
that was done.
And even if it was, as the protocol "specification does not define any
standard for such automatic selection", it seemed unlikely to be easily done
automagically.
But if http://www.w3.org/ does it, then it must be good.
(And I hate misusing things, so 301 smells like a hack!)

And it doesn't tell the client to patch up, although presumably the client
is allowed to react to the 406 and "correct" the URI, probably based on the
NIR URI that comes back in the RDF.

More seriously, I can't find any support (in things like curl) for
seamlessly dealing with the implied redirection, in the same was as -L does
in curl. I am no protocol person though, so ...

Also it requires special code on the client side to handle this. But some
boiler plate code that dealt with it would facilitate.
But in our case, migrating a load of non-LD client code to LD becomes a
challenge, unless the libraries support this.

But at least we need to extend the "How to Publish" to embrace this?
At the least we should be doing what w3c.org does, suggesting the rdf URI
and maybe others.
And defining the format (for machine processing) would facilitate better
use.

We are experimenting with the 301 at the moment (Ian has put it into
rkbexplorer stuff), so if you want to see,
http://southampton.rkbexplorer.com/id/person-00021.

Best
Hugh

On 24/03/2010 08:06, "Pierre-Antoine Champin" <swlists-040405@champin.net>
wrote:

> Hi Hugh,
> 
> interesting suggestion; I have also been frustrated with dbpedia URIs in
> the adress bar, which you have to (or forget to) change when you want to
> feed them to an RDF agent...
> 
> However, 406 seems to be the most appropriate answer to give. Falling
> back to 301 in too many different situations for the sake of forgiveness
> is muddling the waters, IMHO...
> 
> I propose a middle way: the HTTP RFC [1] reads, regarding 406 responses:
> 
>> Unless it was a HEAD request, the response SHOULD include an entity
>> containing a list of available entity characteristics and location(s)
>> from which the user or user agent can choose the one most
>> appropriate.
> 
> As a matter of fact, http://www.w3.org/ complies with this
> recommandation (try to request it for image/svg, for example). It gives
> you a page with alternative representations.
> 
> I think this would be a good principle for linked data as well, as
> linked data relies heavily on Conneg. Note that if you request RDF for
> http://foo/bar.html, the server could reply with 406, but include an
> entity in RDF explaining where you can find other representations...
> Your agent could then interpret that and fetch the new URI.
> 
>   pa
> 
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7
> 
> 
> 
> On 23/03/2010 23: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 Wednesday, 24 March 2010 09:38:57 UTC