W3C home > Mailing lists > Public > public-lod@w3.org > November 2009

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

From: Mark Baker <distobj@acm.org>
Date: Wed, 25 Nov 2009 00:01:06 -0500
Message-ID: <e9dffd640911242101w3ca40846p385eea599e9e8fc6@mail.gmail.com>
To: Herbert Van de Sompel <hvdsomp@gmail.com>
Cc: Linked Data community <public-lod@w3.org>, "Michael L. Nelson" <mln@cs.odu.edu>, Robert Sanderson <azaroth42@gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:01 UTC