 |
 |
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> . Angelika Menne-Haritz Bundesarchiv, Berlin ----- 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 EAD. Michael Fox -----Original Message----- From: Encoded Archival Description List [mailto:[log in to unmask]]On Behalf Of Mike Ferrando Sent: Thursday, June 02, 2005 9:27 AM To: [log in to unmask] Subject: Re: where to indicate container info? Michele R., 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 puzzles. 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 encodinganalog values). 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 each "heading". Mike Ferrando Library Technician Library of Congress Washington, DC 202-707-4454 --- MicheleR <[log in to unmask]> wrote: > OK, another question for the collective wisdom. Let's say I have > some > material that looks like this, and that it's all in Box 1 of a > 5-box > collection: > > 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 > level > (Writings), since all the child pieces are in the same box and > they'll > inherit from the parent, or is it more appropriate to put the > container > 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 > container > information based on the document tree and I'm not really > comfortable with > that... > > Michele > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail