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

2009/11/24 Erik Hetzner <erik.hetzner@ucop.edu>:
> At Mon, 23 Nov 2009 00:40:33 -0500,
> Mark Baker wrote:
>>
>> 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.
>>
>> 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".
>
> I think this is a very compelling argument.
>
> On the other hand, there is, nothing I can see that prevents one URI
> from representing another URI as it changes through time. This is
> already the case with, e.g.,
> <http://web.archive.org/web/*/http://example.org>, which represents
> the URI <http://example.org> at all times. So this URI could, perhaps,
> be a target for X-Accept-Datetime headers.

This is still a different URI though, and requires you to know that
web.archive.org exists and that it has infact trawled example.org.

> There is something else that I find problematic about the Memento
> proposal. Archival versions of a web page are too important to hide
> inside HTTP headers.

The clean aspect of using headers is that you don't have to munge the
URI or attach it to the path of another URI in order to make the
process work.

> To take the canonical example, if I am viewing
> <http://oakland.example.org/weather>, I don’t want the fact that I am
> viewing historical weather information to be hidden in the request
> headers.

The user-agent could help here.

> Furthermore, I am viewing resource X as it appeared at time T1, I
> should *not* be able to copy that URI and send it to a friend, or use
> it as a reference in a document, only to have them see the URI as it
> appears at time T2.

Current web citation methods typically require that you put "Accessed
on DD MM YY" next to the URI if you want to publish it. If you were
viewing it at T1 and that wasn't the current version then your
user-agent would need to let you know that you were not viewing the
most up to date copy of the resource.

> I think that those of us in the web archiving community [1] would very
> much appreciate a serious look by the web architecture community into
> the problem of web archiving. The problem of representing and
> resolving the tuple <URI, time> is a question which has not yet been
> adequately dealt with.

It would still be nice to solve the issue in general so that we don't
have to rely on archiving services in order to get past versions if
you could do it by negotiating directly with the original server.

Cheers,

Peter

Received on Tuesday, 24 November 2009 00:14:34 UTC