126.96.36.199 Policies about preservation responsibility
|188.8.131.52 Policies about preservation responsibility|
|Status||Ready for review|
|Compliance Rating||Fully compliant|
The repository shall have written policies that indicate when it accepts preservation responsibility for contents of each set of submitted data objects.
This is necessary in order to avoid misunderstandings between the repository and producer/depositor as to when and how the transfer of responsibility for the digital content occurs.
Examples for Meeting the Requirement
Properly executed submission agreements, deposit agreements, and deeds of gift; confirmation receipt sent back to producer/depositor.
If this requirement is not met, there is a risk that, for example, the original is erased before the repository has taken responsibility for the submitted data objects. Without the understanding that the repository has already taken preservation responsibility for the SIP, there is the risk that the producer/depositor may make changes to the data and these would not be properly preserved since they had already been ingested by the repository. For example, for convenience the repository could receive a copy of raw science data from the instrument at the same time the science team gets it, but the science team would have responsibility for it until they turn over responsibility to the final repository. Repositories that report back to their depositors generally will mark this acceptance with some form of notification (for example, confirmation receipts) to the depositor. (This may depend on repository responsibilities as designated in the depositor agreement.) A repository may mark the transfer by sending a formal document, often a final signed copy of the transfer agreement, back to the depositor signifying the completion of the transformation from SIP to AIP process. Other approaches are equally acceptable. Brief daily updates may be generated by a repository that only provides annual formal transfer reports.
- Preservation responsibility transfer occurs when APTrust has fully ingested the content. See the APTrust Sustaining Member Deposit Agreement (current adopted version) September 2015
- See the Ingest and Stewardship/Responsibility for Materials for information about when APTrust becomes responsible for preserving depositor materials. In addition to a Web UI and REST API that can tell depositors when an item has been fully ingested into APTrust, our Partner Tools include a component to query APTrust about the state of any bag uploaded by a depositor.
- See the Submission & Ingest for the specific responsibilities during ingest. Also see the S3 Receiving Buckets for more detail.
- Transforming SIPs into AIPs includes both written and visual documentation about the process by which APTrust converts a depositor's SIP into and AIP.
- Restoration using Pharos Web-UI describes how depositors can initiate and check the status of restoration requests.
- Alerts describes how we notify depositors of failed ingests, stalled ingest, failed fixity checks and other problems affecting their materials.
- Use OAI-S language for the SIP Manifest
- See the Reporting section for responsibilities during regular maintenance.
- Depositors may use the Reporting section for details on how to view progress reports.