[core] application/link-format & non CoRE applications

[Herbert van de Sompel <[e-mail]>]

Hi all,


I am getting back to this list regarding the use of application/link-format
documents in the Memento "Time Travel for the Web" framework [1,2].


I have posted to this list before:

- To announce Memento's use of link-format documents [3].

- To point out that the determination of Context IRIs for links expressed
in application/link-format documents as specified in the CoRE Link Format
Internet Draft was problematic for Memento's use [4]. I never received any
reaction to this mail.


Having read the most recent version of the CoRE Link Format Internet Draft
[5] carefully, I need to conclude that the specification has evolved in
such a manner that use of the application/link-format media type in the
Memento framework has become quite problematic. And I expect it would be
problematic for many applications that are not CoRE.


I find this application-specific approach generally inappropriate for a
media type definition, and I find it especially cumbersome because I
anticipate that - as Link headers will become increasingly used - other
applications will encounter the need to express links in documents, not
just in HTTP headers. I think it would be counter-productive if such
applications would have to define their own media type based on the syntax
specified for the HTTP Link header [6]. Hence, I hope it will still be
possible to specify application/link-format in a more generic manner.


These are specific issues I would like to point out that make use of the
application/link-format media type problematic for applications other than
CoRE ones:


(a) Section 1 is entirely framed in terms of CoRE applications and states
"This document specifies a link format for use in CoRE Resource Discovery"


(b) Section 2 states "The CoRE Link Format is only expected to be supported
in constrained networks and M2M systems."


(c) As I expressed in [4], and as confirmed by the current version of the
I-D, the determination of the Context IRI for a link in
application/link-format documents is conceived in function of CoRE
applications and is problematic for other uses.  In Memento (and I
anticipate in other potential applications), the Context IRI is not the
base-URI of the Target URI nor the base-URI of the URI that delivered the
links. As a matter of fact, for the large majority of links used by
Memento, the Context IRI and Target IRI are in different domains. Hence,
following the specification in Section 2.1, all such links would have to be
expressed using an anchor:

- Doing so, as such, yields an enormous overhead (Memento TimeMaps that use
the link format can easily contain many hundreds of links; see e.g.
http://mementoarchive.lanl.gov/list/timemap/link/http://lanlsource.lanl.gov/hello
).

- To aggravate the situation, the wording regarding links with anchors in
the I-D marginalizes this approach by stating: "A consuming implementation
can however choose to ignore such links. It is not expected that all
implementations will be able to derive useful information from explicitly
anchored links." In [4], I described a proposal to allow specifying the
Context IRI of links in application/link-format documents by means of a
special-purpose link and a special-purpose relation type. I trust other
approaches can be imagined; the bottom line however is that a mechanism
that allows to elegantly deviate from the default determination of Context
IRIs as currently specified in the I-D should be available.


I would like to add that Memento's use of link-formatted documents is not
marginal. I anticipate that by the end of 2012 such documents will be
available to communicate the holdings of web archives, worldwide. That is
over 10 billion links expressed using this format.


Looking forward to a constructive discussion.


Greetings


Herbert Van de Sompel


[1] http://mementoweb.org

[2] https://datatracker.ietf.org/doc/draft-vandesompel-memento/

[3] http://www.ietf.org/mail-archive/web/core/current/msg01119.html

[4] http://www.ietf.org/mail-archive/web/core/current/msg01824.html

[5] http://tools.ietf.org/html/draft-ietf-core-link-format-09

[6] http://tools.ietf.org/html/rfc5988




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

==