A Cross-Departmental Collaboration to Improve Digital Storage at The Metropolitan Museum of Art

Alexandra Nichols and Milo Thiesen
Electronic Media Review, Volume Six: 2019-2020

ABSTRACT

The authors researched a variety of digital storage options to improve practices at The Metropolitan Museum of Art. This study was commenced in part due to a file corruption incident and the recovery from it. This led to a cross-departmental investigation between members of The Met’s Digital, Information Systems & Technology, and Photograph Conservation departments to determine the extent of damage and identify its cause. Over a period of nine months, staff in the Digital Department and a Fellow in the museum’s Photograph Conservation Department worked to restore the corrupted files.

This file corruption incident sparked cross-departmental collaboration as a means to implement preservation functions not only for the artworks in the collection but also for non-art digital assets across the museum. The authors factored in the existing organization and culture of The Met in making their final recommendations for a digital storage software vendor who could provide assistance and perform digital storage functions. At the moment, these digital storage practices are being tested on a trial basis for the time-based media artwork collection, with the intention that if they are successful, they can be expanded to include The Met’s other high-value digital assets.

Disclaimer: The Metropolitan Museum of Art does not specifically endorse any vendor or product mentioned in this article.

Introduction

Although libraries and archives have been developing digital preservation practices for many decades, many museums are just now starting to grapple with the issues surrounding the preservation of their digital assets. Much of a museum’s digital footprint includes day-to-day office documents and communications, but there are additional assets that require a higher level of preservation and attention. In this article, these will be referred to as high-value digital assets, which include the following:

• Video, audio, and software relating to time-based media (TBM) artworks
• Digital files required to reprint photographic and sculptural artworks
• Video, images, and documents held in the archives
• Conservation documentation, including before/after treatment images and condition reports
• X-ray images, X-ray Fluorescence (XRF) and Fourier Transform Infrared (FTIR) spectroscopy, and other data from scientific research projects
• Artist interviews.

Many museums’ current data retention strategies are insufficient in addressing the storage needs of these collections, and as such they are at a heightened risk of corruption and permanent data loss. This article will describe efforts at The Met to formulate a digital preservation strategy to address the needs of the institution’s high-value digital assets.

Risks to a Digital Collection

There are many risks to a museum’s digital collection that could cause loss of data or lack of functionality. Data can become corrupted during the process of writing to storage media. In this instance, the data does not copy properly when moving a file from one folder to another, uploading a file to a different server or platform, or when backing up the data on a storage server. Data can also become lost through hardware failure, where the storage device holding the data ceases to function properly. Other risks to the collection come through loss of access—data contained in a file may not be able to be opened or read due to file format obsolescence, may be encrypted, or may require a current software license. Improper documentation can also make it hard for future users to understand the significance of digital files, as well as who created or authored the files and when. Finally, an institution could choose to no longer fund a certain initiative or continue a contract with a storage vendor, and, as a result, the data could be lost.

Development of Time-Based Media (TBM) Conservation at The Met

Since 2014, Nora Kennedy, the Sherman Fairchild Conservator in Charge for the Photograph Conservation Department, has advocated for the creation of a permanent TBM conservator position at The Met (fig. 1). In 2017, Alexandra Nichols, one of the co-authors of this article, joined The Met as its first TBM Conservation Fellow, working under Kennedy’s mentorship in the Photograph Conservation Department. From 2017 to 2019, Kennedy, Nichols, and photograph conservation administrator Mollie Anderson worked with external contractors Glenn Wharton, Lia Kramer, and Lorena Ramírez-López to complete The Met’s TBM Assessment [1], a multiyear evaluation of The Met’s policies and practices toward the care of TBM conservation. This assessment helped foster interest and support for TBM conservation from The Met’s upper administration. As a result, in 2019, The Met hired Jonathan Farbowitz as an associate conservator of TBM.

2017 File Corruption Incident

In the summer of 2017, Christine Frohnert, a contract TBM conservator working with The Met, and Nichols found that some of the video files in The Met’s collection were not playing properly. It was originally thought that the reason these files were not able to open was due to previous errors copying the files from the artist-provided drives to a file share server set up by The Met’s Information Systems & Technology (IS&T) Department. The Met has a policy of duplicating artwork files onto The Met’s file share due to the high rate of hard drive failure (Beach 2013) and obsolescence issues relating to tape media. Unfortunately, a lack of staffing meant that The Met was unable to institute a practice of verifying file integrity when transferring files from artist-provided drives to the server.

However, soon after this problem was noticed within the TBM collection, The Met’s lead technical analyst in digital asset management, Milo Thiesen (a co-author of this article) reached out to Nichols and Kennedy to inform them that some of the video files in the Digital Department were experiencing the same issue, thus establishing that this was not just an initial transfer issue but possibly a recurring problem caused by something in The Met’s information technology (IT) infrastructure.

Investigation

In response, the Photograph Conservation, Digital, and IS&T departments (fig. 2) formed a team to meet on a weekly basis to investigate The Met’s digital storage issue.

The committee’s first objective was to determine what was causing the file corruption. After identifying a corrupted file, Thiesen and Nichols examined it using MediaInfo, a free, open-source metadata extraction program that is geared toward examining video and audio files. Figure 3 shows the MediaInfo report for the metadata of the intact video file on the artist-provided hard drive. This report contains information about the video and audio streams of the file, including the codec and container of the file; the video’s duration, resolution, and framerate; information about the audio tracks embedded in the file; and more.

Figure 4 shows the MediaInfo report for another copy of the same file, this one having been stored on The Met’s TBM server and no longer able to be opened. In contrast to the MediaInfo report for the artist-provided file in figure 3, the MediaInfo report for the one stored on The Met’s servers no longer contained information about the video, audio, and timecode data streams—only the filename, general format, and file size remained.

The authors consulted with Dave Rice, an archivist at the City University of New York who focuses on audiovisual material and is a contributor to MediaArea [2], to see if he had seen files that exhibited similar corruption patterns. Thiesen proposed that the affected files were missing their MOOV atom, and that this resulted in the files being unable to open or to be played. The MOOV atom is a bit of data contained within a video file that contains technical information about the file, such as the codec, the display information, and the duration of the file (Apple Developer Documentation Archive 2020). A lack of a MOOV atom would result in the metadata report being truncated as seen in figure 4. Rice indicated that although he had not come across video files that had exhibited this behavior in the past, Thiesen’s theory regarding the MOOV atom was likely correct.

The authors further examined the files using HexFiend, a hex editor program that looks at the binary data contained in a file and displays it in a hexadecimal form using alphanumeric characters, which is more human readable than the 0s and 1s used in base-2 binary code. HexFiend was used to compare the binary data in the functional video file on the artist-provided hard drive with the corrupted file on The Met’s servers. Sometimes files can become corrupted even when just one bit of data is changed, so the authors’ hope was that if the two files were mostly similar, the files on The Met’s servers might be restored easily by editing the raw data to match the intact copy.

However, the authors found that there were drastic differences between the two files—the corrupted file’s binary data was mostly composed of 0000s, which indicated that much of the data had been erased (fig. 5). This means that the files would not be able to be easily restored using a hex editor or other data recovery software, but would have to be manually replaced by using an intact copy stored elsewhere.

Cause of the File Corruption

There is little published research diagnosing the causes of file corruption, but there are many Internet forums where IT specialists discuss issues with specific hardware and software. Using the information that the authors gathered about the symptoms of the files, Fred Deumig, The Met’s senior IT infrastructure engineer, discovered that a specific combination of hardware and software in use at The Met resulted in a bug that causes file corruption when a file is copied or moved. The problem Deumig identified occurs when an organization has set up share drives (drives on a server that multiple users can access and edit) running on a Windows 7 or Windows 2008R2 operating system while also running RoboCopy version 5.1.10.1027 file duplication software. If this setup is paired with NetApp Fabric-attached Storage external backup servers that are running on the OnTap version 8.3.1 operating system, this can cause a bug that can affect files greater than 512 MB (fig. 6). In this case, the first 512 MB copies properly, but the remaining data in the file is erased. Once this bug was identified, The Met’s IS&T team upgraded the software and hardware used in their IT infrastructure to fix the issue and prevent further corruption.

Data Restoration

Now that the team had prevented further corruption from taking place, the next step was to restore the files that had been affected. Since the authors had established that the corrupted digital files on The Met’s servers could not be restored back to their original content using the existing data, the only course of action was to go back to the last known intact copies and transfer them onto The Met’s file share servers, replacing the corrupted files.

In the case of the TBM artworks, this meant going back to the artist-provided hard drives, flash drives, and DVDs and copying these files onto the TBM server. The artist-provided media was accessed using a write-blocker, also known as a forensic bridge (fig. 7) to prevent accidentally corrupting or altering the intact information on the drive, and the files were transferred using the bag specification of the Library of Congress (2020) to ensure that they copied accurately and to document the transfer.

In the Digital Department, the team found intact versions of some of the corrupted files on another server that had not experienced file corruption. Some other files were restored by transferring the data from XDCAM tapes that held some of the affected files. Other files had benefited from a bit of accidental redundancy—they had been copied over into staff members’ personal folders so they could work on a project and had not yet been deleted. In the end, this process took three staff members nine months to complete.

Identification of Improvements to Digital Storage Practices

The primary focus of this article is the response of the three departments at The Met (Photograph Conservation, Digital, and IS&T) and how they together sought to improve digital storage practices at the museum.

As part of the response, the committee had to clarify exactly what practices IS&T had in place for digital storage. Retaining large amounts of data can be costly, so it is common for IT departments to employ methods to reduce the amount of data they need to store. One of the methods to do this is called de-duplication, which scans servers and removes duplicate copies of files. File compression is another method used to reduce space—in this case, an algorithm discards a certain amount of information in a file to make it smaller. Another thing to consider is the length of an institution’s backup retention cycle.

If an institution is on a 90-day retention cycle, one only has 90 days to identify and restore files that experience file corruption before losing the ability to access the original uncorrupted file.

These space-saving practices are generally appropriate for day-to-day office documents; however, they are not advisable for high-value digital assets, where the goal is to maintain multiple copies of high-resolution or uncompressed files for long periods of time. After speaking with The Met’s IS&T team, they agreed to treat high-value digital assets differently from all other digital files in the museum. Considering that IT departments are often unaware of the significance or content of the data they manage, it is important that conservators and archivists work together with their institution’s IT department to identify data that requires a higher level of digital preservation.

Once the committee established which practices were being performed on high-value digital assets, they could also identify improvements. For example, increasing file redundancy, or the number of duplicate copies retained, would greatly reduce the risk of permanent data loss. Industry standards for digital preservation recommend maintaining three distinct copies of any data you want to retain, preferably with one of those copies being stored in a different physical location (Digital Preservation Coalition 2020).

The Met’s IS&T Department agreed to increase the data retention cycle for high-value digital assets from the normal 90 days used for office documents to a three-year retention span. Data identified in this special group would not have de-duplication or compression applied to it. This established two different classes of data, each with its own preservation policies.

Risk would also be greatly reduced by introducing regular fixity checks. Fixity checks are achieved through comparisons of a file’s checksum over time. Checksums are alphanumeric strings generated by running a hashing algorithm on the file. If the data in a file changes, and the same checksum algorithm is run again, it will return a completely different value (fig. 8). Regular fixity checks are an essential tool in alerting stakeholders if high-value digital assets are experiencing unintended changes.

Finally, monitoring for file obsolescence reduces the risk of data loss due to the inability to access the content of the files.

To determine how these practices should be implemented at The Met, the authors interviewed colleagues at other institutions [3] to learn about their approaches and the lessons they discovered along the way. Many museum colleagues told the authors that digital storage is something they grapple with as well—for example, regular fixity checks are a goal for many but not yet realized. Many were only able to do spot fixity checks or to conduct a check manually when a digital file was accessed for an exhibition or other use. Smaller collections reported that they can manually process digital assets, but larger institutions reported that this becomes impossible at a certain scale, and automation becomes necessary. Some institutions warned against creating a system that is too bespoke and cannot be updated easily, as it is difficult to adapt to new needs.

The authors noted that any proposed solution must be sustainable to be effective—digital preservation is not a one-time treatment but an ongoing issue that requires regular attention and maintenance. Considering that every museum has its own structure, needs, and resources, a digital preservation solution that works for one museum might be ineffective in another museum, so it is important to pick a solution that addresses the institution’s specific needs. At this point in time, The Met had not yet committed to hiring a TBM conservator or other staff member who could dedicate sufficient time to overseeing these preservation practices. Based on the resources available, the committee decided that The Met would need an outside vendor to help manage its digital preservation needs.

Of course, hiring a vendor to manage digital preservation practices requires funding and support. Although the committee already had the support of the Digital, Photograph Conservation, and IS&T departments, it was now time to advocate for assistance from the administration as a whole. Luckily, advocacy for digital storage improvements dovetailed with the completion of the TBM Assessment, which evaluated the state of The Met’s collection and the policies and procedures in place for the care of TBM artworks. Recommendations within the report supported the committee’s suggestions to hire an outside vendor to improve digital preservation practices, and the committee was successful in garnering administrative and institutional support.

Vendor Evaluation

The first step that the authors took in the vendor evaluation was to create a standardized list of requirements, preferences, and questions. The top priorities were to find a vendor that implements the OAIS model in their technical architecture and workflows. The authors drew heavily from the National Digital Stewardship Alliance (NDSA) Levels of Digital Preservation version 1 (OSF 2013). Version 2 (NDSA 2020) of this document is available now but was not available at the time the research was being conducted. The authors wanted a system that could do fixity checks on ingest and in place, monitor file format obsolescence, and allow for geographically distributed storage. The authors asked about the vendor’s standard licensing agreements; the underlying technologies used to create and maintain the software, storage, and technical architecture; the size and age of the company; possible exit strategies; and the future migration plans for their storage technologies. The authors also asked about the vendor’s application security, security testing, application scalability, and virus scanning.

Based on the authors’ interviews with practitioners at other institutions, three potential vendors were identified: Archivematica, Preservica, and Digital Bedrock.

OAIS

OAIS stands for Open Archival Information System. It was originally developed as a conceptual model (independent of any specific hardware or software implementation) by the Consultative Committee for Space Data Systems, and it was first approved as ISO Standard 14721 in 2002. “OAIS is an archive consisting of an organization of people and systems that has accepted the responsibility to preserve information and make it available to a Designated Community” (OAIS 2020) (fig. 9). OAIS is widely adopted in museums, libraries, and archives, with a particular focus on information packages.

OAIS Information Packages
The following three information packages are part of the OAIS model and may or may not be identical to each other depending on how they are implemented (fig. 10):

• Submission Information Package (SIP): The information sent from the producer to the archive. It includes any files being added to the system, as well as any descriptive, administrative, or technical metadata.
• Archival Information Package (AIP): The information stored by the archive. Once ingested, the SIP becomes the AIP and includes robust technical metadata, fixity monitoring information, and other documentation.
• Dissemination Information Package (DIP): A subset of information from the AIP for access. Often this is descriptive and administrative metadata and an access copy/derivative of the preservation master. The DIP can include all or some of the technical metadata.

Vendor Selection

Nichols and Thiesen evaluated the same three different vendors for assistance with The Met’s digital preservation strategy (table 1). Archivematica is an open-source software (developed by Artefactual Systems) that utilizes standards-based tools to create system-independent SIPs, AIPs, and DIPs (Archivematica 2020), and is hosted on a local server. Preservica is a digital preservation system that can be hosted on-site or in the cloud using Amazon or Azure cloud storage (Preservica 2020). Preservica also includes features similar to a digital asset management system. Digital Bedrock is a digital preservation system and managed service that stores digital assets on LTO data tapes (Digital Bedrock 2020). It includes file format obsolescence monitoring with notifications, storage in three geographically distributed locations, client side to server side fixity checks on ingest, and checks fixity in place. SIPs can be stored across multiple LTO tapes. For example, some large DPX packages might not fit onto one tape, or clients can have more than one SIP per tape, but Digital Bedrock recommends that Met staff write one SIP per tape to simplify the exit strategy.

Vendor and Storage Method	Pros	Considerations
Artefactual/Archivematica: Hosted on a local server	● Widely adopted in museums, libraries, and archives ● Staff is highly knowledgeable ● Community driven ● Uses established standards like METS/PREMIS	● No scheduled fixity checks ● No file format obsolescence monitoring with notifications ● Storage solution not included
Preservica: Hosted on-site or in the cloud	● Robust system with many features ● Technical support included ● Software as a Service (SaaS) option available to handle hardware/software upgrades	● User interface was not intuitive ● System is not optimized for large files or complex media (based on demos/tests)
Digital Bedrock: Off-site storage on LTO tapes	● Highly knowledgeable staff ● LTO tape migration included ● File format obsolescence monitoring built in ● Built to handle large amounts of AV materials	● To simplify the exit strategy, SIPs should be around the size of an LTO tape, which can require more planning in the staging process

All three vendors offer great products, and they have been implemented successfully at museums and archives across the United States. After careful consideration, the authors found Digital Bedrock to be the best fit for The Met’s current needs.

Digital Bedrock Implementation

The Photograph Conservation Department at The Met is now working in collaboration with co-author Thiesen on testing various workflows in preparation for fully implementing Digital Bedrock as a storage vendor. This includes the following actions:

• Understanding the system
• Testing the SIP tool
• Understanding constraints
• Defining a staging area
• Developing cataloging standards in the museum’s collection management system
• Conducting an artwork server audit.

Understanding the System
The Digital Bedrock service is made up of three high-level parts: the Digital Preservation Application (DPA), which is responsible for processing files and extracting technical metadata; the Digital Object Obsolescence Database (DOOD), which is responsible for monitoring file format obsolescence; and the SIP tool, which is the client-side tool used to ingest files and submit descriptive metadata to Digital Bedrock.

The DPA is the core preservation tool that processes files. Digital Bedrock staff can see the checksum values, the algorithm used, the creation date, who created it, and the software used to generate the checksum. They can also view the history of each fixity check.

Metadata within the DPA includes the following:

• Checksum value
• Algorithm used
• Checksum creation date
• Checksum creator
• Checksum creator software
• Fixity check history
• Technical metadata extraction
• Event documentation.

Technical metadata about each file is extracted and indexed using software including ExifTool, MediaInfo, ffprobe, Tika, JHOVE, and Sox. Events or actions related to the SIP or an individual file are documented and attached. This can include e-mails from clients, renaming requests, file download requests, and more.

The DOOD is connected to the DPA, another part of the vendor’s backend (fig. 11). This monitors which file formats are at risk of obsolescence and is under U.S. patent no. 10592674.

SIP Tool and Staging

The Digital Bedrock SIP generator (fig. 12) guides users through assessment, de-duplication, cost estimation, adding descriptive metadata, renaming, calculating client-side checksums, packaging into the Digital Bedrock SIP format, and then delivering the SIP to the vendor.

SIPs can be delivered on an external hard drive that is mailed to Digital Bedrock’s data center or by using Digital Bedrock’s integration with FileCatalyst, a cloud-based file transfer acceleration tool. Delivery methods to the vendor will vary depending on the size of the SIP and the speed of the user’s Internet connection. Some museums are fortunate enough to have a 10-GB Internet connection, but it is still fairly rare in museum infrastructures, especially in older buildings. It is certainly still possible to use FileCatalyst with a 1-GB or even a 100-MB connection; however, in some cases, it may be faster to ship a hard drive than it is to transfer a large package over a slow connection.

At the time of this writing (2020), Digital Bedrock uses LTO 7 tapes, so at the moment the limit is five to six terabytes per SIP; that is one SIP is equivalent to one tape. Cost estimates are based on the number of tapes used, so to be more cost effective, Met staff need to work within the constraint of the tape’s storage capacity.

To accomplish this, Met staff need to establish a staging area where multiple artworks are written onto one SIP. One option would be to write one artwork per tape, but that would be an additional cost. Each new generation of LTO tape has a larger and larger capacity, so learning to work within this constraint will save the museum money over time. Digital Bedrock will be moving to LTO9 in 2021 Q1-Q2, which means that 20 TB will fit onto one LTO.

Cataloging and Auditing

Farbowitz, an associate conservator of TBM, has been leading a cross-departmental team to refine The Met’s cataloging standards for TBM art. This team includes Diana Díaz-Cañas, assistant conservator in Photograph Conservation; Ashley Hall, manager of collection information in the Digital Department; Thiesen; and Caroline Gil, Andrew W. Mellon Fellow in Media Conservation, who spent the previous two years of her fellowship at the Museum of Modern Art (MoMA).

The Met is heavily influenced by MoMA’s TBM workflows [4]. In the current workflow, an object record’s components are used to track status, relation, and location information (fig. 13). Before ingest into Digital Bedrock, the files not only need to be cataloged but also need to be as organized as possible.

In the following, a simplified high-level workflow of the digital preservation actions that are currently performed for The Met’s TBM artworks is shown. However, this is the ideal workflow—there are many artworks that have specific needs requiring variations from this workflow. These preservation actions are now being applied to a considerable backlog (essentially any artwork acquired prior to 2019). A team of two conservation staff and one fellow are working through the backlog, which will hopefully be completed by the end of 2021.

Farbowitz leads bi-weekly meetings to monitor the progress of the audit and to answer any outstanding questions.

Simplified ingest workflow:

1. Transfer files to staging area
2. Examine metadata
3. Condition check files
4. Update collection cataloging database
5. Bag files
6. Transfer to TBM file share server
7. Send bags and metadata to Digital Bedrock
8. Update collection cataloging database with information about transfer to Digital Bedrock
9. Create viewing copies
10. Complete documentation.

Next Steps and Conclusions

After the artwork server and cataloging is complete, a taxonomy will need to be defined for the files in Digital Bedrock and a decision will need to be made about whether or not to send the vendor any descriptive or administrative metadata along with the artwork files. The Met will use the Digital Bedrock SIP tool to ingest the assets into the digital preservation repository.

Met staff also need to decide on where to locate the file staging area. The data can either be staged on premise, or the artwork files can be sent to a staging area hosted by Digital Bedrock where they will run backups while the data is waiting to be written to a tape.

When Kennedy first started advocating for a TBM conservator in 2014 through the present, and now with the staff and systems to carry forward, the authors are thrilled to see how far The Met has come. This process has highlighted how important it is to communicate with other stakeholders within the museum, work cross-departmentally to understand digital storage systems, identify where specific files are stored and why, and how critical it is to develop strong and specific digital preservation policies and practices.

ACKNOWLEDGEMENTS

The authors would like to extend heartfelt thanks to the many Met team members who contributed to this project, including Nora Kennedy, Steve Ryan, Jeff Spar, Fred Deumig, Bryan Martin, Kaelan Burkett, Jonathan Farbowitz, Caroline Gil, Diana Díaz-Cañas, Jennie Choi, Claire Dienes, Ashley Hall, Kate Farrell, Melissa Bell, Meredith Reiss, and Catherine Burns. The authors would also like to thank Dave Rice, Amy Brost, and Christine Frohnert for their generous advice and guidance.

REFERENCES

Apple Developer Documentation Archive. 2020. QuickTime File Format Specification. Accessed December 7, 2020. https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-SW1.

Archivematica. 2020. Accessed December 7, 2020. https://www.archivematica.org/en/.

Beach, Brian. 2013. How Long Do Disk Drives Last? Accessed December 7, 2020. https://www.backblaze.com/blog/how-long-do-disk-drives-last/.

Brost, A. 2020. Building a Storage System for Digital Art Objects at MoMA: The First Decade. Paper presented at the 48th Annual American Institute of Conservation Virtual Meeting.

Central Park Conservancy. 2018. The Story of Seneca Village. Accessed December 7, 2020. https://www.centralparknyc.org/articles/seneca-village.

Digital Bedrock. 2020. Accessed December 7, 2020. https://www.digitalbedrock.com/.

Digital Preservation Coalition. 2020. Digital Preservation Handbook. Accessed December 7, 2020. https://www.dpconline.org/handbook/organisational-activities/storage.

Library of Congress. 2020. Bagit-Python GitHub Repository. Accessed December 7, 2020. https://github.com/LibraryOfCongress/bagit-python.

Liebman, Bennett. 2018. The Quest for Black Voting Rights in New York State. Accessed August 28, 2018. https://www.albanylaw.edu/centers/government-law-center/Documents/The-Quest-for-Black-Voting-Rights-Liebman.pdf.

MediaArea. 2020. MediaArea: About. Accessed December 10, 2020. https://mediaarea.net/.

Nanticoke and Lenape Confederation. 2017. The Keepers of the Land. Accessed December 7, 2020. https://nanticokelenapemuseum.org/museum/628/the-keepers-of-the-land/.

Nanticoke Lenni-Lenape Tribal Nation. 2020. Land Acknowledgement. Accessed December 7, 2020. https://nlltribe.com/land-acknowledgement/.

NDSA. 2020. Levels of Digital Preservation. Accessed December 7, 2020. https://ndsa.org/publications/levels-of-digital-preservation/.

OAIS. 2020. OAIS Reference Model (ISO 14721). Accessed December 7, 2020. http://www.oais.info/.

Opentext Security. 2020. Tableau Forensic 3.0 USB Bridge. Accessed December 10, 2020. https://security.opentext.com/tableau/hardware/details/t8u.

OSF. 2013. 2013 Levels of Digital Preservation. Accessed November 16, 2020. https://osf.io/9ya8c/.

Preservica. 2020. Accessed December 7, 2020. https://preservica.com/.

Wikipedia. 2020a. Central Park. Accessed December 7, 2020. https://en.wikipedia.org/wiki/Central_Park.

Wikipedia. 2020b. Checksum. Accessed December 10, 2020. https://en.wikipedia.org/wiki/Checksum.