We’ve been taking a closer look at how we create and encode Physical Description information. Our deployment of the Archivists’ Toolkit does not employ the multiple <extent> plugin so we’re a little limited as to how we enter Physical Description information. We’ve been using the Toolkit “Container Summary” field for recording information about the containers (i.e., boxes, folders, etc.). The Toolkit exports this information as a simple <extent> note that appears immediately after the regular <extent> note (which provides information about the archival materials, not the containers).
We’re watching the developments with ArchivesSpace, the open-source platform that will supersede the Toolkit later this year. The ArchivesSpace team is developing a migration tool to migrate data from the Toolkit MySQL database (as well as the database that powers the Archon platform) into the ArchivesSpace MySQL database so users don’t have to import/export EAD or CSV accession records. This got me wondering about the destination of the Container Summary field in ArchivesSpace (see this ArchivesSpace user group thread for more info). We want to be able to distinguish between the two <extent> notes when we’re working with exported EAD and it appears the only way to do that will be to tweak the export routine in the Ruby source code.
At the same time, as we export our finding aids for publishing in our ICA-AtoM database, we’re noticing that Atom properly handles the multiple <extent> notes nested within the first <physdesc> element. But we’re also noticing issues with how AtoM handles multiple Physical Description elements. Specifically, it does not import repeating <physdesc> elements and it does not import the <physfacet> element (see this AtoM user group thread for more info). We’re currently looking at whether we should revise our XSLT to merge multiple <physdesc> notes into one note or tweak the AtoM import code so it accepts the code.
All of this prompted me to make a post to the Encoded Archival Description list to see how other folks are encoding Physical Description information (see thread #7 in the list archives). This generated some helpful discussion but also brought up the pending revisions to Encoded Archival Description (EAD) and its complete overhaul of the <physdesc> elements (see Mike Rush’s response for more info).
The changes will really help us handle complex physical description information that’s required for audiovisual material but it will be some time before ArchivesSpace or ICA-Atom support EAD3. This is probably a good thing as it will allow us more time to think about how the revisions to EAD will affect the display of the descriptive data. For example, with our Rules for Archival Description, the explanatory text allowed under <physdescstructured><descriptivenote> would not typically be nested within the data included in <physdescstructured>. One of RAD’s many idiosyncrasies is that it asks for descriptive notes relating to the physical description to be included in the “Notes Area,” which comes after the Physical Description Area and Archival Description Area (see Rule 1.8B9: http://www.cdncouncilarchives.ca/RAD/RAD_Chapter01_July2008.pdf). I don’t think that rule is used all that often because in practice, most people just include the note in the Physical Description Area, but it is there nonetheless. This will only become important if anyone attempts to design a stylesheet to display EAD3 data according to the structure prescribed in RAD; they would *technically* need to move the data contained in <physdescstructred><descriptivenote> and place it alongside other elements that appear outside of <did> (e.g., <originalsloc>, <otherfindaid>, etc.).
RAD clearly needs some revisions, but that is another story! The moving targets are making it a little difficult to develop procedures for creating and entering physical description information – do we use granular EAD elements or lump everything together into one <physdesc> note? Our database holds a bit of both, so we will likely need to account for various EAD scenarios when we work on our XSLT, and AtoM database.