Date: Wed, 27 Dec 95 14:30:12 CST
From: "Processing Department" <[log in to unmask]>
Subject: More thoughts on EAD
Back again with more reflections on my earlier message. After a walk in
the crisp air, I have several comments, a long diagram (Sharon, you
started this) and a brief recommendation that might pull this together with
a simple solution so we can move ahead.
Upon reflection, I think the high level model is correct except for a
misidentification of the element cv which is not a view at all but a
component description. The following diagrams explain what I see actually
happening in a finding aid.
There are really only two kinds of finding aid structures (at least with
respect to the part that we call <archdesc>. The first one I will call a
fully nested unit description. We like this one because it reflects the
nested hierarchical way we physically order collections and it works
in electronic form because the SGML navigators can expand and collapse the
hierarchy at the push of a key. Maybe all finding aids (at least
their electronic versions) should be produced this way in the future. The
structure looks like this (I've revived a conceptual element that we
tossed- unit description (UD)). It looks like this.
<archdesc>
<unit description>
<did>
<bioghist>
<scopecontent>
<admininfo>
<controlaccess>
<odd>
<component description>
<did>
<bioghist>
<scopecontent>
<admininfo>
<controlaccess>
<odd>
<component description>
<did>
<bioghist>
<scopecontent>
<admininfo>
<controlaccess>
<odd>
</component description>
</component description>
<component description>
<did>
<bioghist>
<scopecontent>
<admininfo>
<controlaccess>
<odd>
</component description>
</archdesc>
Of course, as one gets further down into the CDs, the less and less of
the basic descriptive information is likely to appear. When you get down
to the folder level, we might have a title, date, and occasionally a scope
and content note.
In the second model, we break out elements and present them in a
linear manner, usually because one otherwises loses one place in the
hierarchy in a long printed finding aid. It looks something like this.
UD
UD
CD
CD
UD
CD
CD
CD
CD
CD
CD
This got complicated so we put wrappers around the segments like this and
called them views.
<UV>
UD
</UV>
<UV>
UD
CD
CD
</UV>
<UV>
UD
CD
CD
CD
CD
CD
CD
</UV>
Yes, the Unit Descriptions are often there within the different views
although they often consist only of a title and tend to be
mistaken for headings.
So, what's the point here. Two.
1. UV is mislabelled. These are really descriptions. Or have I really
missed something. If you change CV to CD, the high level model works so
long as it is clear that CDs can exist within or without views. If you
keep my third option, they always exist within views.
2. Let me offer two options and then shut up.
a. The simple/complex- more layers but only one model. But I don't think
Daniel likes this one. In some views there will be no CDs.
<archdesc>
<view type=x> [repeating]
<unit description>
<did> etc.
<component description> [repeating]
<did> etc.
</component description>
</unit description>
</view>
</archdesc>
b. Closest to where we are model. My number two suggestion in the
previous message.
<archdesc>
<did>
<bioghist>
<scopecontent>
<admininfo>
<controlaccess>
<odd>
<view type=x>
<component description>
</component description>
</view>
</archdesc>
This will be easier to do at this stage but I still think that it
looks sloppy. The first bunch of elements (did, bioghist, etc.) have a
wrapper (unit description) even if only conceptually. Some of the unit
descriptive elements (especially title) do appear within the UVs on most
finding aids, even if they only look like headings where the name of the
collection is repeated.
The best thing about this model comes from a tagging standpoint- perhaps we
have too many wrappers and this simplfies things.
Michael
Processing Department
Minnesota Historical Society
[log in to unmask] or [log in to unmask]
|