I responded this morning to MacKenzie Smith's e-mail message of last week,
but somehow it went only to her and not to the list. She very kindly
pointed this out, so here it is again, properly addressed this time.
Kris
>On Mon, 13 Apr 1998, Kris Kiesling wrote:
>
>> In an effort to dispell the "Michael vs. Harvard" scenario, I'd like to
>> address MacKenzie's comments. Let me state at the outset that I agree with
>> everything Michael has said in his messages on this subject. But there
>> obviously is an issue here, and we need to understand it and resolve it.
>>
>> If physical location information was not traditionally recorded in many of
>> Harvard's finding aids, and if Harvard does not plan to add that
>> information to these finding aids during conversion (and they're certainly
>> not required to do so), then there isn't a problem with at least some of
>> the 14,000 finding aids.
>>
>> When the physical location information is present elsewhere in the finding
>> aids, as MacKenzie notes is sometimes the case, it can be coded as a list
>> or a table within <archdesc>, <dsc>, or any of the "<did>-level" elements
>> (<admininfo>, <bioghist>, <scopecontent>, etc.), or as <odd>. There is no
>> requirement in EAD that the physical location information be brought
>> together with the series or folder descriptions during conversion.
>>
>> EAD privileges intellectual order over physical order. This was necessary
>> because finding aids typically contain these dual (sometimes duel) logics,
>> and SGML, as flexible and accommodating as it is, can't overlay one on the
>> other. So, in a sense, the physical location *is* secondary to the
>> intellectual order, as MacKenzie points out. However, when the physical
>> location is made available in the finding aid in a two- or three-column
>> format (Box, Folder, Contents), it needs to be linked to the other
>> information about the box or folder, such as the <unittitle>, <unitdate>,
>> etc., to facilitate retrieval of this information as a unit. That's why it
>> is part of the <did>. Let me emphasize again that none of the <did>
>> elements, including <container>, is required by the DTD. Let me also
>> stress that implementation of EAD is an ideal opportunity for repositories
>> to think very hard about the information that is presented in their finding
>> aids and how it is presented, particularly in an online environment.
>>
>> All of the elements available within <archdesc> are also available at the
>> component level, creating an unfolding hierarchy that accommodates
>> multi-level description as well as description at one level. Making <odd>
>> available directly within <c>s (rather than following the <did>, as
>> MacKenzie illustrates in her example) would violate the hierarchical
>> structure of EAD, and, as I understand it, would have the effect of making
>> it a "floating" element.
>>
>> The key to the use of <odd> is the last part of the phrase MacKenzie
>> quoted: "...whose information components may not be divided into the
>> distinct categories that have been named as elements in EAD...." EAD has
>> a named element for physical location information at the component level,
>> and that element is <container>. I'm having a lot of difficulty
>> understanding Harvard's preference of coding physical location information
>> as <odd>, except, of course, that one must open an additional element,
>> <did>, to get to <container>. Perhaps if we could see a real example of
>> the perceived problem, rather than a hypothetical one, the problem would be
>> clearer and others could comment.
>>
>> Kris
>>
>>
>>
>>
>> >I want to add a few comments to the discussion between Michael Fox and
>> >various members of Harvard's Digital Finding Aids Project group on the
>> >treatment of physical location of materials in EAD. I'd like to present
>> >our point slightly differently, in case it wasn't evident from the earlier
>> >postings why this issue of physical location is such a problem for us.
>> >
>> >1. We have a rather large body of old printed finding aids which require
>> >EAD encoding retrospectively (on the order of 14,000).
>> >
>> >2. We did not traditionally record the physical location of materials
>> >in many of these finding aids. Or else the information is there somewhere,
>> >but not as part of the series or folder description as is commonly
>> >done now.
>> >
>> >3. The addition of any information to old finding aids that isn't there
>> >now does, in fact, require work, despite our having a nice editing
>> >environment so that we don't have to key in pointy angle brackets, etc.
>> >Adding a <container> element with varying content to every item in up to
>> >14,000 finding aids is a LOT of work, since it couldn't really be done
>> >automatically using macros. Changing our current practice is certainly
>> >an option, and has been done in many cases, but additional keying simply
>> >isn't an option for retrospective conversion on this scale.
>> >
>> >4. Since we have not consistently recorded the physical location of
>> >materials in the archives, we would probably not design our retrieval
>> >system around the assumption that this is useful information for our
>> >users... In fact, since one major goal of this work is to eventually
>> >digitize these collections for online retrieval, it seems to me that we
>> >very often _wouldn't_ want to tell folks where to find the stuff in the
>> >archives... it's just a click away, right?
>> >
>> >5. For retrospective conversion the only thing that makes sense to me is
>> >to markup physical location information in our findings aids in the way it
>> >was originally intended... as secondary, extraneous, notational
>> >information (i.e. a note) when it occurs in a series description. And the
>> >easiest way to do that given the current DTD is with an <odd> element:
>> >
>> > "The <odd> element is primarily used to accomodate existing
>> >finding aids that have been converted into EAD but whose information
>> >components may not be divided into the distinct categories that have been
>> >named as elements in EAD..."
>> >
>> >6. But the <odd> isn't currently defined to be available in a reasonable
>> >way in the <c>, hence our request for a change. We don't want a "floating"
>> >element at all, we just want the <odd> available in a <c> either before or
>> >after any nested <c>s, instead of just before nested <c>s as it is
>>currently
>> >defined.
>> >
>> >We want to do this:
>> >
>> ><c> series info
>> >...
>> ><c> folder info
>> ><odd>box n</odd>
>> >...
>> ></c>
>> ></c>
>> >
>> >and if the DTD isn't changed, our only alternative is this:
>> >
>> ><c> series info
>> >...
>> ><c> folder info
>> ><c><did></did><odd>box info</odd></c>
>> >...
>> ></c>
>> >
>> >Not the end of the world, sure, but yuck! I don't think this an
>> >unreasonable, or even major request, given that we all want to
>> >integrate our old and new finding aids with a minimum of fuss and
>-> >expense.
>> >
>> >
>>
>>>_____________________________________________________________________________ >
>>> >MacKenzie Smith
>>[log in to unmask]
>> >Digital Library Projects Manager phone: (617)495-3724
>> >Office for Information Systems fax: (617)495-0491
>> >Harvard University Library
>>%\%\%\%\%\%\%\%\%\%\%\%\%\%
>>
>>>----------------------------------------------------------------------------- >
>>>
>> Kris Kiesling
>> Chair, SAA Committee on Archival Information Exchange
>> Chair, CAIE EAD Working Group
>> Head, Department of Manuscripts and Archives
>> Harry Ransom Humanities Research Center
>> University of Texas at Austin
>> Austin, TX 78713-7219
>> voice: 512-471-9113
>> fax: 512.471.9646
>> [log in to unmask]
>>
>>
>>
>
|