Linked Data resources change rapidly over time, making a valid consistent state difficult. As a solution, the Memento framework offers content negotiation in the datetime dimension. However, due to a lack of formally described versioning, every server needs a costly custom implementation. In this poster paper, we exploit published provenance of Linked Data resources to implement a generic Memento service. Based on the w3c prov standard, we propose a loosely coupled architecture that offers a Memento interface to any Linked Data service publishing provenance.
Linked Data defines data to be published as resources on the web, uniquely
identified by persistent uris. However, the state of these resources changes
rapidly over time, which causes inconsistencies in the links between them. This
is of great concern to enterprises maintaining their data archives extensively.
Requesting a consistent state of resources at a given point in time is crucial
for recovery, analytics and administration purposes. A popular solution is the
Memento framework [
In Linked Data, provenance has been a hot research topic for years. It
formally describes where the current resource state originates from. Recently, the
w3c Provenance Working Group released the prov [
In this poster paper, we extend the Memento framework with provenance discovery and exploit it to enable generic access. We redefine Memento as an independent service, compatible with any Linked Data server publishing provenance. First, we shortly introduce the Memento framework (Section 2) and propose an extended architecture (Section 3). Next, we describe our approach for generic provenance-based content negotiation (Section 4). Finally, we add conclusions and some future work (Section 5).
Memento is an http framework for accessing prior archived versions of web resources, based on a given datetime. It defines three types of resources: – Original Resource Ri: an existing resource on the web, of which prior versions are desired. – Memento Mi;j: encapsulated prior states of the requested Ri. – Timegate Gi: a resource supporting content negotiation in the datetime dimension. When requested, it decides on a best matching Mi;j, where tj is the given datetime.
An architectural overview is given in Figure 1. The resources Ri, Gi and Mi are connected through hypermedia. When Ri is requested, the http response contains a Link header, pointing at Gi. When Gi is requested, it responds with its Location header set to the selected Mi;j resource. When Mi; j is requested, the response holds link headers to its related Ri and to the previous, the next, the first and the last Mi.
client get
Ri
Link: timegate Gi get Accept-Datetime: ti
Mi;j Memento needs a tailored implementation on every server, due to lacking formal and uniform descriptions about the structure and locations of the different archives. In our approach, we will use provenance of web resources to create a generic Memento implementation as demonstrated in Figure 2. We define two independent types of services: a Linked Data Service lds and a Generic Memento Proxy gmp. The former publishes a Linked Data resource Li and their provenance in prov Pi, which describes the archives Ai;j. The latter provides the functionality of the Memento framework, providing access to the resources Ri, Mi;j and Gi. The decision logic in Gi now depends on Pi to select a matching Mi;j, which is explained in Section 4. This results into a loose coupling between lds and gmp, thus making publishing provenance the only requirement for adding Memento functionality. This reduces costs and effort, while enabling other applications of provenance. 4
When requested, the timegate module decides on a Mi;j based on the value
ti from the Accept-DateTime header and the descriptions in Pi. We use the
semantic reasoner eye [
get
get get lds Ai;j Pi Li describes
logic in only a few compact n3 rules. Third, it can easily be extended with more complex logic if desired later. We can devide the approach into two main steps: discovery of provenance and selecting the memento.
Discovery of provenance Before any decisions can be made, the provenance has to be retrieved. As descibed by the prov-aq note2, a link header pointing to the prov description is added to an http response. The module will lookup the resource Li and dereference the uri in the header. As stated above, we will request the provenance in rdf. An example is given in Listing 1. Selecting the Memento Once the provenance is retrieved, we decide on a memento Mi;j using semantic reasoning. The resulting rules are demonstrated in Listing 2. First, we identify all mementos. Each revision is linked to its predecessor using the predicate prov:wasRevisionOf, forming a chain of revisions with Ri as endpoint. Relying on the transitive property defined in owl logic, the relation between Ri and Mi;j is derived by adding the triples on lines 5 and 6.
Next, we select a version valid at a given datetime [line 8]. The predicate prov:wasGeneratedBy links each version to an instance of prov:Activity, whose prov:endedAtTime predicate indicates the initiation of validity. The rule starts with extracting the defined datetime [line 10] and creating a finite list of occuring datetimes. This list is composed by finding all datetimes [line 11] that occur on or before the requested datetime [line 13]. The valid version occurs on the latest datetime in that list [lines 15 and 16], and is added to the response [line 18]. In addition, we define analogue rules to select the first, the last, the next and the previous memento as well, since links to all of these resources are required. The complete rule file can be found here: http://goo.gl/dz13UN. 2 http://www.w3.org/TR/2013/NOTE-prov-aq-20130430/ 1 @prefix prov: <http://www.w3.org/ns/prov#>. 2 @prefix pred: <http://www.w3.org/2007/rif-builtin-predicate#>. 3 @prefix xsd: <http://www.w3.org/2001/XMLSchema#>. 4 @prefix e: <http://eulersharp.sourceforge.net/2003/03swap/log-rules#>. 5 prov:wasRevisionOf rdfs:subPropertyOf :memento. 6 :memento a owl:TransitiveProperty. 7 8 :request :datetime "2012-04-11T12:30:00Z"^^xsd:dateTime 9 { 10 :request :datetime ?req_datetime. 11 [] e:findall (?datetime { 12 ?rev prov:endedAtTime ?datetime . 13 (?datetime ?req_datetime) pred:dateTime-less-than-or-equal true. 14 } ?datetime_list) . 15 ?datetime_list e:max ?current_datetime. 16 ?current prov:endedAtTime ?current_datetime. 17 } => { 18 :response :memento ?current. 19 }. 20 ...
Listing 2. n3Logic selects the Memento valid at a specific Datetime
After the rule execution, the derived result can be mapped directly to the response. We add a Location header pointing at Mi;j and add the necessary Memento-specific Link headers. 5
Many enterprises publish their data archives as Linked Data. This requires access to a consistent state of all resources. The Memento framework solves this, but requires a costly custom implementation on each server. In the described approach, we avoid these costs by extending the framework using provenance descibed in prov. We proposed a loosely-coupled architecture, where a Memento server can operate independently. We explained how semantic reasoning can implement the decision logic in a quick and scalable way.
In a related project, we have created r&wbase [