Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »


This page is under development. Some standards have been finalized, but not all.

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.

Requirements for "interchange" objects (objects we are storing as a backup to another repository):

  • All of the requirements for DLP-managed objects must be met, although it is possible for us to perform some conversion to meet these requirements. For exammple, 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 commitments.
  • The object must indicate the "primary" repository that is responsible for its management.

Other requirements will differ depending on object type:

Commitments we make for objects in the repository:

  • For objects of our preferred types (need to define these), 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.
  • For objects of non-preferred types, we will maintain the bits.
  • 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.
  • No labels