Will Tew

As the 2025-2026 Archives Fellow, I spent a significant portion of my time dedicated to refining the processes related to the preservation of Franklin Furnace’s digital materials. In particular, I worked on establishing a process for creating and validating fixity metadata for materials in the Event Image and Moving Image collections. 

Throughout its 50 year history Franklin Furnace has amassed a large collection of digital objects including digitized and born-digital video and photo documentation of performances (which are stored in the Event Image and Moving Image collections), supporting documents and ephemera in the Vertical Files collection, and digital surrogates of physical objects, such as the Ree Morton sketchbooks. These materials are stored across multiple network-attached storage (NAS) devices and on a cloud-based server for greater redundancy. While the digital collections prior to my fellowship project were well organized with consistent naming conventions and established workflows in place for the creation of derivatives to service FF’s various archival viewing platforms, there was a lack of documentation in regards to maintaining and checking fixity metadata. 

Fig 1. Akio Suzuki performing Soundaround, March 25, 1983. An example of photo documentation in the Event Image database.

Fixity is a bedrock concept in the world of digital preservation. In the simplest terms, it is information which can tell an archival practitioner whether or not a file has been altered or corrupted. While basic metrics such as file size or file count can be used to determine the stability of an object, it is common in the archival world to use algorithmically derived checksums. These are strings of letters and numbers which represent the byte-level construction of a digital asset which can be used to track imperceptible changes in a file.

While data is relatively safe when it is static, moving or transferring files introduces room for error and data loss. The concern is not that a file might become corrupted while it is sitting on one of the Franklin Furnace servers, but rather that data loss might happen when files are transferred between our storage locations. Fixity metadata allows us to ensure that files maintain their byte-level integrity before, during and after any migration process. 

A popular tool to package fixity information alongside archival materials is the Library of Congress’ BagIt file hierarchy standard. Developed throughout the 2000s to address the risks inherent to transferring large amounts of data, BagIt specifies that digital materials be stored in a payload folder titled “data” alongside descriptive and fixity metadata in individual text documents. These text documents can be used by various software packages to validate the contents of a folder. An example of a folder in Franklin Furnace’s Event Image stored according to the BagIt standard is below. 

Fig 2. An example of the BagIt hierarchy applied to the Event Image folder for Annea Lockwood’s Play the Ganges Backwards, One More Time, Sam. 

The problem of organizing the Event Image and Moving Image collections according to the BagIt standard primarily stems from their size—the Moving Image collection is 42TB and the Event Image collection is 1.8TB. While it would be possible to individually “bag” every folder in these two collections via a command line interface, this would be a tedious and arduous process; one that would have to be repeated every time someone wanted to validate the contents of the bags. To ensure that this process can actually be utilized for day-to-day preservation practices, it was essential that portions of the process be automated programmatically.

Taking inspiration from the New York Public Library’s Audio and Moving Image Preservation Team’s open-source digital preservation scripts, I set out to write a program which could be used to bag and validate files in large batches. Because both the Event and Moving Image collections contain their own unique folder hierarchies, it was necessary to ensure that the bagging process could be modified according to the collection that was being processed. The program simply iterates through directories based on conditions unique to the Event Image and Moving Image collection and uses the Python instantiation of bagit to process the files.

Fig 3. The final version of the BagIt script utilizing the Python library, Gooey, to build a simple graphical user interface.

To prepare the files in the Event Image collection for bagging, I also dedicated time to standardizing the folder structure for files within a given artist’s parent folder. Prior to this process, all image files were grouped under the artist’s folder, even if the artist had produced multiple disparate events at FF. While this doesn’t affect the bagging process per se, a large collection of image files can be difficult to navigate by a user; it is up to them to recognize changes in the date to distinguish distinct performances. To remedy this issue, I first went through the entire Event Image collection and placed event images in folders titled with the format of LASTNAME_FIRSTINITIAL_MMDDYY. This is also advantageous as it makes the process of adding files to bags a lot simpler. If additional materials are added to a bag, it is necessary to update the manifest file by regenerating the checksums of every file in the folder. Maintaining event-specific bags ensures that computational resources are not wasted should files need to be added and/or edited. 

This was also a helpful process as it allowed us to audit the contents of every artist’s folder and check for misplaced files or inconsistencies in naming conventions. Because many of these files had been created over a decade ago, it is expected that a number of materials might get accidentally misplaced or saved using non-standard naming conventions. 

After writing the script I documented every aspect of its structure and use so that in the future it can be connected to other archival processes such as creating derivative files or generating title graphics for video documentation. Because this was an early experiment in programmatically generating bags, there is certainly a lot of room for further optimization by future Franklin Furnace interns and fellows and this documentation will ensure that changes can be integrated seamlessly.

At the end of this project we were able to bring the entire Event Image archive in line with the BagIt standard and are actively working on bagging the Moving Image collection. While this was a relatively small project meant to test the effectiveness of establishing fixity metadata for a portion of Franklin Furnace’s digital collection, it is a significant step in ensuring that materials remain stable. As Seth Shaw argues in “What it Means to be a Repository: Real, Trustworthy, or Mature?,” it is not the sophistication of an archive’s technological solutions that makes a digital collection trustworthy, rather it is the commitment to robust archival practices. Implementing these fixity checks is an important step in ensuring that Franklin Furnace continues to protect the legacy of avant-garde and ephemeral art.

For further reading on the BagIt standard and general digital preservation practices, I recommend the following resources I consulted throughout the project:

Bodleian Libraries. “Digital Preservation at Oxford and Cambridge.” https://web.archive.org/web/20200310040655/https://www.dpoc.ac.uk/.

CUNY TV. “mediamicroservices.” Effective May 15, 2026. https://github.com/mediamicroservices/mm/.

De Stefano, Paula, Carl Fleischhauer, Andrea Goethals, et al. “Checking Your Digital Content: How, What and When to Check Fixity?” NDSA, 2014. https://www.ndsa.org/documents/NDSA-Fixity-Guidance-Report-final100214.pdf/.

Digital Preservation Coalition. “Digital Preservation Policy Toolkit. Effective March 2023. https://www.dpconline.org/digipres/implement-digipres/policy-toolkit.

Ferriter, Megan. “BagIt at the Library of Congress.” Library of Congress Blogs, April 4, 2019. https://blogs.loc.gov/thesignal/2019/04/bagit-at-the-library-of-congress/.

New York Public Library. “ami-preservation.” Effective May 15, 2026. https://github.com/NYPL/ami-preservation.

Shaw, Seth. “What it Means to be a Repository: Real, Trustworthy, or Mature?” code4lib 61 (2025): https://journal.code4lib.org/articles/18541