Kairos 17.3

Production Among the Infinite

As we negotiate the infinite levels of address possible for each postcard in our archive, we can attempt to preserve current and future readings of the card so that those readings will not be lost in history. In doing so, our job as archivists becomes one not only of cataloging, preserving, and making accessible artifacts, but also of cataloging, preserving, and making accessible interpretations of those artifacts, the multiplicity of meanings gleaned from and attributable to our archive. The archive then becomes less terministic and more inclusive. The best way to accomplish this is to allow visitors to contribute their own interpretations; however, it is easy to see how quickly sorting through all these interpretations could become overwhelming.

Fortunately, the Omeka platform offers a number of methods for users to easily and efficiently add their own readings and interpretations to the archive without giving those users free reign. Most of these methods exist in the form of plug-ins that can be installed and regulated by archive administrators.

The Contribute plug-in for Omeka allows registered users to contribute digital representations of their own artifacts and the accompanying metadata to the archive. While our boldest aspirations have us eventually enacting a Contribute-like function (see the University/Community border in this stage), for now, it remains impractical.

A second means of user contribution would be to enable users to add comments (and even ratings) to artifacts. This option offers a familiar convention and interface for Web users. The comments themselves would be another searchable metadata field for researchers.

A third option, a plug-in called Scripto, puts users in charge of transcribing artifacts, enlisting them to read the words printed or handwritten on a given postcard and transcribe them. The transcription functions in many ways like a wiki, complete with meta-commentaries and revision histories, preserving the decisions and thought processes of the transcribers in their own words.

The final available plug-in that allows users to input their own readings is called ImageAnnotation. With ImageAnnotation, archive administrators solicit users to tag images (of postcards in our case) with terms, keywords, and phrases that they see as relevant to the artifact being examined. ImageAnnotation is modeled after the image-tagging function in the photo-sharing site Flickr and behaves in a similar way. When the user tags an image, a rectangle appears around the clicked area. The user can move and resize the rectangle to circumscribe a precise region of the image. The user then types in the tag and applies it, making the term part of the metadata for that artifact.

Plug-ins like these can help contribute to the robustness of the archive. Yancey reflects on robustness in the video here, remarking on how robust archives are "alive" inasmuch as they allow for growth and change in ways addressed by these and other Omeka plug-ins.

The Problem with the Infinite

Of course, if the number of meanings derived from and added to the metadata in our archive were actually infinite, then the value of having the metadata would be lost. Our archive would become a kind of Borgesian labyrinth, its capacity for the entirety of meaning rendering itself meaningless. For now, we don't anticipate this becoming a problem for our archive. We do, however, want to make sure that the means by which users contribute to the archive are administered in such a way that those contributions are helpful (and not, say, the results of spambots running amok). To configure this administration to be as autonomous as possible is an additional challenge.

Fortunately, the community of Omeka users and developers is constantly growing both in terms of its size and in terms of its body of knowledge and understanding about how people are using the platform. With this understanding comes a sense of what needs are left to be met, what gaps to be filled. Thus, in the way visitors to our archive can help contribute to its robustness, so can (and should) we help contribute to the robustness of the broader Omeka community.

Neal ・ Bridgman ・ McElroy