This message is posted by Helena Zinkham to EAD listserv -- realizing that
parts may be cryptic if you weren't at the various 0meetings, but wanting
easy way to check in with all the early implementors.  It's also long.

(1) WHERE'S THE EAD DTD??  Well, Beth Davis-Brown called Debbie LaPeyre
again on Friday.  Debbie's plan is to FTP the DTD to Daniel next week, in
time for the group meeting next Thursday in Los Angeles about application
guidelines.  (That's Michael F., Anne G-S., Steve H., Kris K., Daniel P.,
Tom LaP., Janice R -- using the CLR grant.)

Janice and I asked: could Debbie send the DTD to Beth, too; whatever is
ready on Tuesday, send it in.  Beth's office will PRINT AND XEROX COPIES
(Trying to save Daniel some xeroxing time, and also have something ready
for those who get there Wed. to start reading the DTD before the meeting
begins ...  tho Anne and Tom won't be at the guest house.)  If the DTD
comes on Tuesday, we'll send out an eMail.

How and when does DTD get to rest of early implementors?  (That's for
others to sort out.)

(2) With caveat: AGREE with Steve and Michael and Janice and others that
moving the DTD forward is more important than protracted theoretical
debate; YES, there will be changes and wonderful improvements in future
years as more people use the DTD--nothing we do is 'in stone'-- no need
for perfection now -- just like with MARC, evolution is a good technique.

The elements also need to be readily comprehensible to catch on with

So, please hear this out.  It takes me meanderingly too long to write it,
but the bottom line may be a few quick updates to the DTD.  If Michael,
Janice, and Kris (earlier eMails?) are wondering about the UV element,
it'll crop up during the application guidelines anyway.  Hoping here to
prevent long re-debate with this eMail.

Since I couldn't follow the thread of the UD, UV, CD, CV alternatives from
Michael's and Janice's eMails, Janice and I got out some color markers at
a white board with Beth.  In just 45 minutes, what surfaced supports what
Michael and Janice wrote about ...  they have a line on some SHORT CHANGES
that could make the alpha version easier to use.

What follows is my blend of what I read in eMail messages and the color
marker session discussion; I'll trust those who feel mis-quoted to chime

(2a)  Define "ARCHDESC" to mean "UD"

as in: 'the whole UNIT being described.' (Janice's eMail proposed adding a
'UD' element under ARCHDESC, but at the board, we realized "ARCHDESC" is
serving this overall 'wrapper' function, and, indicating 'whole unit.')
(Symmetrical as it would be to rename "ARCHDESC" as "UD" ..., I'm still not
a UD fan; sounds too much like 'unit of description.')

Since we had "UD" elements in earlier models, it gets hard to keep track
of what's being suggested here.  In Ann Arbor, there was an "ARCHDESC"
with one "UD" below it, and inside the "UD" there were layers of "CDs."
BUT, that "UD" was the counterpart to "ADD"-- it meant 'whole unit' ...
In D.C., that "ARCHDESC"  became "FINDAID" -- the wrapper for "ARCHDESC"
and "ADD."  So, we're 'just' suggesting the return of the idea of "UD" as
part of definition for the new "ARCHDESC."

     old:  archdesc             new:  findaid
             ud                         archdesc
               cd                         cd
             add                        add

In Daniel's next (October) model, "UD" appeared as a repeatable
descriptive view, with attributes that would explain its type as
'overview' 'analytic overview' and 'in-depth.' This approach reminds us
that the 'whole unit' actually gets described several times in a finding
aid: first an introductory overview (from Intro, Biog-Hist, Scope Content
thru Admin Info); second an optional analytic overview of series;  third,
an in-depth view in the container list (which is sometimes a combined
series summary/container list).

     BUT, in November at LC, in looking at the SAA manual on Inventories
and Fred Miller's book, and, in discussion -- this approach to identifying
'sections' of a finding aid broke down.  Although my rough approach to
finding aids accepts this 'three chapter' scenario, it also seemed to
diminish the importance (or high-levelness) of sections like
'ScopeContent' -- which are also overviews of the whole UNIT.  Parts of
the "introductory overview"  could also be called "UDs."  The manuals also
put 'ScopeContent' on a par with 'Descrip of Series' and 'Container List'
-- the manuals see 6-7 parts of a finding aid.  So, the October approach
to UV's accomplished one thing, but made another thing harder to

This realization lead us to talk about "VIEWS" -- and to decide that since
we're trying to build a model for future finding aids, too -- we don't
want a "UD or UV" element that 'only' demarcates existing "sections" of
paper finding aids.  We turned "UD" into "UV (Unit View)"  -- and
gradually defined it to mean CONTENT VIEW -- see 2c below.

(At this point, I stopped to eat an almond cookie; pretty good, too.)

It's real hard to follow these conversations without a finding aid or
diagram in front of us, but could Sharon weigh in on this idea?  There's a
note in the minutes that says you want to be able to accomodate the
diagram 'Pattern A' of your handout.  Does defining ARCHDESC to include
the "ann arbor UD" hinder your Pattern A?   (Maybe it's already defined
that way in the new DTD; well, we'll see soon.)

(2b)  Rename "CV" (Component View)  to be "CD"  (Component Description)

Michael proposed this; it gets us out of the 'view' confusion, and also
strikes Janice as a better expression for what goes inside that element.
Trying for the symmetry of "UV" -- "CV" seems to have bought us trouble.

(2c)  Tinker with the "UV"  (Unit View)

(2.c.i) Let "UV" stand for those who understand it, but add elements for
"Description of Series" and "Container List."

(to go with "Scope Content View" element that Debbie and Daniel added).

     Advantage: easier to convert existing paper finding aids, because
portions of the printed finding aids become easier to recognize. and tag.
Don't have to 'map' the Container List into "UV with attrib.  Container
List."  Both Michael and Janice have proposed this approach.
      Disadvantage: Lose some of the neutrality of language we were aiming
for to encourage appearance of applicability to collections that might not
use "Desc. of Series"  (Being one of those collections, I'm now happy to
trade "UV" with an attribute for "Contents List", for an element called
"Container List" but the TEXT IN THE FINDING AID says "CONTENTS LIST".
Seems way too hard to explain that you have to open "UV" and set an
attribute for "Container List."
     Disadvantage:  An element for "Desc of Series"  might encourage new
finding aids to use separate Desc. of Series, but the DTD tagging should
make a combined 'container list-series descrip' serve both roles (display
a summary of series-only info; show me the individual series description
right with the info about the 'container list.') Let the application
guidelines show the element is for retrospective tagging?

In D.C., we proposed that "UV"  be: "Part of archival description that
presents a view of the CONTENT of the whole unit."  The goal of "views"
was to help show the relationship between the finding aid description and
the collection: One view is "Administrative Information" -- this 'view',
though, is expressed as a named element with subelements, not as a "UV."
For "Context" info., we used the "ADD" element (Adjunct Descriptive Data).
For "Content Views" -- we used "UV."

The first of the 'Content Views' is called "Scope Content" in traditional,
paper finding aids.  Since Scope Content is an element that might also be
needed at the series, subseries, or item level of finding aid, it was left
as the sole element within 'UV."  The other three kinds of content views
"Desc. of Series,"  "Container List," and combined Desc of
Series-Container List were going to be attributes set on "UV"  (which
could be used multiple times.

To some extent, Debbie and Daniel balanced things out by making "SCope
Content View"  (one of the content views) it's own element; just like
AdminInfo and Context views are elements.  But, that left UV to cover
just Descrip of Series and Container List ... so, just make those two
elements, too?

Anne should speak to this "views" role; she was articulate in D.C.; ideas
related to FUTURE FINDING AIDS, where people should be able to navigate
or hone in on the information that most helps them -- that can mean
knowing the "function" of the information; is it 'about' the collection,
or, is it administrative advice, like rights restrictions.

BUT, the word "VIEW" is confusing.  Steve deR mentioned that 'view' has a
special meaning with databases: 'a selection of a database presented in a
certain way.'   Daniel used views nicely in one model description to mean:
overview and analytical view.  Now, we're sort of using 'view' to mean:
kind of information provided -- content, administrative, context.  But
there's not a 'view' element to go with each of the views.   There's only
one element named for a 'view':  UV -- part of ARCHDESC that presents a
view of the content of the whole unit.

(2.c.ii)  If have trouble writing application guidelines for "UV",
and establish elements for Desc. of Series and Container
List,  then drop "UV."

(2.c.iii)  Don't add 2 elements for "Desc. of Series" and "Container
List" -- and Janice and I will pretend that there's a "UV-DS" and a "UV-CL"
and see how things go in the alpha version.

(2.c.iv) Add an element called "VIEW" to contain all of the elements like
admininfo, bioghist, scopecontent.  Janice showed this on the board in a
model most attractive for its simplicity:


And, as mentioned in DC meetings, set attributes on individual elements
to say "Content view"  "Context view"  "Admininfo"   etc.   (NOPE, we
can't imagine tagging at that level of detail.)

(3)   On to shorter, ground.

(3.a)  for the EADGROUP question,  maybe it's also a helpful umbrella in
that it helps bundle separately compiled finding aids, without having to
slip (re-code) the "UD-CD" relationships down a level.  Each separate
finding aid stays  as a "Unit"   (This was for Michael's last query.)

(3.b.)  those TITLEPAGES, last April's UCB model showed some nice opening
screens for the finding aids it coded.   But, it turned out to be a
technique that mixed apples and oranges in the SGML world -- the coding
of that kind of data belonged in a header.  It has dawned on me that my
pleas to 'see a title page' printed  from a header might be answered if I
knew how to take advantage of the re-coded finding aids Daniel has put up
at Berkeley, ....  well, topic for here.

(3.c) the CONTROLLED ACCESS element, Kris wrote wondering where it
belonged; Janice agreed it ought to go down a level; and Michael suggested
tucking it in ODD.  I'd been thinking it was the batch of 'headings' that
applied to whole collection (the 6xx headings out of a MARC collection
record, but embedded in the finding aid to help those who search only
among finding aids, or, don't have MARC recrods pointing to the finding
aids) ... So, it made sense to me at its current 'high level' AND I'm
content to have it go down into ODD, too.  Janice asks: would use
Controlled Access element anywhere in finding aid?  (She hopes so.)

(3.d) for the SOURCES LIST: a summary:  Michael listed all that are in
MARC Subject/index Term sources:  aat, lctgm, gmgpc, lcsh, local, mim,
nmc, rbgenr, dot, mesh, lcnaf, lcsaf, aacr2, other.  (How would lcsaf be
different from lcsh?  Would aacr2 be used to indicate the rules used to
formulate the heading, rather than a list from which a heading was taken?
So, might use BOTH aacr2 and lcnaf, or, aacr2 and local?)

Steve added 2 Canadian sources: Canadian Subject Headings and Repertoire
des vedettes-matiere.

Let the application guidelines settle whethere cite by code or name.

(3.e.) for STATUS ATTRIBUTES, I like Janice's blending of what I suggested
and Michael thought okay.  Four statuses:  Unverified Partial Draft;
Unverified Full Draft; Edited Partial Draft; Edited Full Draft.

                HAPPY NEW YEAR

P.S.  Could someone who's going to the LA meeting print out this message
and take it for Janice to read?  She won't have access to eMail until she
gets to LA, which helps explain why I'm trying to write for both of us.