| Current Module Downloads: Module C4 Activity Worksheet |
|---|
The activities discussed in this module focus on protecting and maintaining the integrity of your work over time, from the platform level down to the bit level. The permissions section asks you to assess which team members have read, write, and delete authorizations for each technology used. The data integrity section details actions that will help project members ensure that the files they are preserving remain, if desired, fixed or unchanged.
Permissions
This area is primarily dedicated to determining and documenting which team members have access to the technological components of your project and what actions they are allowed to perform. At Level 1, this means identifying who has read, write, and delete permissions for specific files, whereas at Level 4, this means creating and auditing logs of all actions taken on your files in order to closely monitor change and prevent loss. If your project needs and/or uses version control software such as Git or Subversion, you may already be working at Level 3 in this area.
Working through this section, you will find it helpful to refer back to Module B1, where you identified project members and roles, Module B2, where you identified your project’s technological infrastructure, and Module B3, where you’ve made connections between staff and technology. If you’ve worked through those each of those modules, you’ll find that you’re already in good standing to address the sustainability levels detailed below. Monitoring staff access and permissions is important not only for preventing accidental data losses or changes, but also for preparing for transition planning in the event that a project team changes.
| Level 1 | Level 2 | Level 3 | Level 4 | |
| Permissions | Identify which project members have login credentials to accounts and services used
Identify which project members have read, write, move, and delete authorization to individual files |
Restrict authorizations to only necessary team members
Document access restrictions for services and files |
Maintain logs of who performs what actions on files, including deletions and preservation actions | Perform routine audits of activity logs |
Data Integrity
The second area in this module, Data Integrity, focuses on the physical attributes of the digital content itself. The activities in this area are intended to ensure that you are preserving the digital materials you intend to preserve, and that changes to files at the bit level do not go unnoticed.
Straight away, you will certainly notice that the Level 1 behaviors for this area are identical to the Level 1 behaviors for the “Permissions” area above. This is because the first line of defense against data corruption is recognizing that people are capable of making mistakes, and that restricting access to files is not always about trust. It is also about limiting risk. Knowing who has access to perform which actions on which platforms and which files is good project management and is the first, best thing you can do to help protect the integrity of your data.
Level 2 introduces the professional notion of “fixity.” Put simply, fixity refers to a digital object’s quality of being fixed or unchanged. To create fixity information, you can use a checksum or cryptographic hash. For a more in-depth explanation of fixity, see the NDSA publication “Checking Your Digital Content: What is Fixity and When Should I Be Checking It?” To learn more about cryptographic hashes, see this post by Bill LeFurgy from the Library of Congress’s blog, The Signal, “Hashing Out Digital Trust.” Some off-the-shelf content management systems, such as CollectiveAccess, create checksum information upon ingesting digital files, so do check in with your system documentation to find out if you are already performing this activity.
However, simply creating fixity information will not be enough to actually offer you sustaining help should something go wrong—knowing that a file has been corrupted will not do much good without being able to repair the issue. For this reason Level 2 also indicates that you must also be able to replace corrupted information when you find out that there is a problem. To assure yourself that this would be possible, please refer back to your work in Module C2, specifically in the section on Backing Up Your Work. Will you have sufficient copies, and access to those copies, to repair any corrupted files?
It is particularly important in this area to remember that each of these levels may not be applicable to every project. Fixity information is likely to be more valuable in some projects than in others: namely, it may not be very meaningful to check and regularly update the fixity information of files that are being actively developed or altered because it is in the nature of such information to keep changing over time. On the other hand, if your project is centered on a curated collection of stable digital images, the fixity information of those files may be mission-critical. Keep this in mind as you consider your ideal level in this area.
| Level 1 | Level 2 | Level 3 | Level 4 | |
| Data Integrity | Identify which project members have login credentials to accounts and services used
Identify which project members have read, write, move, and delete authorization to individual files |
Be able to replace/repair corrupted data
Create fixity information for stable project files |
Check fixity of stable content at fixed intervals | Check fixity of stable content in response to specific events or activities |
Additional Resources
Bailey, Jefferson, “Protect Your Data: File Fixity and Data Integrity.” Library of Congress The Signal Blog. April 7, 2014. https://blogs.loc.gov/thesignal/2014/04/protect-your-data-file-fixity-and-data-integrity/.
De Stefano, Paula, et al. “What is Fixity and When Should I Be Checking It?” Checking Your Digital Content: An NDSA Publication. Accessed September 23, 2022. http://www.digitalpreservation.gov/documents/NDSA-Fixity-Guidance-Report-final100214.pdf.
Gladney, H. M. and J. L. Bennett. “What Do We Mean by Authentic? What’s the Real McCoy?” D-Lib Magazine 9, no. 7/8 (2003). http://www.dlib.org/dlib/july03/gladney/07gladney.html.
Hedstrom, Margaret L., Christopher A. Lee, Judith S. Olson, and Clifford A. Lampe. “’The Old Version Flickers More:’ Digital Preservation from the User’s Perspective.” American Archivist 69, no. 1 (Spring/Summer 2006): 159-187. https://doi.org/10.17723/aarc.69.1.1765364485n41800.
Zwaard, Kate. “Hashing Out Digital Trust.” Library of Congress The Signal Blog. Accessed September 23, 2022. https://blogs.loc.gov/thesignal/2011/11/hashing-out-digital-trust/.
(Module last updated )
| Previous Module: Module C3: File Formats & Metadata | Next Module: Module C5: Digital Sustainability Action Plan |
|---|