I have a question about <unitloc> (we're still working in beta, but
the same question applies to <container> and <physloc> in 1.0). In
some cases in our legacy finding aids, instead of having folders
within a box, we might have loose manuscripts or books, for example,
which are identified visually within the finding aid in much the same
same way that folders are. The formatting is the same, with the
identification "folder" being replaced with "manuscript" or "book,"
and often the item is numbered just as a folder would be. Because of
the similarity in formatting, my temptation is to put this within a
<unitloc>, with containertype set to "othercontainertype" and
othercontainertype being "manuscript" or "book." But this seems a
little nonsensical because obviously a manuscript is not a location
(nor is it a container). Then again, the identification can be a cue
to locating the item (if there are ten folders and a book in a box,
for example). I think putting this information within the <unittitle>
would be cumbersome, and the clarity of the finding aid could be
compromised if the information was ommited.
I have already posed this question to Alvin Pollock at UC Berkeley,
and he pointed out that the EAD version 1.0 tag library lists as
possible type values on the <container> tag "page", "folio", "volume",
"reel", "frame", etc., and that these aren't really containers either,
and seem to be candidates for a <unitid> rather than a <container>.
His suggestion was to use <unitloc> anyway, setting the
othercontainertype attribute to "volume" rather than book, since in
EAD version 1.0 this would be translated to the EAD WG-sanctioned
For myself, I still prefer the more specific "book" or "manuscript"
to a seemingly generic term like "volume."
Any other suggestions/opinions?
Getty Research Institute for the History of Art and the Humanities