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

Herbert,

On Tue, Nov 24, 2009 at 6:10 PM, Herbert Van de Sompel
<hvdsomp@gmail.com> wrote:
> Just to let you know that our response to some issues re Memento raised here
> and on Pete Johnston's blog post
> (http://efoundations.typepad.com/efoundations/2009/11/memento-and-negotiating-on-time.html) is
> now available at:
> http://www.cs.odu.edu/~mln/memento/response-2009-11-24.html

Regarding the suggestion to use the Link header, I was thinking the
same thing.  But the way you describe it being used is different than
how I would suggest it be used.  Instead of providing a link to each
available representation, the server would just provide a single link
to the timegate.  The client could then GET the timegate URI and find
either the list of URIs (along with date metadata), or some kind of
form-like declaration that would permit it to specify the date/time
for which it desires a representation (e.g. Open Search).  Perhaps
this is what you meant by "timemap", I can't tell, though I don't see
a need for the use of the Accept header in that case if the client can
either choose or construct a URI for the desired archived
representation.

As for the "current state" issue, you're right that it isn't a general
constraint of Web architecture.  I was assuming we were talking only
about the origin server.  Of course, any Web component can be asked
for a representation of any resource, and they are free to answer
those requests in whatever way suits their purpose, including
providing historical versions.

Mark.

Received on Wednesday, 25 November 2009 05:01:52 UTC