"Meissner, Dennis" wrote:

> I'll say that I remain convinced that the best descriptive solution for dealing with multiple, separately organized and housed, accessions is to fold them together into the logical
> group/subgroup/series structure of the component-level description.  I think it just makes a much more understandable presentation for the end user, who is able to then grasp the intellectual structure that defines the collection.  If it is necessary or advisable for the repository to maintain
> administrative control of the materials on an accession basis, the component descriptions can each bear their accession identifier, and other administrative information (like accession-specific access provisions) can be presented in a <scopecontent> at that level.

Just wanted to support 100% what Dennis said above. I guess I'd also argue that if the repository needs for some reason to maintain administrative control of the materials on an accession-by-accession basis, a collection file or an inventory of each accession that gets filed away somewhere separate from the finding aid seems like a dandy approach to doing so. The processed collection/fonds represented in the encoded finding aid has an intellectual structure that should be completely independant of whether it came to the repository in a single accession or 100 accessions! When we process new accessions or accruals into a previously processed collection at UCI, we insert the new materials where they belong intellectually in the finding aid, box them in new boxes at the end of the rest of the collection, and just record the fact that they're stored in different boxes from the previously processed stuff using <container> tags within the file-level <did>s. The whole notion of organizing a collection based on something as potentially serendipitous as accessions seems problematic to me, especially from the perspective of an end user trying to make sense out of a finding aid, as Dennis pointed out in his message.

> Better yet, with the release of EAD 2002, those <admininfo> elements should each be available at
> all the component levels, as well.

Actually, they're currently available at all component levels now, just bundled inside of <admininfo>. With EAD 2002 you'll be able to use them without the <admininfo> bundle.


| Bill Landis
| Manuscripts Librarian, Special Collections and Archives
| The UCI Libraries, University of California
| P.O. Box 19557, Irvine, CA 92623-9557
| 949 824.3113 Voice | 949 824.2472 Fax
| [log in to unmask]