B5.4 Repository can demonstrate that referential integrity is maintained between all
archived objects (i.e., AIPs) and associated descriptive information.
Particular attention must be paid to operations that affect AIPs and their identifiers and how integrity is maintained during these operations. There may be times, depending on system design, when the repository cannot demonstrate referential integrity because some system component is out of action. However, repositories, must implement procedures that let them know when referential integrity is temporarily broken and ensure that it can be restored.
Evidence: Log detailing ongoing monitoring/checking of referential integrity, especially following repair/modification of AIP; legacy descriptive metadata; persistence of identifier/locator; documented relationship between AIP and metadata; system documentation and technical architecture; process workflow documentation.
I've given this TRAC requirement considerable thought, and have searched the web for examples on how others have answered this requirement, but I still don't think I have a firm grasp on exactly what it means, and how I would demonstrate compliance.
It is certainly the case that we have a list of AIPs, and each item on this list contains both a pointer to the content which we're preserving in Archival Storage and metadata about the object. So is that referential integrity? Or is it necessary, but not sufficient, for referential integrity? I don't know.
In our case at ICPSR, we just don't modify or repair AIPs all that often. But if we did, would I need to maintain a log or ledger of the "before AIP" which maps it to the "after AIP"? And having that log would be my evidence of compliance?
I would be interested in hearing from others. How do you interpret this item? What is your evidence?
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.