Files and file structure
I’m going to direct you to an updated version of my lovely flowchart, which has a couple new additions and a few more callout notes to explain the intent behind certain categories. The same breakdown of item responsibilities and locations would reflect the file structure for saved items, and inherently the finding aid. The list of desired elements is framed in such a way that it also acts as a checklist for a digital finding aid. Any non-digital item that would only be located in a physical archive would still have an entry, containing the archival metadata and having a physical location notated instead of a URI. In this way, like the production itself, the digital and the analog continue to work side by side.
Files will have a common naming convention, determined as required by the metadata used by the holding archive. If the holding archive does not specify, Dublin Core standards will apply.
Structuring the files in the same way as the finding aid will help with accessibility, but proper metadata will also be important, as some files or aspect types are key in how they overlap: what design choices are requirements of the original creator of the work versus a choice by the designer; cue lights are set up and maintained by the master electrician, but controlled during a performance by the stage manager, and recorded only in their cuing script. The ability to sort and filter objects not only by file type or contributor, but design area or intent aspect (practical, timing, emotional, etc) are the kinds of details that not only will be useful to those recreating a performance, but to those studying the working intent of the designers and directors producing it.
Accessibility of files
The original files will be saved and treated as the preservation copy, while additional lower level access versions of the files will also be created. These will serve not only as the web-available access copies, in some cases, but also to ensure that some readable version will be available if the specialized software the theatre created its originals on is no longer accessible. To that end, CAD files will be exported (at full scale) to PDF/A-2, cue stacks will be converted to database or spreadsheet form, and any specialized visual effects that cannot be exported to other forms will be accompanied by a written artist’s statement describing not only the effect (and how it was created, where possible), but also the intent behind it. Designer’s statements should be included wherever possible, but they are most important for works that cannot be guaranteed to be sustainable. When created, these access files will automatically inherit the metadata of the parent file, in terms of performance information. Access rights and file information metadata will of course differ.
Metadata & archive selection
In terms of what archive this would go in, that kind of depends on a number of factors. Ideally it’d go into something like GloPAD or ECLAP, but it could also go into a local database like WAPAVA, in Big’s case, or the theatre company’s own archive, though the chances of them being able to fully exploit the metadata available is in that case less likely. However, by basing the metadata and extraction on open source tools and shared standards, collecting and displaying as much metadata as possible should be a simple matter.
Fortunately both GloPAD and ECLAP come with suggested metadata models, which employ standards from a variety of regular schema, most notably Dublin Core and VRA Core, but several other models as well. ECLAP also makes use of Linked Open Data (LOD), and generally seems to be more advanced, and actively developed, no doubt in great part due to its status as part of Europeana. However, both models should be scalable (or adjustable in terms of the OAI-PMH) to ensure that even while the holdings records of the online archives may be shared to larger Europeana-type collections, the items themselves may not, dependent on the reproduction rights, which are carefully documented in the metadata schemae. Ideally, in addition to reproduction and transmission rights, general dissemination permissions, of various levels, would be attached to the files, so that different DIPs could be created for the general public, scholars, and the individuals involved in the creation of the work.
In terms of collecting the metadata from the various digital files, a combination of traditional archival metadata extractors would be used. I had hoped to find some theatre-specific tools, but the biggest one I found, Rekall (mentioned in my last post), while at first promising, failed to recognize common lighting-specific file types, including CAD program files, instead lumping anything it didn’t recognize into an ‘octet stream’ category. Additionally I could see no obvious way to export the information out of the program, and documentation or support for the application doesn’t seem to be apparent — it looks like another case of a promising application that dried out with its funding. At least it’s open source, though, so if someone wanted to take it up they’d have a good foundation to build on.
Additional materials
In addition to but archived separately from the show files are general documentation on the metadata schema, the various softwares used in the creation of the performance, and in the creation or acquisition of the metadata. These should all be incorporated somewhere into the larger archive, either in an ‘about’ section or a technical metadata section. The general file structure for each show, once completely uploaded, should be saved as a PDF/A-2 to act as a finding aid, in addition to the general searchability of a digital archive.
Other useful items to archive would be the various union contracts, also mentioned in my last post. If it were a large-scale archive, covering more than one specific theatre, having a section covering the various contracts longitudinally and departmentally would be an invaluable resource. Of course, in a similar fashion to the detailed information in the stage manager’s and directors’ portions of the archived works, privacy concerns would probably mean that a generalized standard contract, rather than one with any specific concessions for a specific theatre, would be most appropriate to archive.
Hopefully, though, some aspects of the archive would continue to grow over time. Allowing for a user-contribution section, as CircusOZ’s Living Archive does, will allow for additional reviews outside the scope of the professional theatre world, and commentary on all aspects of the endeavor to be added at any time even after the initial upload, to ensure that as new connections are made, by people working on the project or simply viewing it, they are not lost. The show may have been struck, but how the show strikes you will never go away.