Dereferencing a URI returns a representation of the current state of the resource identi ed by that URI. But, on the Web representations of prior states of a resource are also available, for example, as resource versions in Content Management Systems or archival resources in Web Archives such as the Internet Archive. This paper introduces a resource versioning mechanism that is fully based on HTTP and uses datetime as a global version indicator. The approach allows \follow your nose" style navigation both from the current time-generic resource to associated time-speci c version resources as well as among version resources. The proposed versioning mechanism is congruent with the Architecture of the World Wide Web, and is based on the Memento framework that extends HTTP with transparent content negotiation in the datetime dimension. The paper shows how the versioning approach applies to Linked Data, and by means of a demonstrator built for DBpedia, it also illustrates how it can be used to conduct a time-series analysis across versions of Linked Data descriptions.
H.3.5 [Information Storage and Retrieval]: Online Information Services
The Architecture of the World Wide Web [
Resource state may evolve over time. Requiring a URI owner to publish a new URI for each change in resource state would lead to a signi cant number of broken references. For robustness, Web architecture promotes independence between an identi er and the state of the identi ed resource.
Nevertheless, use cases abound that require the availability of (representations of) distinct prior states of resources. Resource versioning is of crucial importance in areas as diverse as community-driven content creation, open government, and scienti c communication. Also, as more data becomes available in the Linked Data cloud, the need to version them will increase if only to allow e cient update of stores that leverage the data, and to trace their provenance. Web archives and content management systems possess signi cant amounts of prior versions of resources, but these prior versions are largely disconnected from current versions and discoverable only in an ad-hoc manner. Given this state of Web resource versioning, we consider these challenges: 1. Given the current version of a resource, how can \follow your nose" style navigation to prior versions of the resource be achieved? 2. Given any version of a resource and a particular timestamp, how can \follow your nose" style navigation towards another version that matches the timestamp be achieved?
This paper is concerned with versioning mechanisms that
are machine-actionable, have global scope, and are
independent of media-type. Hence, approaches that are
mainly bene cial to human users such as untyped hyperlinks
in HTML with anchor text that provides navigational
guidance (e.g. \previous/next version"), or version semantics
expressed in metadata-carrying URIs [
Our contributions are a resource versioning mechanism based on the global notion of time and an HTTP-based mechanism to navigate across versions. Furthermore, we demonstrate how these contributions can be applied for time series analysis across resource versions, and illustrate this using a linked data example.
The remainder of this paper is structured as follows: Section 2 discusses and illustrates characteristics of resource versioning approaches; Section 3 provides an introduction to the Memento framework that extends HTTP with transparent datetime content negotiation capabilities; Section 4 shows how the Memento framework suggests an elegant resource versioning approach that is fully based on HTTP; Section 5 shows how the Memento versioning ideas apply to Linked Data; Section 6 describes the demonstrator we built for the DBpedia environment to illustrate how the proposed versioning mechanism can be used to access prior descriptions of DBpedia concepts via their existing DBpedia URIs. In the same section, we also show how this mechanism was used to conduct a time-series analysis of Gross Domestic Product values for several countries across DBpedia versions. Section 7 reviews some related work, and Section 8 holds our conclusions.
This Section introduces core characteristics of versioning approaches, discusses these characteristics for a typical resource versioning approach, and evaluates how that versioning approach can meet the challenges (1) and (2) from the Introduction. 2.1
The following four core characteristics of versioning approaches are considered: 1. Identi cation: By which means are di erent versions identi ed? 2. Versioning Strategy : What is the approach used to assign identi ers to versions, e.g. do new versions receive a new identi er, do they inherit a prior identi er, etc.? 3. Version Relationships: How are version relationships between resources expressed? 4. Version Timestamping : How is the datetime associated with versions conveyed? 2.2
A Typical Resource Versioning Approach
The quote from the Architecture of the World Wide Web
implicitly suggests a versioning approach as depicted at the
top of Figure 1. This approach is described in terms of the
aforementioned core characteristics:
1. Identi cation: HTTP URIs are used to identify
versions of resources; each version has its own URI.
2. Versioning Strategy : A new URI is minted for each for
each new version. When a use case requires that a
resource URI-R0 that started its existence at t0, but at
time t1 changes state in such a way that a distinct
identity is needed, a new resource with URI-R1 is minted.
And, if consecutively at time t2 a change in state of
URI-R1 again requires a new identity, a resource
URIR2 is created (top of Figure 1). URI-R0, URI-R1, and
URI-R2 co-exist and, in terms of [
abstract resource and are interlinked by the http:
//www.w3.org/2006/gen/ont#sameWorkAs property.
3. Version Relationships: Can be made available as RDF
metadata published about and linked from the related
resources. The common Dublin Core Terms2
hasVersion and isVersionOf predicates (bottom of Figure 1)
can be used. Alternatively, the machine-processable
and media-independent HTTP Link header [
The above characterization reveals the technological substrates that are used in the considered versioning approaches: 2http://dublincore.org/documents/dcmi-terms/ for the RDF approach, URIs, HTTP, RDF, and an appropriate RDF vocabulary; for the HTTP Link approach, URIs, HTTP, HTTP Link, and registered link relationships. For both approaches, applications such as browser plug- ins, can be created to support the navigation described in question (1) above, whereby the starting point would be the current resource URI-R2. Also (2) can be achieved for the RDF approach, although a processor would need to traverse versions until a matching datetime is found. Lacking appropriate version datetime information, (2) can not reliably be achieved in case of the HTTP Link header.
To summarize, both (1) and (2) can be achieved for the RDF approach, however: (a) Two technological substrates, HTTP and RDF, must be combined (b) Version datetime can not be used as a primary entry point; rather resource versions must be traversed until a version with a matching datetime is found (3) The common predicates used to express version relationships do not necessarily imply timebased version relations.
The basic motivation for the Memento3 work [
From a HTTP perspective, URI-R and URI-Mi are
disconnected in that HTTP provides no means to navigate
towards a URI-Mi via its original URI-R. The Memento
framework introduces this missing capability as follows (Figure 2):
Inspired by Transparent Content Negotiation for HTTP
(conneg from now on) speci ed in RFC 2295 [
In order to support discovery of a TimeGate URI-G
for a resource URI-R, a relationship type of timegate is
introduced for the HTTP Link response header [
Memento also introduces the notion of a
TimeBundle resource via which an overview is available of all
Mementos that a server hosts for a given (internal or
external) URI-R. A TimeBundle is a non-information
resource [
Three aspects of the Memento architecture ensure that the
globally deployed HTTP caching infrastructure can be
leveraged. First, the Original Resource URI-R and its TimeGate
URI-G are always separate resources: URI-R is a
conventional resource and URI-G is dedicated to datetime conneg.
This eliminates caching problems that would be caused by
transitioning URI-R between non-negotiable and negotiable
if URI-R and URI-G were to coincide. Second, the initial
Memento architecture [
A detailed overview of HTTP request/response
scenarios is available in the Memento HTTP Transactions Guide6.
Here, we highlight certain aspects related to HTTP
interactions with the TimeGate URI-G. A choice was made to
handle cases in which URI-G is dereferenced without the
Accept-Datetime header, by issuing a \302 Found" redirect
to the most recent Memento, as opposed to o ering a list
of choices to the client. While a list would be feasible for a
top-level resource (say, an HTML page), it would be
cumbersome for the potentially many embedded resources (say, the
images in the HTML page). URI-G will only return HTTP
response code \300 Multiple Choices" if explicitly requested
with a \Negotiate: 1.0" request header or when there are
multiple Mementos with the same Content-Datetime7.
URIG will return HTTP response code \406 Not Acceptable"
when the Accept-Datetime is outside of the datetime range
of known Mementos. For further technical details about the
Memento framework, we refer to the original paper [
Since its publication, Memento has received signi cant attention. Major Web Archives have started implementing support8, and work is ongoing to develop support for common CMS platforms such as MediaWiki and Drupal. Also, the establishment of a Memento-track at the JISC Developer Days (Dev8D)9 organized by the UK's Joint Information Systems Committee is an early indication of interest by both funders and implementers.
As an illustration, Figure 3 shows a Memento HTTP ow whereby a client requests a November 8 2009 version of the Wikipedia page for DJ Shadow, by interacting with its current URI http://en.wikipedia.org/wiki/DJ_Shadow; the client is pointed by http://en.wikipedia.org/wiki/DJ_Shadow to a TimeGate at Wikipedia; via that TimeGate the client successfully retrieves a Memento that meets its datetime preferences (only headers crucial to convey an understanding of datetime conneg are shown). We should point out that Wikipedia has not (yet) implemented such Memento HTTP ows, but a MediaWiki plug-in that adds Memento support is available10. 6http://www.mementoweb.org/guide/http/ 7This may occur as HTTP only supports second-level time granularity 8See Agenda of First Memento Implementation Meeting at http://mementoweb.org/events/IA201002/ 9http://wiki.2010.dev8d.org/w/Talk_6 10Memento MediaWiki plug-in http://www.mediawiki.org/ In Figure 3, note the use of the HTTP Link header to express the very rst and most recent Mementos available from Wikipedia (rel=\ rst-memento" and rel=\last-memento", respectively) as well as the Mementos that are closest in time (rel=\prev-memento" and rel=\next-memento") to the one that is returned. Note also the use of a HTTP Link header to point back to the Original Resource (rel=\original"). 4.
MEMENTO RESOURCE VERSIONING The Memento framework suggests a versioning mechanism that is fully based on HTTP (see Figure 4). These are its core characteristics:
Identi cation: HTTP URIs are used to identify versions of resources.
Versioning Strategy : The top of Figure 4 shows URI-R
as the resource from which at any point in time the
current representation is served, and URI-Mi as resources
that provide access to representations that were
previously available from URI-R. In terms of [
Version Relationships: A timegate HTTP Link header provided in response to GET/HEAD requests issued against the stable URI-R points at a TimeGate. And, an original HTTP Link header provided in response to GET/HEAD requests issued at Mementos URI-Mi points at URI-R of the Original Resource. As described, a TimeGate supports datetime conneg based on the content of the Accept-Datetime header. It is a time-travel resource that acts as a gateway between the time-generic URI-R and its associated time-speci c Mementos URI-Mi. The result of the datetime conneg is a Memento that meets the expressed datetime preference. Also, the prev-memento and next-memento relationships may be used in the HTTP Link header to point at Mementos that are adjacent in time to the returned one.
Version Timestamping : Versioning of URI-R is not required as it always is the current version. Mementos URI-Mi are timestamped by means of the ContentDatetime response header.
The technology substrate used by the Memento versioning approach is fully centered on HTTP: URI, HTTP, HTTP Link with to-be-registered link relationships, HTTP datetime conneg. The challenges formulated in the Introduction can be addressed as follows (bottom of Figure 4): wiki/Extension:Memento 11http://www.w3.org/2006/gen/ont 1. Given the current version of a resource, how can \follow your nose" style navigation to prior versions of the resource be achieved? The current version is the stable URI-R. A client application can follow its nose to a TimeGate for URI-R by using the URI that is expressed in the timegate HTTP Link header returned by URI-R. The TimeGate supports datetime conneg allowing the client to obtain various versions (Mementos) by varying the content of its Accept-Datetime request header. In addition, in cases where the prevmemento and next-memento relationships are available in the Alternates header provided in TimeGate responses, a client can engage in version-to-version navigation with a certainty that the version-relationships are time-based. 2. Given any version of a resource and a particular timestamp, how can \follow your nose" style navigation towards another version that matches the timestamp be achieved? A version URI-Mi provides an original HTTP Link header pointing at the stable URI-R. From thereon, this scenario is the same as described in the previous point; the timestamp is used as the content of the Accept-Datetime request header. The ContentDatetime provides the earliest datetime at which the returned version became available; that version was still the then-current one at the datetime that was expressed in the Accept-Datetime header.
MEMENTO RESOURCE VERSIONING AND LINKED DATA
Figure 5 shows how Memento integrates in the Linked
Data environment. In this case, URI-R is a cool URI for a
non-information resource [
We have implemented the architecture depicted in Figure 5 in the DBpedia context. We rst downloaded the ve prior English-language versions of DBpedia (2.0 through 3.3)12 in NT format. Using a python script, the approximately 600 Million triples were loaded into a MySQL table (Table 1). Loading took approximately 15 hours, and resulted in a MyISAM table of 81 GB.
For each DBpedia subject URI-R, we exposed a TimeGate to support content negotiation in the datetime and mediatype dimensions. For example, our TimeGate for DBpedia's France resource http://dbpedia.org/resource/France is http://mementoarchive.lanl.gov/dbpedia/timegate/http: //dbpedia.org/resource/France. The datetime functionality was implemented by retrieving all distinct start/end 12http://wiki.dbpedia.org/Downloads34 combinations for the requested subject URI-R. This approach readily supports providing the rst-memento, lastmemento, next-memento and prev-memento relationships in the HTTP Link header provided in responses. The returned Memento is the one with the start/end interval that covers the datetime requested via conneg. For conneg requests with a datetime value that is in the range of the current DBpedia version, the TimeGate issues an HTTP 302 redirect to the Original Resource URI-R at dbpedia.org. Mementos are available both in HTML and RDF/XML. For example, the Memento for DBpedia 3.3's France resource in HTML is http://mementoarchive.lanl.gov/dbpedia/ memento/20090701/http://dbpedia.org/page/France.
Colleagues at DBpedia kindly implemented the timegate HTTP Link header pointing at our TimeGates. This required approximately one hour and consisted of adding a stored procedure in the OpenLink Virtuoso engine to add the appropriate HTTP Link header.
Figure 6 shows a Memento HTTP ow whereby a client requests the description of France that was available from DBpedia on March 20, 2008. Only headers crucial to convey an understanding of the conneg are shown.
To illustrate full Memento compliance, we also implemented TimeBundle/TimeGate support for our DBpedia version archive. This functionality was not used to achieve the time-series analysis described below. The Appendix shows our TimeMap for the DBpedia resource http://dbpedia. org/resource/France; the content should be self-explanatory.
Although DBpedia currently operates under a regime of recurrent discreet updates, both the proposed Memento approach and our speci c database design support a possible future regime in which DBpedia is updated on an ongoing basis. In this case, an archiving mechanism would need to be added to ensure that versions of distinct DBpedia descriptions are pushed/pulled into the version archive as they change. 6.2
Time-Series Analysis using Memento Resource Versioning
To illustrate the power of the proposed approach, we implemented a simple time-series analysis using both past and current DBpedia data. We set out to trace the evolution over time of the Gross Domestic Product Per Capita for various countries, leveraging the http://dbpedia.org/property/ gdpPppPerCapita property.
The straightforward data-time-traveling algorithm used to construct the time-series data-set is described by the below pseudo code. It must be noted that the actual script must rely on some ad-hoc heuristics to deal with diverging data formats used for GDP values. resources := [list of country description TimeGate URIs] times := [list of date times, one per version including current] prop := "http://dbpedia.org/property/gdpPppPerCapita" values := {} foreach r in resources: values[r] := [] foreach t in times:
data := fetch(URI-TG/r, Accept-Datetime: t, Accept: "application/rdf+xml") graph := parse(data) value := graph.sparql(SELECT val WHERE { r prop ?val . }) value := normalize(value) values[r].push(value)
The collected data were then turned into a chart (Figure 7) using the Google Chart API13.
Little research has explored a protocol-based solution to
augment the Web with time travel capabilities. TTApache
[
There is a relationship between the described work and
e orts that research the problem of provenance of Linked
Data, speci cally those provenance aspects concerned with
the time intervals in which speci c data is valid. For
example, [
URIs like http://weather.example.com/oaxaca used in
[
The URI http://weather.example.com/oaxaca can now
be leveraged to obtain an overview of Oaxaca's weather in
the past months, merely by issuing HTTP GET requests
with varying datetime preferences. Similarly, time-traveling
a Dow Jones data URI can result in an overview of the
stock market's evolution at any desired granularity.
Tracing the evolving state of tra c congestions, implemented in
Zoetrope [
While this paper has focused on Linked Data, it should be clear that the proposed versioning mechanism can be applied to Web resources in general. It could, for example, be leveraged to facilitate navigating across issues of Web-based newspapers and magazines, and it can play an important role in better integrating the data-intensive eScience and eHumanities e orts into the Web. Hence, the addition of a time dimension to the Web is not something only digital archaeologists should care about. It is an enabler for a global HTTP-based versioning mechanism that can support a new range of temporal applications for both the document and the data Web. This paper has merely scratched the surface of a new world of possibilities.
The Memento research is partly funded by the Library of Congress. Many thanks to Chris Bizer, Kinsley Idehen, and Mitko Iliev for implementing the timegate HTTP Link header in DBpedia. 10.
The following is an RDF/XML TimeMap for http:// dbpedia.org/resource/France. <?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:foaf='http://xmlns.com/foaf/0.1/' xmlns:dcterms='http://purl.org/dc/terms/' xmlns:mem='http://www.mementoweb.org/terms/tb/' xmlns:dc='http://purl.org/dc/elements/1.1/' xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#' xmlns:ore='http://www.openarchives.org/ore/terms/' xmlns:rdfs1='http://www.w3.org/2001/01/rdf-schema#'> <ore:ResourceMap rdf:about="http://mementoarchive.lanl.gov/dbpedia/timemap/rdf/http://dbpedia.org/resource/France"> <rdf:type rdf:resource="http://www.mementoweb.org/terms/tb/TimeMap"/> <dcterms:modified>2010-02-17T05:26:27Z</dcterms:modified> <dcterms:created>2010-02-17T05:26:27Z</dcterms:created> <dc:format>application/rdf+xml</dc:format> <dcterms:creator> <rdf:Description rdf:about="http://foresite-toolkit.googlecode.com/#pythonAgent"> <foaf:mbox>foresite@googlegroups.com</foaf:mbox> <foaf:name>Foresite Toolkit (Python)</foaf:name> </rdf:Description> </dcterms:creator> <ore:describes> <ore:Aggregation rdf:about="http://mementoarchive.lanl.gov/dbpedia/timebundle/http://dbpedia.org/resource/France"> <ore:aggregates rdf:resource="http://mementoarchive.lanl.gov/dbpedia/memento/20070901/http://dbpedia.org/data/France"/> <ore:aggregates rdf:resource="http://mementoarchive.lanl.gov/dbpedia/memento/20080201/http://dbpedia.org/data/France"/> <ore:aggregates rdf:resource="http://mementoarchive.lanl.gov/dbpedia/memento/20080801/http://dbpedia.org/data/France"/> <ore:aggregates rdf:resource="http://mementoarchive.lanl.gov/dbpedia/memento/20081101/http://dbpedia.org/data/France"/> <ore:aggregates rdf:resource="http://mementoarchive.lanl.gov/dbpedia/memento/20090701/http://dbpedia.org/data/France"/> <ore:aggregates rdf:resource="http://mementoarchive.lanl.gov/dbpedia/timegate/http://dbpedia.org/resource/France"/> <ore:aggregates rdf:resource="http://dbpedia.org/resource/France"/> <dc:title>Memento Time Bundle for http://dbpedia.org/resource/France</dc:title> <rdf:type rdf:resource="http://www.mementoweb.org/terms/tb/TimeBundle"/> </ore:Aggregation> </ore:describes> </ore:ResourceMap> <rdf:Description rdf:about="http://www.openarchives.org/ore/terms/Aggregation"> <rdfs1:label>Aggregation</rdfs1:label> <rdfs1:isDefinedBy rdf:resource="http://www.openarchives.org/ore/terms/"/> </rdf:Description> <rdf:Description rdf:about="http://www.openarchives.org/ore/terms/ResourceMap"> <rdfs1:label>ResourceMap</rdfs1:label> <rdfs1:isDefinedBy rdf:resource="http://www.openarchives.org/ore/terms/"/> </rdf:Description> <mem:TimeGate rdf:about="http://mementoarchive.lanl.gov/dbpedia/timegate/http://dbpedia.org/resource/France"> <mem:timeGateFor rdf:resource="http://dbpedia.org/resource/France"/> <mem:covers rdf:nodeID="gtKXRtug21"/> </mem:TimeGate> <mem:Period rdf:nodeID="gtKXRtug21"> <mem:end rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2009-11-01T00:00:00+00:00</mem:end> <mem:start rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2007-09-01T00:00:00+00:00</mem:start> </mem:Period> <mem:Memento rdf:about="http://mementoarchive.lanl.gov/dbpedia/memento/20070901/http://dbpedia.org/data/France"> <mem:validOver> <mem:Period> <mem:start rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2007-09-01T00:00:00+00:00</mem:start> <mem:end rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2008-02-01T00:00:00+00:00</mem:end> </mem:Period> </mem:validOver> <mem:mementoFor rdf:resource="http://dbpedia.org/resource/France"/> </mem:Memento> <mem:Memento rdf:about="http://mementoarchive.lanl.gov/dbpedia/memento/20080201/http://dbpedia.org/data/France"> <mem:validOver> <mem:Period> <mem:start rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2008-02-01T00:00:00+00:00</mem:start> <mem:end rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2008-08-01T00:00:00+00:00</mem:end> </mem:Period> </mem:validOver> <mem:mementoFor rdf:resource="http://dbpedia.org/resource/France"/> </mem:Memento> <mem:Memento rdf:about="http://mementoarchive.lanl.gov/dbpedia/memento/20080801/http://dbpedia.org/data/France"> <mem:validOver rdf:nodeID="gtKXRtug42"/> <mem:mementoFor rdf:resource="http://dbpedia.org/resource/France"/> </mem:Memento> <mem:Period rdf:nodeID="gtKXRtug42"> <mem:end rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2008-08-01T00:00:00+00:00</mem:end> <mem:start rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2009-11-01T00:00:00+00:00</mem:start> </mem:Period> <mem:Memento rdf:about="http://mementoarchive.lanl.gov/dbpedia/memento/20081101/http://dbpedia.org/data/France"> <mem:validOver rdf:nodeID="gtKXRtug49"/> <mem:mementoFor>
<mem:OriginalResource rdf:about="http://dbpedia.org/resource/France"/> </mem:mementoFor> </mem:Memento> <mem:Period rdf:nodeID="gtKXRtug49"> <mem:end rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2008-11-01T00:00:00+00:00</mem:end> <mem:start rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2009-07-01T00:00:00+00:00</mem:start> </mem:Period> <mem:Memento rdf:about="http://mementoarchive.lanl.gov/dbpedia/memento/20090701/http://dbpedia.org/data/France"> <mem:validOver rdf:nodeID="gtKXRtug56"/> <mem:mementoFor rdf:resource="http://dbpedia.org/resource/France"/> </mem:Memento> <mem:Period rdf:nodeID="gtKXRtug56"> <mem:end rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2009-07-01T00:00:00+00:00</mem:end> <mem:start rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2009-11-01T00:00:00+00:00</mem:start> </mem:Period> </rdf:RDF>