Capturing the Ephemeral

Part 2 of the Technical Guidelines Series focuses on documentation. It’s a topic that is touched on in the previous Archivability section, but it’s one that really requires a bit more unpacking, so it has its own page in our recommendations package.

As usual, I won’t reprint the document in this blog post—you can view it here—but rather talk a bit about its purpose and motivation.

We’ve established in a few places now how challenging it is to balance a digital project’s longevity with its heft and innovation. New forms are naturally resistant to existing modes of preservation. To a great extent, digital content is ephemeral. And to the extent that we cannot guarantee a project’s lifespan, we must take care to ensure that it remains part of the scholarly record. There are several ways to approach this: we can save it component files and store them in a repository; we can crawl it and produce a web archive made of WARC files; we can emulate and host the project’s original technological environment; but perhaps the most obvious way—one that has been used for similarly ephemeral art forms for millennia—is documenting it.

In an open-access manuscript draft of his forthcoming book The Theory and Craft of Digital Preservation, Trevor Owens emphasizes that “documentation has been a primary mode of preservation in the performing arts (theater, dance, music, etc.)” and goes on to explain the correlation between these long-established art forms and new digital modes of cultural transmission:

“Performing arts documentation starts from the same kind of recognition that folklorists start from. A performance is a unique temporal lived event. It does not persist through time and while you can take something like a music score or the script of a play and make perfect copies of its information that is still not the lived experience of being there at the event. Thus, similarly to folklore and oral history, the field of performing arts preservation has adopted and adapted new media as they have emerged as a means for recording and providing access to the performances of works” (19).

But what happens when it’s the new media, itself a kind of performance, that you’re trying to preserve? We hope we can do a combination of storing, web archiving, emulating, and documenting for our interactive digital publications. But the costs and challenges of emulation and the still unreliable and incomplete state of web archive crawling mean that we need to invest more energy at early stages in storage and documentation. The storage approach is somewhat straightforward. We take each file comprising the project and deposit it, with metadata, into Stanford Digital Repository. The documentation process is a bit more ambiguous. What should be documented? What should the documentation look like? What format should the documentation take? And perhaps most importantly, who should determine all these variables?

I’ll return to Owens to set up the answer:

“The case of performing arts documentation further clarifies some of the key tensions at the heart of preservation. While we can preserve things, tangible objects, we often care deeply about experiences. The only way to preserve those experiences is to somehow register aspects of them on a medium. Similarly, the documentation approach in the performing arts defaults to an informational frame of reference as well. The mediums are chose[n] by the documenters and are thus lacking in much of the more rich kinds of artefactual information that might be associated with objects where the original artifact was itself part of its creator’s choices” (20).

As publishers, we are fortunate to be positioned in just the right moment in the preservation process so that we can allow the authors themselves to determine how they want the ephemerality of their work remembered through documentation. Providing them with the guidance to make the kinds of decisions that will affect the afterlife, if necessary, of their projects means that the documentation will not be outsourced to future researchers who may only encounter the work through a directory of disambiguated repository files or through the window of an embedded browser emulator.

By requiring authors to put together their own documentation, we help ensure a reader a hundred years from now will understand how the project originally looked, was organized, and functioned according to the author’s vision of their own work. This could take many forms, as listed in the guidelines, and may include screencasts, blueprints of the project’s organization, spreadsheets of component files and their descriptions, filmed reader traversals in the vein of Dene Grigar’s Pathfinders, etc. As a literature scholar, I should really emphasize the value of this further documentation from a reader’s perspective, but hopefully reviewers will help us out with that as we release our next projects! 😉