Re: Extending redirects to suggest updated locations ?

hi Willy, all,

It strikes me that the Memento approach can be useful in this scenario.

For information on Memento, see http://mementoweb.org . A quick intro is
available at  http://www.mementoweb.org/guide/quick-intro/ . Work is ongoing
to compile a first version of an Internet Draft that specifies the Memento
framework. If all goes well, it should be possible to share it with this
last in a few weeks time.

A. Here is how Memento could be leveraged for this scenario, in 2 different
cases:

Case 1: A URI-minting strategy is used in which (as is the case with many
specification, cf W3C specs)
- the current version is always at the same generic URI,
- each version gets its own URI

In this case:

1.1) An old version of the software provides a HTTP Link header with a
"original" Relation Type and a Context IRI of that generic URI.
1.2) A client interested in the current version follows that "original"
link.
1.3) The current version (at generic URI) provides a HTTP Link header with a
"timegate" Relation Type and a Context IRI of a resource that supports
datetime content negotiation.
1.4)  A client interested in a version as it existed at some other point in
time, follows the "timegate" link, and uses that time as the value for
datetime content negotiation n (conveyed in the Content-Datetime request
header) and is 302-ed to the version that was the current one at the
specified datetime.
1.5) That version advertizes its version datetime by including a
Memento-Datetime header, the value of which is the datetime of the
version. A current version never has a Memento-Datetime header. Only old
versions do.

Note that this approach is used to datetime-navigate between versions of
DBpedia descriptions. For info, see the paper http://arxiv.org/abs/1003.3661


Case 2: No URI-minting strategy as in Case 1 is used

In this case:

2.1) An old version of the software advertizes it is old by including a
Memento-Datetime header, the value of which is the datetime of the
version. A current version never has a Memento-Datetime header. Only old
versions do.
2.2) An old version of the software provides a HTTP Link header with a
"timegate" Relation Type and a Context IRI of a resource that supports
datetime content negotiation.
2.3) A client interested in the current version follows the "timegate" link,
and uses the current time as the value for datetime content negotiation
(conveyed in the Content-Datetime request header) and is 302-ed to the
current version of the software.
2.4)  A client interested in a version as it existed at some other point in
time, follows the "timegate" link, and uses that time as the value for
datetime content negotiation and is 302-ed to the version that was the
current one at the specified datetime.

B. In addition to the Memento datetime navigation capabilities, and the
Relation Types introduced by Memento (the aforementioned ones, and some
others), Relation Types with more semantic specificity could be used to
fully convey the semantics your scenario requires. RFC5829 comes to mind,
but one could imagine defining even more specific ones.

Greetings

Herbert Van de Sompel

-- 
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/