JSON TimeMaps

Last updated: April 23, 2016


Authored by:
   Yorick Chollet - Los Alamos National Laboratory
   Harihar Shankar - Los Alamos National Laboratory
   Herbert Van de Sompel - Los Alamos National Laboratory

Abstract

This document describes how to express TimeMaps in JSON.

Table of Contents

Motivation

RFC 7089 defines a TimeMap for an Original Resource as a resource from which a list of URIs of Mementos of the Original Resource is available. It specifies the content that needs to be expressed in a TimeMap and defines a serialization based on the application/link-format media type, which itself is based on the definition of content for the HTTP Link header field. This TimeMap format was chosen because Memento clients must be able to parse HTTP Link headers anyhow when engaging in datetime negotiation. However, the format is not particularly appealing for consumption by, for example, JavaScript applications. In order to meet the needs of such applications, a JSON TimeMap format is defined in this document.
This section details how a basic TimeMap should be serialized as a JSON document with MIME type application/json. A basic TimeMap conveys information about all Mementos known to the responding server. Sometimes there are too many Mementos for the information to reasonably fit into a single TimeMap, in which case either Paged TimeMaps or a TimeMap Index need to be used.

A basic TimeMap must contain the URI of the Original Resource (original_uri) and it must list the Mementos for that resource. All Mementos known by the server that provides the TimeMap must be listed in an array (mementos.list). For each Memento, its URI (uri) and its archival/version datetime (datetime) must be provided.

It is highly recommended that the TimeMap also provide some additional information. It should contain the URI of the TimeGate for the Original Resource (timegate_uri) and the URI of the TimeMap itself (timemap_uri), serialized as application/json (timemap_uri.json_format) and/or application/link-format (timemap_uri.link_format). In addition, the first and last Mementos known by the responding server should be provided separately (mementos.first and mementos.last, respectively). If these special Mementos are provided in this manner, they still must be provided in mementos.list too.

Example 1: Assuming http://example.com/ is an Original Resource for which http://an.archive.org/timemap/json/http://example.com/ is a JSON formatted TimeMap. A TimeMap serialization that contains all required and recommended information looks as follows:

{
  "original_uri": "http://example.com/",
  "timegate_uri": "http://an.archive.org/timegate/http://example.com/",
  "timemap_uri": {
    "json_format": "http://an.archive.org/timemap/json/http://example.com/",
    "link_format": "http://an.archive.org/timemap/link/http://example.com/"
  },
  "mementos": {
    "first": {
      "datetime": "2000-06-21T04:41:56Z",
      "uri": "http://an.archive.org/20000621044156/http://example.com/"
    },
    "last": {
      "datetime": "2012-08-31T12:22:34Z",
      "uri": "http://an.archive.org/20120831122234/http://example.com/"
    },
    "list": [
      {
        "datetime": "2000-06-21T04:41:56Z",
        "uri": "http://an.archive.org/20000621044156/http://example.com/"
      },
      {
        "datetime": "2008-04-10T20:30:51Z",
        "uri": "http://an.archive.org/20080410203051/http://example.com/"
      },
      {
        "datetime": "2012-08-31T12:22:34Z",
        "uri": "http://an.archive.org/20120831122234/http://example.com/"
      }
    ]
  }
}
    

Whenever possible, basic TimeMaps should be used. But there are cases where there are just too many Mementos for all information to reasonably fit into a single TimeMap. In these cases, either Paged TimeMaps, described here, or a TimeMap Index should be used.

When paging JSON TimeMaps, each of the individual TimeMaps must be a JSON document with MIME type application/json. Certain information is repeated in each of the paged TimeMaps. This is the case for the mandatory URI of the Original Resource (original_uri), the recommended URI of the TimeGate for the Original Resource (timegate_uri), and the recommended URI of the first and last Mementos known by the responding server (mementos.first and mementos.last, respectively). In addition, it is recommended that each paged TimeMap lists its own URI (timemap_uri), serialized as application/json (timemap_uri.json_format) and/or application/link-format (timemap_uri.link_format).

In addition, using an array (mementos.list), each paged TimeMap must provide information about a subset of all Mementos known to the responding server. For each Memento, its URI (uri) and its archival/version datetime (datetime) must be provided. Subsets should be created in such a manner that the number of individual TimeMaps is minimized while their size remains reasonable for transfer and consumption.

As a paging mechanism, each paged TimeMap must include references to previous and next TimeMaps, as applicable (pages.prev, pages.next, respectively). For each referenced TimeMap, its URI (uri) must be provided. If the subsets of Mementos are created in a manner by which the archival/version datetimes are sorted, it is also highly recommended that the references include the timespan covered by each referenced TimeMap (from and until).

Example 3: Assume a TimeMap for the Original Resource http://example.com/ that is split into 3 paged TimeMaps, each of which can be accessed at http://an.archive.org/timemap/X/, where X is the page number. This example shows TimeMap #2, which covers Mementos between 2003-05-13T00:00:13Z and 2006-10-05T20:30:51Z, with all the mandatory and recommended information elements. Remember that TimeMap #1 and #3 will list the same information for original_uri, timegate_uri, mementos.first, and mementos.last. Note also that the values for pages.prev and pages.next will be empty for the first and last paged TimeMap, respectively.

{
  "original_uri": "http://example.com/",
  "timegate_uri": "http://an.archive.org/timegate/http://example.com/",
  "timemap_uri": {
    "json_format": "http://an.archive.org/timemap/2/json/http://example.com/",
    "link_format": "http://an.archive.org/timemap/2/link/http://example.com/"
  },
  "mementos": {
    "first": {
      "datetime": "2000-06-21T04:41:56Z",
      "uri": "http://an.archive.org/20000621044156/http://example.com/"
    },
    "last": {
      "datetime": "2009-04-10T23:45:20Z",
      "uri": "http://an.archive.org/20090410234520/http://example.com/"
    },
    "list": [
      {
        "datetime": "2003-05-13T00:00:13Z",
        "uri": "http://an.archive.org/20030513000013/http://example.com/"
      },
      {
        "datetime": "2005-04-10T07:05:12Z",
        "uri": "http://an.archive.org/20050410070512/http://example.com/"
      },
      {
        "datetime": "2006-10-05T20:30:51Z",
        "uri": "http://an.archive.org/20061005203051/http://example.com/"
      }
    ]
  },
  "pages": {
    "prev": {
      "from": "2000-06-21T04:41:56Z",
      "until": "2003-05-12T22:25:15Z",
      "uri": "http://an.archive.org/timemap/1/json/http://example.com/"
    },
    "next": {
      "from": "2006-10-06T00:00:57Z",
      "until": "2009-04-10T23:45:20Z",
      "uri": "http://an.archive.org/timemap/3/json/http://example.com/"
    }
  }
}
    

Whenever possible, basic TimeMaps should be used. But there are cases where there are just too many Mementos for all information to reasonably fit into a single TimeMap. In these cases, either a TimeMap Index, described here, or Paged TimeMaps should be used.

An Index TimeMap is a TimeMap that does not list any Mementos but rather provides pointers to several individual TimeMaps that, together, cover all Mementos known by the responding server. Both the Index TimeMap and the individual TimeMaps are JSON documents with MIME type application/json.

The Index TimeMap must list the URI of the Original Resource (original_uri). In addition, it should list the URI of the TimeGate for the Original Resource (timegate_uri) as well as its own URI (timemap_uri), serialized as application/json (timemap_uri.json_format) and/or application/link-format (timemap_uri.link_format).

The Index TimeMap must provide references to all individual TimeMaps in an array (indexes). For each referenced TimeMap, its URI (uri) must be provided. If the Mementos listed in a referenced TimeMap fully cover an interval of archival/version datetimes (no other TimeMap lists any Mementos in that interval), then it is also highly recommended that the reference includes the start and end time of that interval (from and until).

Each individual TimeMaps referenced by the TimeMap Index contains the information and is serialized like a Paged TimeMap as shown in Example 3, but it does not need to include references to previous and next TimeMaps as that information is already available in the Index TimeMap.

Example 4: Assume that three individual TimeMaps describe the Mementos available for Original Resource (http://example.com/). Each TimeMap can be accessed at http://an.archive.org/timemap/json/X/http://example.com/ where X is the TimeMap's number. These three TimeMaps are referenced in the TimeMap Index, shown below, available at http://an.archive.org/timemap/link/http://example.com/.

{
  "original_uri": "http://example.com/",
  "timegate_uri": "http://an.archive.org/timegate/http://example.com/",
  "timemap_uri": {
    "json_format": "http://an.archive.org/timemap/json/http://example.com/",
    "link_format": "http://an.archive.org/timemap/link/http://example.com/"
  },
  "timemap_index": [
    {
      "from": "2000-06-21T04:41:56Z",
      "until": "2003-05-12T22:25:15Z",
      "uri": "http://an.archive.org/timemap/1/json/http://example.com/"
    },
    {
      "from": "2003-05-13T00:00:13Z",
      "until": "2006-10-05T20:30:51Z",
      "uri": "http://an.archive.org/timemap/2/json/http://example.com/"
    },
    {
      "from": "2006-10-06T00:00:57Z",
      "until": "2012-08-31T12:22:34Z",
      "uri": "http://an.archive.org/timemap/3/json/http://example.com/"
    }
  ]
}
    
The JSON TimeMap format allows for the introduction of extensions that can not readily be covered by the application/link-format TimeMap format. At this point the following extensions have been defined:
  • memento_compliant: An indicator to convey whether an archive is compliant with the Memento protocol or not. It is used as a qualifier for TimeMap URIs. Values are yes or no. Introduced in DIY TimeMaps exposed by the Time Travel service.
  • archive_id: A short name for an archive. It is used as a qualifier to a TimeMap URI. Values are provided by the Time Travel Archive Registry, in the id attribute of the link element. Introduced in DIY TimeMaps exposed by the Time Travel service.

This table explains which value are mandatory (1), recommended (>=0) or if they do not apply(0). If the enclosing Object do not apply, then the table enytry is (-).

KeyKeyKeyValue TypeBasic FormatPaged FormatIndexed Format
original_uri  string (RFC3986)111
timegate_uri  string (RFC3986)>=0>=0>=0
timemap_uri  string (RFC3986)>=0>=0>=0
 json_format string (RFC3986)>=0>=0>=0
 link_format string (RFC3986)>=0>=0>=0
mementos  object110
 first/last object>=0>=0-
 prev/next object00-
 closest object0>=0-
 all array11-
  datetimestring (ISO8601)11-
  uristring (RFC3986)11-
pages  object010
 prev/next object-1-
  fromstring (ISO8601)-1-
  untilstring (ISO8601)-1-
  uristring (RFC3986)-1-
timemap_index  array001
 from string (ISO8601)--1
 until string (ISO8601)--1
 uri string (RFC3986)--1