You are right, Michael, concerning the German archival practice. A <c> with
the level attribut value "class" here is something like a chapter in a book
and we use <unittitle> for the header of this classification group. In
German finding aids the actual records are the deciptive units on the lowest
c-level where we use the attribute value "file", which in general correspond
to the physical units in the stacks identified by a call number in <unitid>
----- Original Message -----
From: "Fox, Michael" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, June 03, 2005 5:20 PM
Subject: Re: where to indicate container info?
There are some interesting ideas here but I would prefer not to use the term
"headings" as that evokes the concept of display text associated with the
element <head> in EAD.
Rather what we have is a reflection of arrangement. In our organizational
of archival materials, some of the units of arrangement relate to actual
archival "stuff" and may be described specifically. Other units of
arrangement are simply there to provide organizing "buckets" for ordering
materials into useful groupings. I am reminded, in a vaguely related sort
of way, of the guide cards in card catalogs that helped to organize and
subdivide the contents of a drawer into manageable groupings. Of course,
these were not necessarily hierarchical in the way we do archival
arrangement but they achieve some of the same goals.
If I understand the theory correctly, German archival practice consciously
identifies such units of arrangement as classification (though not in the
sense of library subject classification), thereby distinguishing them from
descriptions of actual records. Hence the level attribute value "class" in
From: Encoded Archival Description List [mailto:[log in to unmask]]On Behalf Of
Sent: Thursday, June 02, 2005 9:27 AM
To: [log in to unmask]
Subject: Re: where to indicate container info?
My perspective on the relationship between finding aid container list
and the DSC elements is that you only have two types of entries. You
either have a "heading" (used loosely) or you have an "item" (used
loosely). Headings rarely have any descriptive elements. Items do
have descriptive elements.
If the headings are series or subseries, then you will have the
summation of container info, a scopecontent and other information
elements. (These are not necessarily required or always needed. For
example, you need not have subseries scopecontent if you have covered
it in the series scopecontent.) Whatever the elements chosen for the
series or subseries, they will be summations.
Items have elements specifically related to their description. This
could include scopecontent and other such elements, but even these
are tailored to the specific item itself.
Limitations do present situations where you may fudge the finding aid
to get a better coded EAD document. There are often times when it is
unclear if a "heading" is actually a subseries or not. In such cases,
you must make a decision concerning these types of finding aid
In my coding experience, "subseries" represents an intellectual
judgement about the material. The heirarchy of information in the
finding aid does not always obligate an intellectual judgment, but
rather only an organizational judgement. When you have an
organizational judgement you merely continue to give the "heading"
component [c02] and nested component [c03] the @level='file'.
Often there will be only "headings" and no item level description at
all. I find this very common with clippings and miscellaneous.
I must admit that there are times when I just have to go and look at
the collection box or folder to understand the finding aid for proper
coding. (The shorthand is just too short.)
In the case you present, I know nothing of the actual items. If you
are presented with material that clearly has one genre of material
"writings", then you most likely should try to find a term to
describe the other group as well (i.e, "printed matter",
"miscellaneous", "notes", "other", etc.). Often you can find many
items of this other "group" is actually a subseries in the first
group. This would mean that you really don't have "writings" and
"other" you have groups of "writings". The subseries you thought you
had under writings become series in the new arrangement and you have
solved your problem.
My experience is that the "headings" are best served by using the
components hierarchically to give context to the items (providing the
landscape of processed collection). The "items" are best served by
the component itself and the descriptive elements that will best
represent the datatypes given (dates, notes, physical description,
etc.). I admit that I do tend to see the hierarchy as wrapping, and
the item as a possibility of item level description (aka MARC21
In conclusion, you really don't offer much information about this
collection. I would say that the container MUST appear for each item
(my stylesheet does respect the @parent attribute in the container
elements). However, if this has not been done in the legacy finding
aid, then go with what is there. The real issue is how are people
going to find the item (if that is the intention of the container
information)? Otherwise, you merely have summations of containers for
Library of Congress
--- MicheleR <[log in to unmask]> wrote:
> OK, another question for the collective wisdom. Let's say I have
> material that looks like this, and that it's all in Box 1 of a
> c01 - Writings
> c02 - History of Spain
> c02 - History of England
> c02 - History of Holland
> c01 - something else...
> Is it more appropriate to put the container information at the c01
> (Writings), since all the child pieces are in the same box and
> inherit from the parent, or is it more appropriate to put the
> information at the lowest level, i.e. repeat it in each c02, so
> that each
> piece has its own container information? Has anyone run into
> problems doing
> it one way or the other?
> The EAD application guidelines say something nutty about just
> sticking in a
> container element wherever the material switches to a new container
> and not
> worrying about what c0# you're in but that seems, well, a bit
> strange to me.
> Doing that is likely to leave some elements with no accurate
> information based on the document tree and I'm not really
> comfortable with
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.