Re: RDF Update Feeds + URI time travel on HTTP-level

2009/11/23 Mark Baker <distobj@acm.org>:
> On Sun, Nov 22, 2009 at 11:59 PM, Peter Ansell <ansell.peter@gmail.com> wrote:
>> It should be up to resource creators to determine when the nature of a
>> resource changes across time. A web architecture that requires every
>> single edit to have a different identifier is a large hassle and
>> likely won't catch on if people find that they can work fine with a
>> system that evolves constantly using semi-constant identifiers, rather
>> than through a series of mandatory time based checkpoints.
>
> You seem to have read more into my argument than was there, and
> created a strawman; I agree with the above.

I did take some Literary privilege. The strawman was intended to be
knocked down in the same argument.

> My claim is simply that all HTTP requests, no matter the headers, are
> requests upon the current state of the resource identified by the
> Request-URI, and therefore, a request for a representation of the
> state of "Resource X at time T" needs to be directed at the URI for
> "Resource X at time T", not "Resource X".

The issue with requiring people to direct requests at the URI for the
Resource X at time T is that the circular linking issue I described
previously comes into play because people need to pre-engineer their
URI's to be compatible with a temporal dimension. If the user didn't
know exactly what time scales were used by the server they would
either need to follow a roughly drawn up convention, such as
/YYYY/MM/DD/meaningfulresourcename, or they would have to find an
index somewhere, neither of which are as promising for the future of
the web as having the ability to add another header to provide the
desired behaviour IMO.

The documentation of the Vary header [1] seems to leave the situation
open as to whether the server needs to be concerned about which or any
Headers dictate which resource representation is to be returned.
Caching in the context of HTTP/1.1 may have been designed to
temporary, but I see no particular reason why a temporal Accept-*
header, together with the possibility of its addition to Vary,
couldn't be used on the absolute time dimension. It seems much cleaner
than adding an extra command to HTTP, or requiring some other non-HTTP
mechanism altogether. The extra header would never stop a server from
returning the current version if it doesn't recognise the header, or
it doesn't keep a version history, so it should be completely
backwards compatible.

Cheers,

Peter

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44

Received on Monday, 23 November 2009 06:02:18 UTC