Date: Wed, 27 Dec 95 14:23:12 CST
From: "Processing Department" <[log in to unmask]>
To: [log in to unmask], [log in to unmask]
Subject: EAD


Hello all,
Hope everybody survived the holidays.

The following is in reply to Debbie's note of 12/21 with references to
Kris' comments on Daniel's high level model and Helena's replies to Debbie.

1.   EADS TOGETHER.  I can imagine combining several series level finding
aids together ex post facto to form a single finding aid for a record
group or a group of manuscript collections for individuals, say a family
grouping.  I'm not sure how this would work out until I can see the model
you have developed.  The problem of concatenation is that one usually
needs some higher level data at the front to draw the pieces together
(record group/fond info for example).  Do you provide for same?  One could
of course create a finding aid for an entire record group from the very
beginning but that would not cover instances where one would pull stuff
together later.  The problem that I see is that a consolidated finding aid
of this sort would be at a higher level of aggregation.  For example, if
one pulled together a number of series descriptions into a single record
group entry, the new finding aid would have data elements in the DID
reflecting info re the record group.  In effect, every level in the
hierarchical layering of a finding aid would "slip down" one level.  I
can't envison how that would work here.  Not that it couldn't.

2.  TITLE PAGE  I'm with Helena.  It looks like a typographical concession
where minimal content encoding is warranted.  Just enough to get the
layout to look right.  One would pull substantive info for
displays/navigators out of the DID or header since the content and even
very existence of a title page would be so idiosyncratic.

3.  SCOPE CONTENT  A BIG flag here for me.  I understand Debbie's concern
about having only a single element in an otherwise empty UV which would
occur if one has a UV that is a scope and content note at the unit level
and the other unit identifying data is sitting elsewhere (the did, etc.)

Back to another topic for a moment.  The CV or UV option in the high
level model seems wrong.  My notes suggest that CVs exist only within
UVs.  In the new model, we said that a unit level scope and contents
note, a series listing, and a container listing were all views of the
contents of the particular unit being described.  They exist at the same
level.  In the latter two views, there will be additional information
about subordinate components of the unit described.  These are CVs and they
can posses all the same data elements as the unit (title, dates, extent,
origination, scope and content).  In these later UV types, there is apt to
be little if any information (outside a header) that is not within one of
the subordinate CVs.

Back to Debbie's comment which points up the chief problem with the DC
model.  Within the UVs of the types series listing and container list, the
identifying data elements (title, dates, extent, etc.) are present.  But
not in the UV of the type Scope and Content Note describing the entire unit
described in the EAD.  (Boy is that a qualifier.)  So it looks funny and
rightly so.

Aside-  What has happened here, to my mind, this is a wonderful example of
the situation where one fixes one thing and breaks another.  I personally
was never convinced that there was a problem with the older model that
needed changing but we did and now we have to fix this problem.  (There may
have been some SGML-type difficulties but it made more archival sense to
me.)

Anyway I see three options.

1.  Debbie's solution- create a SCOPE CONTENT VIEW.  As I see it, all this
does is create another element which is a specific instance of a view, one
that contains only a scope and content note, so as to differentiate it from
other views that have more stuff in them.   I don't see that this buys us
much. Linguistically, it is confusing since other views may also contain
scope and contents notes.

2.  Move the scope and content note for the unit out of the UVs entirely.
Treat it within archdesc as an element at the same level as did, bioghist
and admininfo.  Most archivists would feel comfortable with the
point of view that scopecontent is fundamental data of the same
significance as did, bioghist, et al.(certianly more integral
than controlaccess).  The UVs then become those components that contain
information at any more detailed level than that of the unit as a whole.

3.  As above, except put a UV wrapper around those elements that
describe the unit as a whole (the unit's did, scopecontent, bioghist,
etc.)  This is really where we were in Ann Arbor.  It recognizes that
these unit-level elements exist in parallel with the same elements as
they appear within the other UVs and CVs.  There is a symmetry that exists
within these hierarchical structures, even if all the elements are not in
place, sometimes because they are not know, are not significant or are
implied.  I personally prefer this approach but could live with no. 2.

CONTROLLED ACCESS ATTRIBUTE
  How about the following from the USMARC Code List for Relators,
Sources, Descriptive Conventions, Part IV, Subject/Index Term Sources:
aat, lctgm, gmgpc, lcsh, local, mim, nmc, rbgenr, dot, mesh, lcnaf,
lcsaf, aacr2, other.

STATUS ATTRIBUTE
   I like Helena's choices.  Perhaps add "core," probably to replace or
supplement "minimal."

Enough damage for now.

Michael
Processing Department
Minnesota Historical Society
[log in to unmask] or [log in to unmask]