Interesting discussion of issues here. Liz Shaw points out an elegant way around the redundancy issue by using the parent attribute, though it bears emphasis that the ability to utilize that approach in containment encoding in whatever system one is using to provide access to EAD-encoded finding aids may be dependent on available technological expertise and system capabilities.
What hasn't been discussed here at all, and what interests me the most, is what seems to me a certain fixation on containment and its preeminence in display in finding aids. Alvin Pollack's original question to the list seemed, in my assessment of it anyway, to posit the problem in terms of achieving a columnar layout of box and folder information that might be problematic if there is too much box and folder information to fit in the defined columns (information at levels that span containers).
As I recall it, the original discussions in the EAD WG that led to the recommendation currently in the EAD Application Guidelines was predicated on the idea that end users might want search/display options that don't necessarily force them to deal with an entire finding aid at once and that, in such a situation, it would be good to present containment information at every level encoded below series/subseries (at the file and item levels). As Alvin rightly pointed out in his original 4/27 message, the following type of *display* of EAD encoding is pretty ugly and probably very confusing:
"The only thing I can come up with is the following, which seems
too ambiguous to me:
Box Folder Contents
1-2 1-3, 1-2 Correspondence
1 1-3 Personal
1 1 1960
1 2 1961
1 3 1962
2 1-2 Professional
2 1 1960
2 2 1961
2-3 3-4, 1 Speeches
2 3 Rotary Club
2 4 Kiwanis
3 1 American Legion"
My main question though, is why we are so fixated on preserving the above display? To my mind at least, it gives precedence to containment information over the actual intellectual description that I would guess would be of greater interest to end users of our descriptive information online. When is the containment information really useful to end users? Seems to me it is only really useful when they are in our repositories wanting to page something for use, in which case some mediation can occur to tell them how to fill out the paging requests.
At UCI we've embraced the reengineering mindset that Dennis Meissner eloquently championed in his American Archivist article and raised the status of our descriptive information relative to the facts about containment in our encoded archival description displays (even though we had the columnar format shown in Alvin's message in our old print finding aids). So something like his example above might display in our online finding aids like this (the position of the containment information in the display and the square brackets around it, as well as making it a slightly lighter color to deemphasize it relative to the descriptive content, are all done via a stylesheet):
Correspondence [Boxes 1:1-2:2]
Personal [Box 1:1-3]
1960 [Box 1:1]
1961 [Box 1:2]
1962 [Box 1:3]
Professional [Box 2:1-2]
1960 [Box 2:1]
1961 [Box 2:2]
Speeches [Boxes 2:3-3:1]
Rotary Club [Box 2:3]
Kiwanis [Box 2:4]
American Legion [Box 3:1]
I don't know whether this approach is the answer or not, since we haven't had the opportunity to do any kind of formal end-user testing of it. But I do feel comfortable that we are able to get containment information at every <c0x> level for files and items, which will hopefully make our data more flexible for use in future access systems that can do better than shove entire finding aids at online end users who may want more options for dealing with these information-rich access tools. I also feel much better focusing attention on our actual descriptive data by bringing it to the left-hand margin on our displays making it easier to scan.
Elizabeth Shaw wrote:
> The issue with this container problem is that fundamentally that there
> are two hierarchies in the finding aids - an intellectual one and a
> physical one. Because the crafters of the DTD decided to focus on the
> intellectual hierarchy (bravo), the container hierarchy is left in the
> lurch and so we can not really represent the inheritance as successfully
> as one might if we had a way in SGML/XML of capturing overlapping
> That said, we at the University of Pittsburgh (in the Historic
> Pittsburgh project) have successfully used the parent attribute to
> reduce encoding redundancy in capturing the relationships of folders and
> When a box first "opens" -at whatever level we declare it with
> <container type="box" id="collectionid.boxno">1</container>
> Folders within that box are expressed as
> <container type="folder" parent="collectionid.boxno">1</container>
> at the level at which they open.
> We do not redeclare the box - that is redundant and time consuming. By
> using the parent attribute we can always point back to the parent box.
> While it isn't a true heirarchical representation (if we could capture
> multiple heirarchies in SGML/XML the container of type folder would be
> nested and the relationship implied) it seems like an adequate solution
> that saves redundancy and encoding time.
> Using XSLT it is a simple matter to create a display that repeats the
> box information as often as necessary or desirable. And it can be placed
> in a variety of places if you get really fancy. It is likely that you
> could even place the information every nth folder(though I haven't
> Because SGML/XML can be so good at using inheritance and reducing
> redundant data, it seems a shame not to use the parent attribute to do
> the same - even if it is a compromise to this problem of dealing with
> dual hierarchies.
> Liz Shaw
> School of Information Sciences
> University of Pittsburgh
> Pittsburgh, PA 15206
> [log in to unmask] wrote:
> > Dear EADers
> > I thought that one of the purposes (if not the main one?) of a hierarchical
> > structure in the DTD was to avoid data redundancy. If repeating some
> > information helps the user, can't it be done with the style sheet ?
> > Or did I misunderstand the original question ?
> > Regards
> > Pierre Clavel
| 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]