Subject: [core] declaring default Context IRI for links in application/link-format documents

From: Herbert van de Sompel <[email-masked]>
Date: Fri, 8 Apr 2011 16:37:53 -0600

Hi all,

I have posted to this list before regarding the use of
application/link-format documents in the context of the Memento (Time Travel
for the Web) framework (see
https://datatracker.ietf.org/doc/draft-vandesompel-memento/ and
http://mementoweb.org).

In Memento, we have come across a problem that we think you also have in the
CoRE effort, and that we assume others would have that want to
leverage application/link-format type documents: the real Context IRI for
links expressed in these documents is implicit and can only be understood by
applications that are specialized in processing a certain kind
of application/link-format documents, e.g. CoRE-specific or Memento-specific
processors.

In Memento, a typical application/link-format document, which we call a
TimeMap looks like this:

<http://a.example.org>;rel="original",
 <http://arxiv.example.net/timegate/http://a.example.org> ; rel="timegate",

 <http://arxiv.example.net/web/20000620180259/http://a.example.org>
   ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT",
 <http://arxiv.example.net/web/20091027204954/http://a.example.org>
    ; rel="memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT", ...

All links should be interpreted to have http://a.example.org as Context IRI.
 If we understand it correctly, CoRE faces a similar issue because the links
in its application/link-format documents need to be interpreted, for
example, as having the baseURL (scheme & authority) of the Target IRI as
 their Context IRI. In both cases, there can be no "universal" understanding
of the provided links.

This problem could be addressed by making all links explicit through the
introduction of an anchor for every single link, e.g. for TimeMaps:

 <http://arxiv.example.net/timegate/http://a.example.org>
   ; anchor="http://a.example.org"; rel="timegate",

 <http://arxiv.example.net/web/20000620180259/http://a.example.org>
   ; anchor="http://a.example.org"; rel="memento";datetime="Tue, 20
Jun 2000 18:02:59 GMT",

 <http://arxiv.example.net/web/20091027204954/http://a.example.org>
    ; anchor="http://a.example.org"; rel="memento";datetime="Tue, 27
Oct 2009 20:49:54 GMT", ...

This is not impossible but it definitely generates a lot of redundancy in
the document, and added complexity for processing.

So, we were wondering whether there would be interest in introducing a
solution that is inspired by the <base> element of HTML, i.e. providing a
link that expresses what the Context IRI is for all links provided in the
document (the first line in the below example). The above Memento TimeMap
would then look as follows:

<http://a.example.org>;rel="contextIRI";anchor="URI-of-TimeMap",

 <http://arxiv.example.net/timegate/http://a.example.org> ; rel="timegate",

 <http://arxiv.example.net/web/20000620180259/http://a.example.org>
   ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT",
 <http://arxiv.example.net/web/20091027204954/http://a.example.org>
    ; rel="memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT", ...

In which:

=> URI-of-TimeMap is the URI of the application/link-format document itself
=> contextIRI is a new relation type that could be registered (e.g. in the
CoRE RFC). Note that the rel could also be called "base" or "anchor", or
whatever is deemed to make most sense.

This would make links in application/link-format documents generally
understandable, without the need to resort to repeating the same anchor in
each link. And note that this would still allow overwriting the default
Context IRI with another one by using the "anchor" attribute on a link. From
a processing perspective, determining what the Context IRI for any given
link is would be as follows:
1. The value provided in the "anchor" attribute on a link;
2. The value provided as the Target IRI of a link that has the contextIRI
rel type;
3. The URI of the resource that returns the application/link-format document
as a representation (as is the case with the Link header).

Looking forward to feedback.

Cheers

Herbert Van de Sompel

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

==