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

On Wed, 25 Nov 2009, Mark Baker wrote:

> 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.

Hi Mark,

What you describe is really close to what RFC 2616 calls "Agent-driven 
Negotiation", which is how CN exists in the absence of "Accept-*" request 
headers.

12.2 Agent-driven Negotiation

    With agent-driven negotiation, selection of the best representation
    for a response is performed by the user agent after receiving an
    initial response from the origin server. Selection is based on a list
    of the available representations of the response included within the
    header fields or entity-body of the initial response, with each
    representation identified by its own URI. Selection from among the
    representations may be performed automatically (if the user agent is
    capable of doing so) or manually by the user selecting from a
    generated (possibly hypertext) menu.

    ...

RFC 2295 also permits this style of CN via the "TCN: List" response header 
semantics (generally sent with a 300 or 406 response).

But the "TCN: Choice" approach is introduced as an optimization.  The idea 
is that if you know you prefer .en, .pdf and .gz then tell the server when 
making your original request and it will do its best to honor those 
requests.

We think adding an orthogonal dimension for CN will be similar: if you 
know you prefer .en, .pdf, .gz and .20091031, then tell the server when 
making your original request and it will do its best to honor those 
requests.

In practice, agent-driven CN is rarely done (I can only guess as to why). 
In practice, you get either server-driven (as defined in RFC 2616) or 
transparent CN (introduced in RFC 2616 (well, RFC 2068 actually), but 
really defined in RFCs 2295 & 2296).  See: 
http://httpd.apache.org/docs/2.3/content-negotiation.html

  Apache supports 'server driven' content negotiation, as defined in the
  HTTP/1.1 specification. It fully supports the Accept, Accept-Language,
  Accept-Charset andAccept-Encoding request headers. Apache also supports
  'transparent' content negotiation, which is an experimental negotiation
  protocol defined in RFC 2295 and RFC 2296. It does not offer support for
  'feature negotiation' as defined in these RFCs.

In practice, Apache goes out of its way to not send back a 300 response: 
it will look at your Accept-* request preferences, compute the q-values, 
and has an elaborate tie-breaking scheme to always try to send back 
*something* (and not a 300).

Having said all of the above, the client can always force the server to 
send back a 300, along with a full list of possible URIs.  To do this, you 
simply have to send a "Negotiate: 1.0" request header, and the server will 
send back a 300/"TCN: List" response.  In the case of Memento, the URI 
list is the time map.

So while I think you are describing agent-driven CN (or something very 
similar), I also think it would be desirable to go ahead and get the full 
monty and define the appropriate Accept header and allow server-driven & 
transparent CN.  Agent-driven CN is still available for clients that wish 
to do so.

regards,

Michael

>
> 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.
>

----
Michael L. Nelson mln@cs.odu.edu http://www.cs.odu.edu/~mln/
Dept of Computer Science, Old Dominion University, Norfolk VA 23529
+1 757 683 6393 +1 757 683 4900 (f)