In Belgium, we developed a digital long-term preservation archive to preserve the information from our heritage institutions. This platform harvests the information from the institutions, preserves the information for the long term and disseminates the information as Linked Open Data. Our platform produces many di erent versions of the harvested data to keep the information accessible over time when, e.g., mapping the metadata or transcoding the multimedia les, but it also produces a lot of provenance information relating all those di erent versions of a resource. For publishing this information as Linked Open Data, we extended our Linked Open Data server with Memento datetime content negotiation. Next to this, we extended the Memento framework to also publish the provenance information of those datetime content negotiated versions using an HTTP provenance link header for automatic discovery of the provenance information. This way, our framework allows to publish the information of a resource as Linked Open Data, including all its previous versions and their provenance information, in a web-accessible manner.
Linked Open Data, Memento datetime content negotiation, Provenance
Many organisations and private persons still possess a lot of material which is stored on analogue carriers. This material is mostly part of important cultural heritage anywhere.
At this moment, the analogue carriers are degrading and
continuously losing quality, making the data inaccessible.
While we are still able to see wall paintings from millennia
ago, many documents from merely a decade or two decades
ago have become inaccessible, e.g., WordPerfect les. Some
refer to this situation as the Digital Dark Age[
The project Archipel 1 initiates the dissemination and
digital long-term preservation of the cultural heritage in
Flanders, Belgium, and researches the problems encountered with
digital long-term preservation. In this project, we developed
a platform that harvests data coming from various
institutions (libraries, archival institutions, the art sector
(museums), and the broadcasters), preserves the data for the long
term and disseminates the data as Linked Open Data [
To guarantee the long-term preservation of the harvested
content, our platform has the necessary processes in place
to keep the information intact and interpretable, in line
with the Open Archival Information System (OAIS)
reference model [
Our developed platform generates many di erent versions of the harvested data, i.e., metadata and referenced multimedia les, via its preservation processes. These resources, their previous versions and their provenance information, re
samcoppe/ontologies/Premis/index.html lating the di erent versions, will be published on the Web as LOD. When preserving information for the long term and publishing the information as LOD at the same time, di erent problems arise. First of all, we need to have persistent URIs for our resources, which will publish the information of a certain version of the resource. Another problem involves the enrichments that occur on the resources before publishing them as LOD. These enrichments will not always remain valid over time. We need a way for preserving the temporality of these enrichments. The last problem being tackled in this paper is the publication of the provenance information on the Web which will allow automatic discovery of the provenance information.
To solve these problems, our developed platform is
extended with the Memento5 [
In this paper, we present how our digital long-term preservation platform is able to publish the provenance information on the Web. First, Section 2 describes some related work on this topic. Then, in Section 3, we introduce our semantic layered metadata model, which allows the archive to deal with the diversity of metadata records coming from diverse institutions and to track the provenance of the harvested data. Section 4 describes the distributed architecture of the archive and its processes. Section 5 explains the publication of the content and its provenance information using the Memento framework, extended to provide provenance information. We end with a conclusion in Section 6.
Interest in digital preservation can be seen by the
multitude of projects in this area. Planets (Preservation and
Long-term Access through Networked Services)6 was
especially aimed at de ning guidelines for preservation planning.
However, it did not tackle the integration of di erent
existing metadata formats, or the dissemination of the metadata
as LOD. Likewise, the Prestospace (Preservation towards
storage and access) project's objective was to provide
technical solutions and integrated systems for a complete digital
preservation of all kinds of audio-visual collections 7. The
project was especially focussed on the underlying
technologies, e.g., automated generation of metadata or detection of
errors in content [
The CASPAR project (Cultural Artistic and Scienti c knowledge for Preservation, Access, and Retrieval) presented
technologies for digital preservation 8. The OAIS Reference Model was chosen as the base platform, and the project was focused on implementing the di erent steps in the preservation work ow. They focus more on preservation services than on describing the preservation information. BOM Vlaanderen 9, a national research project, was aimed at preservation and disclosure of audio-visual content in Flanders. Additionally, it looked at ways to unify di erent metadata standards currently used for describing audio-visual content. Current trends are on integrating di erent media archives. PrestoPRIME researches and develops practical solutions for the long-term preservation of digital media objects, programmes and collections, and nds ways to increase access by integrating the media archives with European on-line digital libraries in a digital preservation framework 10.
The previous discussed related work were focusing on the
digital long-term preservation, not on the more general
problem of enabling their provenance information on the Web.
For the work done is this area, the work of the W3C
Provenance Incubator Group11 is the major reference. This
incubator group produced working de nitions for provenance
information, provided a state-of-the-art understanding and
developed a roadmap for development and possible
standardisation of provenance on the Web. This work included
de ning key dimensions for provenance, collecting use cases,
designing three agship scenarios from the use cases,
creating mappings between existing provenance vocabularies,
looking how provenance could t in the Web architecture
and providing a state-of-the-art report on the current
provenance activities. Their work is summarised in a nal report
[
Another interesting work done in the area of publishing
provenance for linked data is the paper of Olaf Hartig and
Jun Zhao published at IPAW [
10http://www.prestoprime.org/ 11http://www.w3.org/2005/Incubator/prov/wiki/W3C_ Provenance_Incubator_Group_Wiki 12http://purl.org/net/provenance/ mation or ways for publishing provenance on the Web beyond using semantic web technologies. Future work could involve publishing the provenance information using this vocabulary, which is more suited for publication on the Web than PREMIS OWL, which is intended to be a data model for digital long-term archives. The mapping table, relating various provenance vocabularies, produced by the W3C Incubator Group13 will be the reference for this work.
Descriptive metadata schemes describe the content of the
harvested data: subject, author, date of creation, le
format, etc. This metadata makes it possible to manage and
search the complete digital archive. When archiving data
coming from di erent sectors like the broadcast sector, the
libraries, the cultural sector, and the archival sector, a
problem arises concerning descriptive metadata. Many of the
institutions already have descriptive metadata using
domainspeci c metadata models. To deal with this diversity of
metadata models, the descriptive metadata is mapped to
Dublin Core RDF [
DC RDF was chosen as format for the descriptive metadata, as it is a broadly accepted descriptive schema. The power of this schema is its simplicity and generality. It only consists of fteen elds among which creator, subject, coverage, description, and date. It can answer to the basic questions: Who, What, Where, and When. All the elds in DC are optional and repeatable. This makes it possible to map relatively easily almost all the descriptive metadata schemes to DC RDF as many institutions already support DC. This choice will also bene t the publication of the diverse records coming from the institutions as LOD, as will be discussed in Section 5.
To store the preservation metadata, we developed a semantic binding of the PREMIS 2.0 Data Dictionary. The 13http://www.w3.org/2005/Incubator/prov/wiki/ Provenance_Vocabulary_Mappings
PREMIS 2.0 Data Dictionary was especially designed for storing provenance information in the context of digital longterm preservation and is in line with the requirements of OAIS. This PREMIS OWL schema is currently undergoing a standardisation process and will soon be published on a more stable URL of the Library of Congress. The PREMIS 2.0 Data Dictionary is described by a data model, which consists of ve semantic units or classes important for digital preservation purposes:
Intellectual Entities: a part of the content that can be considered as an intellectual unit for the management and the description of the content. This can be for example a book, a photo, or a database.
Object: a discrete unit of information in digital form, typically multimedia objects related to the intellectual entity.
Event: An action that has an impact on an object or an agent.
Agent: a person, institution, or software application that is related to an event of an object or is associated to the rights of an object.
Rights: description of one or more rights, permissions of an object or an agent.
Intellectual entities, events, and rights are directly related to an object, whereas an agent can only be related to an object through an event or through rights, as can be seen on Figure 1. This way, not only the changes to an object are stored, but the event involved in this change is also described. These relationships o er the necessary tools to properly store the provenance of an archived object. The @prefix r d f : < h t t p : / /www. w3 . org /1999/02/22 rdf syntax ns#> . @prefix r d f s : < h t t p : / /www. w3 . org /2000/01/ rdf schema#> . @prefix owl: < h t t p : / /www. w3 . org /2002/07/ owl#> . @prefix premisowl: < h t t p : / / multimedialab . e l i s . ugent . be / users / samcoppe / o n t o l o g i e s / Premis / premis . owl#> . <event1> p r e m i s o w l : e v e n t I d e n t i f i e r premisowl:eventType premisowl:eventDateTime premisowl:eventDetail premisowl:eventOutcomeInformation pr emi sow l: lin kin gAg ent p r e m i s o w l : l i n k i n g O b j e c t p r e m i s o w l : l i n k i n g O b j e c t
. <event1ID> p r e m i s o w l : i d e n t i f i e r T y p e p r e m i s o w l : i d e n t i f i e r V a l u e . <event1OutcomeInformation> a premisowl:EventOutcomeInformation ; premisowl:eventOutcome .
a a Listing 2: notation. rights metadata needed for preservation are covered by the rights entity, which relates to the agent entity and the object entity. The binary metadata, technical metadata and structural metadata are encapsulated in the PREMIS data dictionary via the description of the object entity. Examples of an PREMIS OWL Object entity, Event entity, Rights entity and Agent entity are given in the resp. Listing 1, Listing 2, Listing 3, and Listing 4. @prefix r d f : < h t t p : / /www. w3 . org /1999/02/22 rdf syntax ns#> . @prefix r d f s : < h t t p : / /www. w3 . org /2000/01/ rdf schema#> . @prefix owl: < h t t p : / /www. w3 . org /2002/07/ owl#> . @prefix premisowl: < h t t p : / / multimedialab . e l i s . ugent . be / users / samcoppe / o n t o l o g i e s / Premis / premis . owl#> . <object1 > a premisowl:preservationLevel p r e m i s o w l : s i g n i f i c a n t P r o p e r t i e s p r e m i s o w l : o b j e c t C h a r a c t e r i s t i c s premisowl:originalName premisowl:storage premisowl:environment p r e m i s o w l : l i n k i n g E v e n t premisowl:linkingRightsStatement p r e m i s o w l : l i n k i n g I n t e l l e c t u a l E n t i t y p r e m i s o w l : F i l e ; < object1PreservationLevel > ; < o b j e c t 1 S i g n i f i c a n t P r o p e r t i e s > ; < o b j e c t 1 O b j e c t C h a r a c t e r i s t i c s > ; " 0001h . t i f " ; <object1Storage> ; <object1Environment> ; <event2> ; < r i g h t ss t a t e m e n t1 > ; <dublinCoreDescription1 > . < object1PreservationLevel > a premisowl:PreservationLevel ; premisowl:preservationLevelValue " 0 " ; premisowl:preservationLevelRole " master copy " ; premisowl:preservationLevelDateAssigned "2010 07 29T14:41:28 " . < o b j e c t 1 S i g n i f i c a n t P r o p e r t i e s > a
; < o b j e c t 1 O b j e c t C h a r a c t e r i s t i c s > a ; p r e m i s o w l : s i g n i f i c a n t P r o p e r t i e s T y p e p r e m i s o w l : s i g n i f i c a n t P r o p e r t i e s V a l u e " behavior " ; " h y p e r l i n k s t r a v e r s a b l e " .
In this section, our architecture of the digital long-term preservation archive is described. In this networked world, various resources are linked to each other. We do not want to build yet another central e-depot, but a distributed network of storage components. For this reason, the platform will have a service oriented architecture14 (SOA). This SOA will make use of a central service hub, which will o er the needed services for the platform. The objectives of our platform are twofold:
Disseminate the content and provenance information as LOD.
Enable long-term preservation.
Our architecture is depicted in Figure 3. The green arrow indicates the dissemination path, the red arrow stipulates the preservation path. The basic components of our architecture are:
Repositories : these are the repositories of the diverse
institutions, which have their content published
online, using the OAI-PMH protocol [
premisowl:License ; <rights1ID > ; " license " ; <licenseInformation1> ; <rightsGranted1> ; <object1> ; <object2> ; <> ; <rights1ID > a premisowl:RightsStatementIdentifier ; premisowl:identifierType "URL" ; p rem is ow l: id en ti fi erV al ue " h t t p : / / archipellod .demo. i b b t .
be:8080 / r i g h t s / resource / dissemination " ; <licenseInformation1> a premisowl:LicenseInformation ; p r e m i s o w l : l i c e n s e I d e n t i f i e r < l i c e n s e 1 i d e n t i f i e r > ; premisowl:licenseTerms " Here comes the actual t e x t of the license . ( under development ) " ; premisowl:licenseNote " These objects may be
disseminated . " ; < l i c e n s e 1 i d e n t i f i e r > a premisowl:LicenseIdentifier ; premisowl:identifierType "URL" ; p rem is ow l: id en ti fi erV al ue " h t t p : / / archipellod .demo. i b b t .
be:8080 / license / resource / dissemination " ; <rightsGranted1> premisowl:act premisowl:termOfGrant . <license1termofgrant> premisowl:startDate .
notation.
Integration Server : this server provides an integration layer for orchestrating all the needed processes, which are all implemented as web services, e.g., transcoding services. Box 3 of Figure 3 shows this.
LOD server : this server is used for the dissemination of the content and the provenance information, with a triple store as a storage back-end, shown in box 4 of Figure 3.
CMS : The CMS will store the archived content, using persistent identi ers and cloud storage, depicted in box 5 of Figure 3. For this Fedora Commons 17 is used. . . . pr em is ow l:a ge nt Ide nt if ier premisowl:agentType premisowl:agentName premisowl:linkingAgent premisowl:linkingObject premisowl:linkingObject
. <agent1ID> premisowl:identifierType p rem is ow l: id en ti fi erV al ue
archipelopenID . be " ; Listing 4: notation. a a a a premisowl:LicenseInformation ; < l i c e n s e 1 i d e n t i f i e r > ; <license1termofgrant> ; premisowl:TermOfGrant ; "2009 09 01T08:30:00 " ; 17http://fedora-commons.org/ @prefix r d f : < h t t p : / /www.w3. org/1999/02/22 rdf syntax ns#> . @prefix r d f s : < h t t p : / /www.w3. org /2000/01/ rdf schema#> . @prefix owl: < h t t p : / /www.w3. org /2002/07/ owl#> . @prefix premisowl: < h t t p : / / multimedialab . e l i s . ugent . be / users / samcoppe / ontologies / Premis / premis . owl#> . <agent1> premisowl:Event ; <agent1ID> ; " person " ; "Sam Coppens" ; <agent1> ; <object1> ; <object2> ; premisowl:AgentIdentifier ; "OpenID" ; " h t t p : / / smcoppens .
Identity Service: with this distributed architecture an identity server is needed for authentication across the di erent systems, shown in box 6 of Figure 3.
For building our distributed, digital long-term
preservation platform, we need an integration server to orchestrate
the di erent processes, based on SOA technology. An
Enterprise Service Bus (ESB) provides the open, standards-based
connectivity infrastructure for the service oriented
architecture and allows these services to exchange data with one
another as they participate in our processes. Orchestration
between services is handled by a work ow engine. This
engine is integrated in the service bus architecture and
supports the execution of the preservation processes. An
executable preservation process is de ned by a control ow that
consists of a combination of basic and structured activities.
For the communication, the 'Simple Object Access Protocol'
(SOAP)[
The whole preservation/dissemination cycle starts with a harvesting process, which will harvest the metadata, and the referenced les. The metadata harvested, is described using several descriptive metadata formats, e.g., MARC, DC, or CDWA. For management and dissemination purposes this metadata needs to be mapped to DC RDF. For this, we rely on a mapping service, which will map the incoming metadata to DC descriptions.
If the content also to be preserved, the original metadata
record, the mapped DC RDF record and the referenced les
get packed into a Submission Information Package (SIP),
according to the OAIS speci cations by the SIP creator
service. For this SIP, the BagIt [
When ingesting this BagIt package into the CMS, it has to be supplemented with the preservation information to form an Archival Information Package (AIP) in the OAIS terminology. This package holds all the di erent versions of the metadata and the multimedia les, referenced by the metadata les. For this preservation information, we will use our PREMIS OWL ontology. During this ingest process, all les in the package get a PREMIS Object description, related to the mapped DC RDF description, thus becoming the PREMIS intellectual entity. For this we rely on a characterisation service, which will identify the le format of the les and model the les as PREMIS Objects. Every action performed on such a PREMIS Object, will get related to that Object and will be modeled as a PREMIS Event. This way, the platform is able to store and track the provenance of the descriptive metadata and the referenced multimedia les.
The next thing within the work ow is the migration of the stored, related multimedia les. These les get migrated to a le format, de ned by the archives preservation plans. Such a preservation plan can stipulate, e.g., that all image les must be migrated to the TIFF le format to keep the image information accessible for long-term preservation purposes, or, e.g., that all image les must be migrated to the JPEG le format to keep the image information accessible for dissemination purposes. For this, we need migration services, which can then migrate various incoming le formats to the appropriate le format according the preservation plans. This migration will extend the AIP package with the extra migrated data stream. This data stream is then passed to the characterisation service to get a PREMIS Object description of the generated data stream and the preservation information is also extended with a description of the migration service as a PREMIS Event relating the source object to the migrated object.
During the last phase, the archived information is moved to the LOD server for dissemination of the information. For this, the descriptive DC RDF metadata will get enriched by the enrichment service before it gets ingested into the LOD server's triple store by the LOD ingest service. For the enrichment service, the platform relies on data sources like the OpenCalais infrastructure19 for extracting these named entities, GeoNames20 for enriching the locations, DBPedia21 for enriching the persons, organisations and events, BibNet 22 for authors, singers and music bands enrichment, and Toerisme Vlaanderen23 for touristic information enrichment on locations. This way, our approach provides i) unique identi ers for the resource and ii) formalised knowledge about this resource.We will not only disseminate the intellectual entity, i.e., the descriptive metadata, but also the preservation information, so the end-user has access to all the information available about that object.
If the harvested content does not need to be preserved, it is directly routed to our enrichment service, which will interlink the data with external data sources after harvesting and mapping the metadata. This enriched DC description then gets ingested into the triple store of the LOD server, which automatically publishes the enriched DC records as LOD. 5.
Our architecture, described in the previous section,
ingests all the harvested and generated information into our
triple store. This information, including the provenance
information, needs to be disseminated as Linked Open Data.
For this dissemination, we want to have stable URIs [
The Memento framework is based on HTTP and HTTPS URIs and introduces several concepts:
Original Resource (URI-R): This resource is archived for the long-term and has several versions.
Memento (URI-Mj): This resource refers to one of the versions of an original resource.
TimeGate (URI-G): The TimeGate for an original resource is a resource that supports the datetime content negotiation.
TimeMap (URI-T): A TimeMap for an original resource lists the URIs of all the mementos of that original resource.
The Memento framework is based on HTTP request and response headers. The framework introduces two new headers: Accept-Datetime and Memento-Datetime. The AcceptDatetime header is used to ask for the version of the original resource valid on that time. If a user agent requests an original resource for a speci c datetime, the server responds with a link to the timegate, which can do the datetime content 24http://datatracker.ietf.org/doc/ draft-vandesompel-memento/
URI Mj
Listing 5: Typical Memento HTTP interaction negotiation for that original resource. The timegate redirects the user agent to the appropriate memento, which responds with a memento-datetime. This memento-datetime gives the datetime the resource was created. This datetime of a memento is retrieved using the provenance information of that memento. The provenance of every memento is modeled as a PREMIS OWL Object instance relating to Event instances. Such an Object instance has always a creation event. The datetime of this creation event is used for the Memento datetime content negotiation. List 5 gives an example of such an HTTP interaction.
Next to the two new headers, Memento also introduces some new values for the existing HTTP headers: Vary and Link. The value for the VARY header in our case will be negotiate, accept-datetime, accept. This VARY header informs that the content negotiation was performed in two dimensions, i.e., the datetime content negotiation and the media type content negotiation. The relation types for the Link header Memento introduced are original, for referencing the original resource, timegate, for indicating the timegate, timemap for linking to the timemap, and memento for referencing to various mementos for an original resource. These Link headers allow automatic discovery of the timegate, the timemap, the original resource and several other mementos.
Introducing this Memento datetime content negotiation is justi ed from our digital long-term preservation perspective. A problem we were facing publishing information as Linked Open Data and preserving it at the same time, involved the enrichments. These enrichments do not always remain valid over time. That is why these enrichments are mostly left out of the metadata to be stored for the long term. If the data providers of the enrichments also support the datetime content negotiation, a memento with enrichments would reference that memento of the enrichment when it was valid. In other words, the Memento datetime content negotiation also preserves the temporality of the information. This justi es storing also the enrichments of the metadata records for the long-term. 5.2
In our platform, every version (memento) of a harvested resource (original resource) has a PREMIS OWL Object description. This Object description describes the provenance of that object and is related through events to object descriptions of other versions/mementos of that original resource. This allows our platform to include in the response of the request for a memento a provenance link header which includes the link to the LOD published PREMIS OWL Object description (URI-Pj ) of that memento. This provenance link header will allow automatic discovery of the provenance information.
We extended the Memento framework with a new concept: Provenance (URI-Pj): This resource refers to the provenance of the selected version/memento of the original resource.
To allow this resource to be automatically discovered, we extended the Memento framework with a special value for the existing HTTP header Link referencing the provenance information. The relation type for this Link header is provenance for the current provenance record (URI-Pj). A typical HTTP interaction, requesting a certain memento, is shown in Listing 6. In our framework steps 1 and 2 of the shown interaction are skipped, because the URI the original resources are published on is also the timegate for the original resources.
The provenance records are themselves also datetime content negotiable. So they become mementos of an original provenance resource. Doing this, gives some extra bene ts. The Memento framework de ned some extra relation types for the HTTP Link header referencing a memento. When applied to a provenance record of a memento of an original resource, they get the following de nitions:
rst memento (URI-M0): This resource refers to the provenance of the rst version/memento of the original resource. last memento (URI-Mn): This resource refers to the provenance of the last version/memento of the original resource. memento (URI-Mj): This resource refers to the provenance of the selected version/memento of the original resource. previous memento (URI-Mi): This resource refers to the provenance of the previous version/memento of the selected version/memento of the original resource. next memento (URI-Mk): This resource refers to the provenance of the next version/memento of the selected version/memento of the original resource. timemap (URI-T): A TimeMap for a provenance record of an original resource lists the URIs of the provenance records of all mementos of that original resource.
The response for a memento request will includes a provenance header link, referencing the provenance information of that memento. This provenance record is on itself also a memento. The response of this memento includes a timemap link header pointing to a URI (URI-T ) listing the URIs of the provenance records of all mementos of that original resource. This way, an agent can have immediately an overall view on the provenance of an original resource.
These extra links could be very helpful in processing the provenance information. Our PREMIS OWL model allows describing digital signatures, signing the versions/mementos of that original resource. A quality checker could investigate the quality and trustworthiness of the published information. This quality checker could investigate the digital signature of the last version. If this was signed by a trusted party and the digital signature is still valid, the quality checker could immediately move on to the provenance of the rst memento to check where the signed information 1 : UA HTTP GET/HEAD; Accept Datetime: T j 2 : UA < HTTP 200; L i n k : URI G 3 : UA HTTP GET/HEAD; Accept Datetime: T j 4 : UA < HTTP 302; L o c a t i o n : URI Mj ; Vary ; L i n k :
URI R, URI T , URI Mj , 5 : UA HTTP GET URI Mj ; Accept Datetime: T j 6 : UA < HTTP 200; Memento Datetime: T j ; L i n k :
URI R, URI T , URI G, URI Mj , URI Pj
URI Mj Listing 6: Extended Memento HTTP interaction with provenance information came from and if that data provider is a trusted party also to make a judgment regarding the quality and trustworthiness of the information. The PREMIS OWL model also allows describing the rights information in the provenance of a resource, such as licenses, copyrights, rights granted, etc. A license checker could use these additional links to browse through the provenance records of the mementos of an original resource and check if in none of them violates the rights information of another memento.
A shortcoming of making provenance records also datetime content negotiable, is that all events happening on a preserved resource more recent than the datetime asked for will be left out of the provenance description. Hence, the provenance information would then only contain links to older versions/mementos of the preserved resource and the links to the more recent versions are lost.
To improve the automatic discovery of the provenance information of a memento, our platform will inject the provenance link of the memento also in the HTML and RDF descriptions of that memento. This will enhance the provenance discovery, because not all clients will be able to intercept the provenance link header. For the HTML representation of the memento, our framework includes a HTML link tag in the head of the HTML document. This link has a relation type of provenance, e.g., <link rel="provenance" href="http://../object/VTi/1/oai:archipel1.demo.ibbt. be:10_V3"/>. For the RDF representation, our platform injects a triple denoting the provenance information of that memento. For linking this provenance record (PREMIS OWL Object intance), the PREMIS OWL object property linkingObject is used. An example of such an injected triple in the RDF description of a memento is: <http://../record/ VTi/1/oai:archipel1.demo.ibbt.be:10_V3> premis:linkingObject <http://../object/VTi/1/oai:archipel1.demo. ibbt.be:10_V3>.
In some cases, it might be convenient to store the provenance of the provenance information. An example of this in our framework is the characterisation process. This process identi es a memento of an original resource and creates a PREMIS OWL Object instance of it. This can be the metadata record or a multimedia le referenced in a metadata record. In case of a le, the Object description is being enriched with information from the Preserv2 format registry25. This is an enrichment event occurring on provenance information. This could be described in the provenance of the provenance information. Another example of this are digital signatures. Our PREMIS OWL model allows describing these digital signatures applied to a stored memento, but digital signatures can also be used to sign provenance information. When including a provenance Link header in 25http://p2-registry.ecs.soton.ac.uk/ the response to a provenance record, the provenance of the provenance information can be discovered.
Looking at the 5-star deployment scheme26 of Tim BernersLee, this framework could add two more stars for indicating the rating of a Linked Open Data provider. A sixth star could go to Linked Open Data providers that support the Memento datetime content negotiation. This sixth star will indicate to, e.g., a long-term preservation archive, that the enrichments coming from that provider could be stored also for the long term, as discussed earlier. A seventh star could go to Linked Open Data providers not only supporting the Memento datetime content negotiation, but also using this framework to publish their provenance records as Linked Open Data. This seventh star will indicate that the data provider publishes provenance information and, hence, it is possible to make trust judgments over that data using quality checkers or license checkers, as mentioned above. 5.3
For implementing this framework, we used Jena TDB as triplestore for the back-end. This is a large-scale persistent triplestore which supports SPARQL. On top of this triplestore, the LOD server was built using Apache Tomcat as HTTP web server. This LOD server has a servlet which will do the datetime and the mediatype content negotiation and will redirect from the original resource, published on a persistent URI, to the appropriate version/memento of that original resource. This servlet will form the timegate. Next to this, we have servlets to serve the appropiate mediatype of the information (HTML and RDF) will also insert the provenance information. The resources that will be published with this timegate are the harvested collections and records. As explained in the previous section, we do not o er datetime content negotiation for the provenance information. For this information, we have a seperate servlet only supporting media type content negotiation.
Next to the LOD server supporting the datetime content negotiation, we have an integration server which will provide the needed preservation processes. These preservation processes will generate the di erent versions of the harvested information. This integration server was built using the Porthus .NET Integration server.
The LOD server will soon be publicly available for demonstration on the URL http://archipellod.demo.ibbt.be: 8080/. It will support the datetime content negotiation and this can be tested in the Mozilla web browser using the Memento plugin27.
In this article, we have presented a distributed, digital long-term archive relying on semantic technologies. Our platform is able to harvest data, store it for the long-term, and disseminate it as LOD. This data comes from very diverse institutions, each using domain-speci c metadata formats. For this, we have developed a layered, semantic metadata model. The top layer lets the archive deal with the diverse data coming from the institutions. For this layer, DC RDF was chosen. The bottom layer will enable the long-term preservation processes and consists of a semantic 26http://www.w3.org/DesignIssues/LinkedData.html 27https://addons.mozilla.org/en-US/firefox/addon/ mementofox/ version of the PREMIS 2.0 data dictionary, i.e., PREMIS OWL. Using this ontology, it is possible to store the metadata needed for the preservation services. It forms the data model for the archive.
A SOA was designed for this distributed archive. This SOA in combination with an ESB allows to modify and expand the current setup of processes and to communicate with all the distributed preservation and dissemination services. This platform produces lots of di erent versions of the stored information and also produces provenance information, which will relate the di erent versions of the stored information. To publish these di erent versions of a preserved resource and their provenance information, our platfrom relies on the Memento datetime content negotiation. We extended this framework to include also HTTP provenance header links for automated discovery of the provenance information. This approach allows us to disseminate the versioned information of the preserved resources on persistent URIs, depending on the datetime content negotiation to redirect to the appropriate version/memento of the original stored resource. Combining datetime content negotiation with the publication of the provenance information, links the provenance information to the datetime dimension of a certain stored resource. It also allows to store even the enrichments of the LOD published and preserved resources, because the temporality of these enrichments is also preserved. Finally, the framework allows discovering the provenance information of the other existing versions of an original resource bringing provenance information to the Web. This can all be tested on our publicly available LOD server, published on the following URL: http://archipellod.demo.ibbt.be:8080/ 7.
The research activities that have been described in this paper were funded by Ghent University, K.U. Leuven, VRTmedialab, the Interdisciplinary Institute for Broadband Technology (IBBT) through the Archipel-project (50Innovation by Science and Technology in Flanders (IWT), the Fund for Scienti c Research-Flanders (FWO-Flanders), and the European Union. Special thanks go out the work package 4 partners. The work described was carried out by this team. This team consists of Gert Goossens, Bart Janssens, and Raf Vandesande from Porthus28, Descartes, Filip Borloo working for VTi29, Inge Van Nieuwerburgh and Patrick Hochstenbach from Boekentoren30, Kris Buytaert from Inuits31 and Matthias Vandermaesen from Krimson32. 8. 28http://www.porthus.be/default2.aspx 29http://www.vti.be 30http://www.boekentoren.be 31http://www.inuits.be 32http://www.krimson.be