This page is stable.
Note: for policies related to preservation, see the Infrastructure Policies Workspace.
Minimum requirements for an object to be allowed into the repository
Requirements for DLP-managed objects to be entered into the repository:
- The object must have a valid DLP Identifier.
- Any media files in the object must adhere to the Filename Requirements for Digital Objects.
- The object must adhere to the Minimum Object Metadata standards.
- Any XML in the object, whether primary data or metadata, must pass XML Validation.
- The object must conform to an existing Content Model, or have a new content model created for it.
- Each collection-level object must have established Collection Policies.
- Each item-level object must belong to a collection. Even if the object is referenced in multiple collections, it will have a single "primary" collection that is referenced by its DLP Identifier.
- The object's owner must intend for the object to be retained for a long time. "Temporary" objects are not allowed, and should be handled by some other means.
Some types of objects must meet more stringent requirements:
Minimum requirements for interchange objects
Interchange objects are objects that the DLP stores as a backup to another repository. The DLP is not the primary location for these objects, and the DLP does not make an effort to distribute these objects to end-users.
Requirements for storage of interchange objects:
- All of the requirements listed above for DLP-managed objects must be met, although it is possible for us to perform some conversion to meet these requirements. For example, if we recieve an object that does not meet our filename requirements, we may change the filenames and note this change in metadata so the original object may be reproduced.
- The originating repository must agree to our level of commitment.
- The object must indicate the "primary" repository that is responsible for its management.
Commitments we make for objects in the repository:
- For digitial files of Preferred Media Types, we will maintain the bits and migrate the objects to new formats. If a migration is necessary for an interchange object, we will notify the primary repository both before and after migration occurs (since the primary repository may prefer to do the migration and/or remove the object from our repository).
- For digital files of non-preferred types, we will maintain the bits. We will not attempt to migrate the files to new formats.
- We will not actively manage interchange objects (correct metadata errors, etc.). If we determine that a change to the object is advisable, we will pass this information on to the primary repository. The primary repository may then wish to deposit a new version of the object.