Automated Validation of Trusted Digital Repository Assessment Criteria Journal of Digital Information (JoDI), Vol 8, No 2, 2007

Transcription

1 Autmated Validatin f Trusted Digital Repsitry Assessment Criteria Jurnal f Digital Infrmatin (JDI), Vl 8, N 2, 2007 Reagan W. Mre San Dieg Supercmputer Center 9500 Gilman Drive La Jlla, CA mre@sdsc.edu MacKenzie Smith MIT Libraries 77 Massachusetts Avenue Cambridge, MA kenzie@mit.edu ABSTRACT The RLG/NARA trusted digital repsitry (TDR) certificatin checklist defines a set f preservatin assessment criteria. The criteria can be mapped int management plicies that define hw a digital preservatin envirnment is perated. We explre hw these management plicies can be autmated thrugh their characterizatin as rules that cntrl preservatin services. By integrating a rule-based data management system with the DSpace digital library, we expect t demnstrate autmated audits f the TDR checklist. The system is sufficiently general that ne can als demnstrate the cmpleteness and self-cnsistency f preservatin envirnments. This is the cncept that all required preservatin are cntrlled by management plicies, and that fr each management plicy the required preservatin are preserved. Categries and Subject Descriptrs H.3.4 [Systems and Sftware]: Distributed systems, D.2.9 [Management]: life cycle, sftware prcess mdels, H.3.6 [Library Autmatin]: Large text archives General Terms Management, Dcumentatin, Verificatin. Keywrds Rule-based cnsistency management, Plicy expressin 1. INTRODUCTION The Research Library Grup, in cllabratin with the Natinal Archives and Recrds Administratin, has published An Audit Checklist fr the Certificatin f Trusted Digital Repsitries [TDR] [1]. The checklist defines a set f management plicies that are rganized int criteria fr the functinal prperties: Organizatin; Repsitry Functins, Prcesses, and Prcedures; The Designated Cmmunity & the Usability f Infrmatin; and Technlgies & Technical Infrastructure. While the dcument des nt specify the implementatin f the management plicies, we can define rules that check the implied assertins. We examine the set f rules and assciated state infrmatin required t autmate the verificatin f the trusted digital repsitry. In effect, we attempt t define the set f rules that validate the trustwrthiness f a repsitry. We extend this result t examine the cmpleteness and self-cnsistency f preservatin envirnments themselves. If it is pssible t define management plicies fr authenticity and integrity f recrds [2], ne can assert that a preservatin envirnment is cmplete when preservatin attributes exist fr each management plicy. We can assert that a preservatin envirnment is selfcnsistent if fr each preservatin attribute, a management plicy has been defined. An unexpected result frm this analysis is that the required preservatin fr cmpleteness and self-cnsistency are dependent n attributes used t define the entire preservatin envirnment (peple, management rules, etc.), and are nt simply assciated with attributes that identify recrds. Our apprach can be used t implement a prvably trustwrthy preservatin envirnment. 2. PRESERVATION ENVIRONMENT One can think f a preservatin envirnment as the set f sftware that prtects recrds frm changes that ccur in hardware systems, sftware systems, and even presentatin mechanisms. Preservatin envirnments insulate recrds frm changes that ccur in the external wrld while retaining the ability t display the recrds and assert authenticity and integrity f the recrds. Fr this t be feasible, the preservatin envirnment must manage all f the names needed t identify, discver, and manage recrds. The preservatin envirnment must als prvide mechanisms t guarantee the ability t parse and present digital data, even after the riginal creatin applicatin has becme bslete. A preservatin envirnment shuld be able t use mdern technlgy t access and display ld recrds. irods Trust Repsitries 1

2 Preservatin management plicies define the preservatin attributes that shuld be maintained by the preservatin envirnment. The RLG audit checklist describes a set f assessment criteria that the management plicies shuld cnserve. A preservatin envirnment is trustwrthy when it implements these management plicies. The DSpace digital asset management sftware [3], in cmbinatin with the Strage Resurce Brker (SRB) [4] distributed data management sftware, is an example f a preservatin envirnment. The cmbined system supprts the implementatin f a trusted digital repsitry fr lng-term preservatin. DSpace prvides management f standard prcessing steps fr the curatin f recrds. The SRB prvides management f the digital entities that may be replicated r distributed acrss multiple strage systems [5]. Tgether the tw systems prvide the capabilities needed t implement a preservatin envirnment. The DSpace/SRB system prvides administrative cmmands that can be issued t supprt ingestin f recrds, check assertins abut integrity and authenticity f the preserved recrds, and cntrl the display f recrds. Fr very large cllectins, these administrative tasks becme nerus. The ability t autmate the applicatin f administrative tasks that implement management plicies is essential fr building scalable preservatin envirnments. At the San Dieg Supercmputer Center, an integrated Rule-Oriented Data System (irods) is under develpment [6]. The irods system expresses management plicies as rules that cntrl the executin f preservatin micr-services, and manages the utcmes as persistent state infrmatin. Each rule is expressed as an [event cnditin (set f actins)] in which the actins are either micr-services r ther rules. Fr each Client Interface micr-service, a recvery prcedure is defined. The state infrmatin that is needed t execute a rule is dwnladed frm the persistent state infrmatin repsitry int a temprary cache. On successful cmpletin, the persistent state infrmatin is updated t preserve the utcme f applying the rule. Typical micr-services include the validatin f access cntrls, the selectin f a strage lcatin, the strage f a recrd, the replicatin f a recrd, and the validatin f a checksum. A typical rule may invke multiple micrservices. Thus a rule fr the ingestin f a recrd may invke each f the micr-services just described. A beta versin f the irods system was released in December The develpment f the irods envirnment required a cmplete descriptin f the prperties f a preservatin envirnment. In the develpment f the SRB data grid, three lgical namespaces were used t manage the identity f strage resurces, recrds, and persns. Preservatin attributes culd then be assciated as fr an entity defined by ne f these namespaces. In the irods envirnment, three additinal lgical namespaces were required t manage the identity f rules, micr-services, and persistent state infrmatin. In traditinal preservatin envirnments, preservatin attributes are mapped nt the lgical naming set used t identify recrds. We shall see that the management f a preservatin envirnment requires preservatin attributes that are mapped nt all six lgical namespaces: recrds, strage systems, persns, rules, micr-services, and persistent state infrmatin. The preservatin envirnment needs t manage all cmpnents f the preservatin envirnment t successfully satisfy assertins required fr a trusted digital repsitry. Admin Interface Resurces Resurce-based Services Rule Invker Rule Service Manager Rule Mdifier Mdule Cnfig Mdifier Mdule Metadata Mdifier Mdule Micr Service Engine Check Mdule Check Mdule Check Mdule Mdules Metadata-based Services Current State Repsitry Rule Cnfs Micr Service Metadata Persistent irods Trust Repsitries 2

3 Figure 1. irods rule-based data management system architecture The architecture f the irods system is shwn in Figure 1. The shaded cmpnents are the extensins applied t data grid technlgy t implement rule-based data management. The riginal data grid technlgy prvided a persistent repsitry (t hld bth state infrmatin and ), services fr the remte manipulatin f data and, access methds fr administratin f the preservatin envirnment, and user access methds. The rule-based envirnment adds: Rule base this stres the rules that implement the management plicies. Rule invker this lads the rule set needed t manage the interactins f a specified user with a specific recrd series. Rule engine this executes the rules that express management plicies. Temprary state infrmatin cache this manages the state infrmatin generated n executin f the micr-service set assciated with a rule. If recvery prcedures are invked t handle prblems with remte strage systems, the updates are made t the temprary state infrmatin cache. Micr-service cnsistency check mdule when new versins f micr-services are added, the functinality supprted by the micr-services is verified fr cnfrmance with prir functinality. Rule cnsistency check mdule when new versins f rules are added, the persistent state infrmatin that is generated is verified fr cnfrmance with prir persistent state infrmatin. Persistent state cnsistency check mdule when new persistent state infrmatin is defined, cnsistency checking is dne t ensure n verlap with prir persistent state infrmatin. The six lgical namespaces enable a preservatin envirnment t cntrl all prperties required t preserve recrds independently f the chice f hardware and sftware strage systems. The preservatin envirnment cntrls the identity f the archivists. The preservatin envirnment cntrls the file names under which recrds are stred. The preservatin envirnment manages the access cntrls defining wh is allwed t ingest recrds, wh is allwed t view recrds, and wh is allwed t manage recrd dispsitin. The preservatin envirnment can be migrated nt new types f strage systems and new catalgs withut having t change any f the namespaces. The ability t add new versins f rules, micr-services, and persistent state infrmatin means that the preservatin envirnment itself can evlve. The management plicies used tday can be extended t meet the new preservatin requirements that becme evident as technlgy evlves. The cmbinatin f DSpace and irods is designed t autmate the applicatin f preservatin management plicies at scale. 3. ASSESSMENT CRITERIA The RLG audit checklist can be applied t the DSpace/SRB system as implemented by a given rganizatin t determine whether all the management plicies are being adequately met t insure lng-term preservatin f the cntents. In this paper we g ne step further, and seek t have the DSpace/iRODS system autmatically validate the trustwrthiness defined by lcal plicy decisins. Our apprach is based upn the characterizatin f each item in the checklist as a rule that must be prcessed. Fr each rule, we identify the state infrmatin that must be prvided t drive the executin f the rule. We then validate the trustwrthiness based upn the state infrmatin that is generated by the applicatin f the rule. This prvides a mechanism t assert hw the trusted digital repsitry is being managed, and als prvides the infrmatin that is needed t validate the assertin. In ur design prcess, we discvered many implicatins within the TDR criteria that impact the ability t describe trustwrthiness. We encapsulate these implicatins in the fllwing bservatins: 1. The assessment criteria can be mapped t management plicies. 2. Implementatin f many f the management plicies requires mapping t a set f rules that can be autmatically evaluated. 3. Management rules require definitin f cntrl parameters that define hw an assertin is applied, as well as attributes that encapsulate the result f the applicatin f the rule The types f rules that are needed include: 1 As an example, take an assertin abut replicatin fr preservatin purpses. The cntrl parameter might be three cpies lcated in different cntinents, and the attributes wuld be the date and lcatin f each cpy made. irods Trust Repsitries 3

4 Specificatin f assertins (setting flags and ) Deferred cnsistency cnstraints that may be applied at any time (i.e. a-peridic) Peridic rules that execute defined prcedures Atmic rules applied n each peratin (access cntrls, audit trails) 5. The level f management granularity n which the rules are applied encmpasses the enterprise level, the archives level, the cllectin (recrd-series) level, and the item level. A specificatin f the multiple levels f management granularity is needed t understand hw t apply the TDR assessment criteria. 6. The rule that is applied at each level f granularity may differ, even thugh the same assessment criteria are being applied. This is ne f the mst imprtant bservatins: that each management plicy may require the definitin f multiple rules that are applied differently at each level f granularity. 7. Within the DSpace/SRB envirnment, additinal management plicies are needed beynd thse specified in the TDR dcument. These include plicies related t business case; security architecture; pen surce sftware license; user privacy; retentin schedule; dispsitin; destructin f recrds; withdrawal f recrds; risk management; prtectin data staging; and audit frequency. These shuld be evaluated fr pssible inclusin in a future versin f the TDR checklist. 8. The actual implementatin f the assessment criteria is dependent upn the persistence f the namespaces n which the management plicies are applied [7]. The management plicies need t apply t persistent identifiers fr users, files, strage systems, rules, micr-services, and persistent state infrmatin. The persistent identifiers are managed as six separate namespaces. Preservatin is then assciated with entities identified by each naming set. Thus preservatin prperties assciated with archivists are stred as attributes n the archivist s name. Preservatin prperties assciated with strage systems are stred as attributes n the strage repsitry name. 9. The trusted preservatin repsitry shuld implement multiple levels f virtualizatin t enable migratin nt new technlgy withut impacting the ability f the system t meet the assessment criteria. In practice this includes bth management f the six persistent namespaces and the management f tw levels f mapping between the actins specified in user interfaces and the standard peratins fr interacting with strage systems (data virtualizatin). The preservatin envirnment maps frm the applicatin level actins t standard micr-services. The micr-services are then mapped t the set f standard peratins that can be executed at remte strage systems. A preservatin envirnment als manages the authenticatin envirnment (trust virtualizatin), and the rule executin engine (cnstraint virtualizatin) independently f the chice f hardware infrastructure [8]. We als bserve that the chice f levels f granularity impacts the types f rules that are needed. The rules used at the enterprise level are typically assertins that define the state infrmatin required by rules executed at finer levels f granularity. The deferred cnsistency cnstraints are typically applied at the cllectin level t enfrce assertins made n the cllectin. An example is checking cmpliance f Submissin Infrmatin Packages with Service Level Agreement specificatins. The peridic rules are applied at the cllectin (recrd series) level, and are driven by mandates fr peridic validatin f integrity. An example wuld be the validatin f integrity every 6 mnths. The atmic rules are evaluated at the item level n each executin f a related peratin. The standard example is the checking f access cntrls befre an peratin is perfrmed upn a file. If additinal levels f granularity are defined, such as a recrd grup level, ne cncern is that additinal types f rules may be required. In practice, we expect nly these fur types f rules. This implies that a rule engine that is capable f executing all fur rule types shuld be able t autmate validatin f the trustwrthiness f a digital repsitry. The irods system has been designed t supprt the fur types f rules that have been identified (specificatin f assertins, deferred cnsistency cnstraints, peridic rules, and atmic rules). Thus the irods system shuld be able t execute the rules that implement the management plicies. By creating rules that cmpare the persistent state infrmatin utcmes with the assertins that drive the management plicies, irods will be able t track whether the management plicies are being met. This cnstitutes autmatin f the validatin f trustwrthiness f a digital repsitry. Finally, we bserve that the mapping f the certificatin criteria t the management plicies planned fr the DSpace/iRODS system is nt ne-t-ne. Multiple assessment criteria may apply t a particular repsitry management plicy. We address this issue by explicitly listing each time when the assessment criteria shuld be applied, and the additinal rules that are applied. 4. RULES T prvide a flavr f the assessment, we list sme example rule sets fr selected TDR criteria. We select an example frm each level f granularity, including a case irods Trust Repsitries 4

5 where the same TDR criteria must be evaluated at multiple levels f the data management hierarchy. The left-mst clumn in tables 1-4 is the management numbering scheme used in the DSpace/SRB plicy assessment. The numbering scheme uses 1 fr enterprise level, 2 fr archives level, 3 fr cllectin level, and 4 fr item level. The secnd number identifies the management plicy at that level f granularity. The secnd clumn lists the crrespnding plicy. The third clumn lists the TDR criteria number that mst clsely crrespnds t the management plicy. # Plicy layers / types Annual review f planning prcesses Table 1. Enterprise Level Rule Example TDR A4.2 Rule r prcedure State inf - result f rule applicatin Timestamp f last planning prcess review List f dates f annual review prcess Descriptin Annual prcess t review and adjust business plans Repsitry has in place at least annual prcesses t review and adjust business plans as necessary The 4 th clumn lists the type f rule that is needed. The 5 th clumn lists examples f the state infrmatin that are needed fr either executing the rule, r fr managing the result f the applicatin f the rule. The right-mst clumn prvides an explanatin f the plicy. In Table 1, there are tw items listed fr the plicy entitled Annual review f planning prcesses. The first rw is the criteria as prpsed within the DSpace/SRB system. The secnd rw lists the crrespnding TDR criteria. # 4. Plicy layers / types 2.14 Persistent identifiers TDR B2.4 Table 2. Archives Level Rule r prcedure rule - check that handle was created Set/update naming specificatin State inf result f rule applicatin List f types f GUID. Lists f lcatins f handle systems fr creating GUIDs Specificatin f standard naming cnventin fr physical files Descriptin Management f mapping f identifiers t SIPs. Which type are assigned and t what? Are multiple identifiers fr an item supprted? Repsitry has and uses a naming cnventin that can be shwn t generate visible, unique identifiers fr all AIPs B2.5 Set/update templates Prducerarchive submissin pipeline fr extracting n ingest; Template based extractin If unique identifiers are assciated with SIPS befre ingest, they are preserved in a way that maintains a persistent assciatin with the resultant AIP. In Table 2, tw assessment criteria frm the TDR checklist shuld be applied t the management plicy fr persistent identifiers. The types f rules that are needed include bth deferred cnsistency checking as well as setting f state infrmatin needed fr rule validatin. The persistent identifiers require mapping t the identifier used in the Archival Infrmatin Package (AIP) frm the identifiers specified in the Submissin Infrmatin Package (SIP). In Tables 3 and 4, the same TDR criterin (A5.1) is applied at multiple levels f granularity. Rule A5.1 was applied at bth the cllectin and item level. In additin t managing the service level agreement that specifies the required cnsistency checks, is als needed t allw changes t the service level agreement t ccur. Fr the item level rule, we als listed the additinal TDR criteria that were applied. This indicates that multiple assessment criteria are applicable fr a given plicy. The validatin f the data frmat requires checking rules related t Service Level Agreements, AIP definitins, allwed transfrmative migratins, and assciatin f with each file. # Plicy layers / types Service level agreements fr cllectins Table 3. Cllectin Level TDR A5.1 Rule r prcedure flags State inf - result f rule applicatin Flag fr specificatin f type f service level agreement Depsit agreement fr strage f data specifying access, replicas, cnsistency checks Descriptin Maintain a service level agreement fr each cllectin. Specify required by SIP type. If repsitry manages, preserves, and/r prvides access t digital materials n behalf f anther rganizatin, it has and maintains apprpriate cntracts r depsit irods Trust Repsitries 5

6 agreements. The full assessment f the TDR criteria takes 13 pages t print in 8-pint type. The cmplete mapping is available upn request. Please cntact Reagan Mre at mre@sdsc.edu fr a cpy r visit the prject website at 5. TRUSTED DIGITAL REPOSITORY The autmatin f the verificatin f the assessment criteria fr a trusted digital repsitry can nw be implemented as a set f peridic rules that are applied t the preservatin envirnment. The rules examine the persistent state infrmatin, cmpare the values with the desired values, and generate reprts f the recrds r prperties that are nt in cmpliance. Sme f the rules are applied n each peratin perfrmed within the preservatin envirnment. Examples are the authenticatin f the identity f the archivist and the checking f access cntrls. Sme f the rules are applied as deferred cnsistency checks. Since preservatin envirnments may be distributed acrss multiple administrative dmains and access multiple types f strage systems, a mechanism is needed t handle wide-area-netwrk failures. If a preservatin peratin is suppsed t create a replica at a remte strage lcatin (t avid data lss in case f a natural disaster), it may nt be pssible t cmplete the peratin. The netwrk may be dwn r the remte strage system may be ff line fr maintenance. In this case, a deferred cnsistency flag is set that indicates the replica must still be created. Deferred cnsistency checks lk fr such cases and attempt t cmplete the peratin. If the replica is created successfully, the deferred replica creatin flag is reset. If the attempt is unsuccessful, the flag is nt updated, and a future attempt may succeed in creating the replica. # 6. Plicy layers / types 4.2 Frmat Rule r TDR prcedure A5.1 Peridic rule - check cnsistency with required frmats rule - check that depsit agreement exists Table 4. Item Level State inf - result f rule applicatin List f supprted frmats and flag fr SLA supprt level fr each Descriptin Whether file frmat is accepted, preservatin SLA fr each accepted frmat; Als any requirements fr quality within frmat (e.g. cmpliance with TIFF 6.0 acceptance specs) Depsit If repsitry manages, agreement fr preserves, and/r strage f prvides access t data digital materials n specifying behalf f anther B2.1 rule that AIP definitin exists access, replicas, cnsistency checks rganizatin, it has and maintains apprpriate cntracts r depsit agreements. Repsitry has an identifiable, written Statement f definitin fr each AIP characteristics r class f infrmatin f each AIP preserved by the repsitry rule - check Criteria fr allwed allwed B2.2 (r class) that is transfrmative transfrmative migratin is migratins perfrmed B3.9 B4.2 : check fr changes t allwed transfrmative migratins rule - check required Prcedure fr updating transfrmative migratin strategy: Audit trail f changes; check fr changes t migratin strategy Repsitry has a definitin f each AIP adequate t fit lng-term preservatin needs Repsitry has mechanisms t change its preservatin plans as a result f its mnitring activities Validatin Repsitry captures r that minimum creates minimum and is ensures that it is present assciate with the AIP rules are typically applied peridically because the preservatin envirnment is a dynamic entity. Prperties that have been asserted as verified in the past may change based n circumstances nt under archivist cntrl. T make this cncept clearer, cnsider a validatin f integrity. One f the prperties shuld be the existence f replicas at a remte site that have been verified as being bit-fr-bit identical with the riginal. There are multiple surces f risk that can cause this prperty t becme invalid: Media crruptin the tape n which the replica was created may be damaged and becme unreadable Administrative errr a systems administratr at the remte site may have erased the file Vendr prduct errr the remte strage system may have crrupted the data. An example is a micr-cde update t a tape drive that is incrrectly perfrmed. Replicas must be peridically checked t verify that they are still reliable. A trustwrthy preservatin envirnment is ne in which all assertins n integrity and authenticity have been irods Trust Repsitries 6

7 verified within a specified time perid. The verificatin prcess must be repeated peridically. Preservatin envirnments are live systems that require cnstant appraisal and validatin. 6. SELF-CONSISTENT PRESERVATION ENVIRONMENTS Given the ability t characterize assessment criteria as rules that verify preservatin attribute values, we can nw explre the cncepts f cmpleteness and self-cnsistency fr preservatin envirnments. Multiple preservatin grups have created lists f preservatin that shuld be assciated with a trusted digital repsitry. An example is the PREMIS preservatin list. This defines authenticity and integrity, prvenance, and administrative that shuld be created fr each recrd within a digital repsitry [9]. Fr trustwrthiness, assessment criteria can be defined t validate the attribute value assciated with each PREMIS element. Verificatin tests culd include whether the attribute exists, whether the value lies within the expected range r is included in the expected enumerated list. Each recrd can be examined and a list generated f all recrds that are nn-cmpliant. When all recrds have the required, the system can be cnsidered trustwrthy. Assessment criteria, therefre, shuld prvide cnsistency checks n all preservatin assciated with each recrd. A preservatin envirnment can be cnsidered self-cnsistent when a management plicy exists fr each required preservatin attribute. In practice, there are multiple preservatin attributes that are used t express administrative required t keep the preservatin envirnment running crrectly. Thus we need t differentiate between the attributes required t assert preservatin prperties (integrity and authenticity) and attributes required t mnitr the running f the preservatin envirnment (time the last set f assertins were validated). We als want t assert that a preservatin envirnment is cmplete. If preservatin attributes exist fr each management plicy, then we have clsure. We can map frm required preservatin attributes t the management plicies needed t assess trustwrthiness. We can then map frm these management plicies back t the preservatin that are needed t keep the preservatin envirnment running successfully. We will have demnstrated that the system is capable f validating the assessment criteria. This analysis raises the questin: Shuld preservatin envirnments be based n the management plicies required t assert trustwrthiness? Or shuld preservatin envirnments be defined by a set f required preservatin attributes? In practice, mst preservatin envirnments have been designed t assciate required preservatin with each recrd. These attributes may then be rganized, as in the Life Cycle Data Requirements Guide [10]. A preservatin envirnment that meets these requirements can be defined and implemented. By examining the preservatin envirnment frm the perspective f assessment criteria, we discver that additinal preservatin are required, assciated with all six lgical namespaces used t identify resurces, persns, recrds, rules, micr-services, and persistent state infrmatin. Examples f these additinal preservatin attributes include: User Resurce Rule Identificatin as archivist, r staff Allwed rles fr creating dispsitin dcuments, transferring recrds, anntating recrds Type f strage system Access classificatin Media type Rule type Access cntrl Versin number Persistent State Versin number Attribute creatin date These additinal attributes are needed because the preservatin envirnment itself evlves. Given that the technlgy that is used t implement a preservatin envirnment changes ver time as new technlgy is acquired, the preservatin envirnment must als evlve t maintain an unchanging recrd cllectin. The preservatin attributes that are needed t maintain trustwrthiness include nt nly the required preservatin attributes assciated with the recrd prvenance, but als the preservatin attributes that define the preservatin envirnment attributes. 7. ACKNOWLEDGMENTS This prject was supprted by the Natinal Archives and Recrds Administratin under NSF cperative agreement thrugh a supplement t SCI , Cyberinfrastructure; Frm Visin t Reality. The views and cnclusins cntained in this dcument are irods Trust Repsitries 7

8 thse f the authrs and shuld nt be interpreted as representing the fficial plicies, either expressed r implied, f the Natinal Science Fundatin, the Natinal Archives and Recrds Administratin, r the U.S. gvernment. 8. REFERENCES [1] Audit Checklist fr Certifying Digital Repsitries, [2] Fr a general discussin f the definitin f authenticity and integrity in digital preservatin envirnments see Lynch, C. (2000). Authenticity and integrity in the digital envirnment: An explratry analysis f the central rle f trust. In Authenticity in a digital envirnment (Cuncil n Library and Infrmatin Resurces reprt). [3] DSpace digital repsitry, [4] Strage Resurce Brker data grid, [5] Mre, R., A. Rajasekar, M. Wan, Data Grids, Digital Libraries and Persistent Archives: An Integrated Apprach t Publishing, Sharing and Archiving Data, Special Issue f the Prceedings f the IEEE n Grid Cmputing, Vl. 93, N.3, pp , March [6] Rajasekar, A., M. Wan, R. Mre, W. Schreder, A Prttype Rule-based Distributed Data Management System, HPDC wrkshp n Next Generatin Distributed Data Management, May 2006, Paris, France. [7] Mre, R., Building Preservatin Envirnments with Data Grid Technlgy, American Archivist, vl. 69, n. 1, pp , July [8] Mre, R., R. Marcian, Technlgies fr Preservatin, chapter 6 in Managing Electrnic Recrds, edited by Julie McLed and Catherine Hare, Facet Publishing, UK, Octber [9] Preservatin Metadata: Implementatin Strategies (PREMIS) defines a schema t supprt digital preservatin activities and digital lifecycle management. The current schema can be fund at [10] LCDRG irods Trust Repsitries 8