Download (PDF, 9MB, Not barrier-free file.) - Nestor

versioning functionality which allows the linking of digital objects via their IDs and todescribe the nature of the relationship with the help of Dublin Core metadata.Different approaches were also taken to authenticating the source of materialsubmitted to the repositories. Of all three repositories, as an institutional repository with aclosed and clearly defined community of (potential) depositors, JUWEL is certainly in themost comfortable position, whereas both Qucosa and pedocs are in a more difficultsituation as their communities of potential depositors are much bigger and in many casesmuch further removed (geographically, institutionally) from the repository, makingcommunication a greater challenge, for example. Thus, although Qucosa is also auniversity-based institutional repository, potential depositors also come from a largenumber of different and very heterogeneous institutions throughout Saxony. Inconsequence, and to compensate for this lack of “closeness” between repository anddepositors, Qucosa and pedocs use contracts in the form of author agreements toascertain that depositors are who they claim to be and hence have the right to deposit thematerial in question.In the functional entity of Archival Storage, the question of how each repositoryprotected the integrity and authenticity of its digital objects is of particular interest andrelevance – not only because the repositories must be able to protect their digital assets inthe time span elapsing between submission by depositors and harvesting by ortransmission to the long-term archive, but also because users accessing the digitalcollections must be certain at all times that they are viewing authentic, uncorrupteddocuments. In this context it was recommended that pedocs and Qucosa implement a toolor program similar to the DSpace checksum checker in order to make sure that anychanges of checksums are detected as quickly as possible. In addition, all threerepositories should develop a policy spelling out which steps are to be taken if thechecksum of an object is found to have changed, and how this object will be treated bothin relation to access and long-term preservation.Of particular interest was also the question of metadata changes. In all threerepositories metadata can be changed only by authorized staff. For reasons oftransparency it seems nonetheless important that such changes are documented, e.g.with a time stamp and a history note explaining the nature of these changes. Such adocumentation procedure has been implemented in pedocs and should be considered bythe other repositories as well – in particular as the checksums, indicating the integrity andauthenticity of the digital objects, are part of the metadata.In the Data Management functional entity, none of the repositories worked withactual information packages in the sense of actual containers; instead, (virtual) AIPs aremanaged by means of the relational databases and DBMS of the repository software.Although a new DSpace functionality is currently being developed which will allow for thecreation and storage of actual AIPs, whether this is a useful and necessary feature for a77