Thanks Bill - I really appreciate this!  

Actually, I did get a fair number of private responses from kind people
out there who took pity on me (smile) - they were so incredibly helpful
and if anyone else out there would like a copy of the e-mails, please
let me know!  I've definitely got to take some classes!!

Thanks again to everyone - you, as usual - have helped me enormously!

Evelyn


Evelyn Taylor, University Archivist
Cal. State Univ., Channel Islands

-----Original Message-----
From: Archives & Archivists [mailto:[log in to unmask]] On
Behalf Of Bill Landis
Sent: Thursday, June 22, 2006 11:20 AM
To: [log in to unmask]
Subject: Re: EAD and DACS - It's Greek to me!

Hi Archives list colleagues,

Just wanted to jump in here and try to address some of the issues raised
= in this thread of listserv posts. To be right up front about my
context for what I have to say below, I was involved for 2 years in the
work of the Canadian-U.S. Taskforce on Archival Description (CUSTARD),
out of which D= ACS was produced for the U.S. archival community. DACS
emerged from a shared draft standard created by the CUSTARD group, and
the Canadian version of that, RAD2, is still in review (see below).
Also, I'm one of the instruct= ors for the SAA DACS workshop.

DACS & EAD

The question in Evelyn Taylor's original post on this subject doesn't
see= m to have gotten addressed. It was a request "... in the simplest
terms possible, [for an] explanation of what DACS is - as compared to
EAD - [an= d] do they work together or not?"

DACS is a data content standard and EAD is a data structure standard. So
= if you think about EAD as defining the buckets, DACS helps you to
figure out=

what to put in some of those buckets. There's a great explanation of
cont= ent standards vs. structure standards in "Descriptive Metadata
Guidelines for=

RLG Cultural Materials", available at
http://www.rlg.org/en/pdfs/RLG_desc_metadata.pdf - specifically "Chapter
=
1:
Terminology" on p. 3-5. DACS is only one of many data content standards
t= hat might help you determine what content to supply in which EAD
elements. If=

you want an overview of the correspondence between DACS element content
rules and EAD tags, you might take a look at the DACS Appendix C, Table
C=
-5
erratum, available on the SAA web site at
http://www.archivists.org/publications/DACS_TableC5_Erratum.pdf. This is
= a crosswalk that maps DACS element content rules into specific EAD and
MARC=

"buckets". As indicated on the erratum, this replaces p. 220-221 in
exist= ing print copies of DACS, and will replace these pages in the
next printing o= f DACS.

DACS as a US Standard

It is kinda fuzzy what makes something a "US standard", but in the
archiv= al community it seems like approval via SAA's standards process
is one step,=

and having something officially accepted in Library of Congress
catalogin= g documentation is another. Both of these have happened with
DACS. DACS was=

approved by SAA Council as an SAA standard in March 2005 on the
recommendation of SAA's Standards Committee, and it has been added to
LC'= s "MARC Code List for Description Conventions" (see
http://www.loc.gov/marc/relators/reladesc.html). You'll note that APPM
is=

still on LC's list as well, so even though it is no longer an official
SA= A standard (as noted earlier in this thread), it is still possible
to use i= t, if for some reason you want to, as a description convention
for your MARC=

cataloging.

DACS & ISAD(G)

ISAD(G) (http://www.ica.org/biblio/isad_g_2e.pdf) is unarguably the
international standard for archival description. It may be worth
pointing=

out here that ISAD(G) parallels another standard with which many of you
m= ay be familiar: ISBD(G) (the General International Standard
Bibiliographic Description --
http://www.ifla.org/VII/s13/pubs/isbdg.htm), which has bee= n around for
a lot longer. A salient point in discussing DACS and APPM is t= hat
ISAD(G) did not even exist when APPM was created. Prior to ISAD(G)
becomi= ng an official standard of the International Council on Archives
(ICA) in 19= 94, the world for archivists was cast both in the context
of and in response = to ISBD(G). So DACS is the first U.S. content
standard for archivists that post-dates and incorporates ISAD(G).
ISAD(G) envisions an archival conten= t standards infrastructure in
which the very high-level definitions of elements used in archival
description in ISAD(G) are used in conjunction with more specific
national standards, of which DACS is an example for U.= S.
archivists (see I.1 in the ISAD(G) Introduction on p. 7). So DACS
incorporates ISAD(G) with a few well-reasoned tweaks, and I think it is
worth emphasizing that there is no conflict between DACS and the
international:national archival content standards model outlined in
ISAD(= G).
In case it is useful, I've attached a slide (.wmf file that should open
readily on any Windows machine) that explicitly outlines where DACS
diffe= rs from the description elements set forth in ISAD(G). The one
ISAD(G) eleme= nt (Level of Description) for which DACS does not have a
comparable element = is incorporated in DACS via the Chapter 1 "Minimum"
requirements, so it isn'= t completely missing.

DACS & Other Standards, including RAD

I just wanted to dig a little deeper on a couple statements that Kate
Bow= ers made. Kate says that RAD (the Canadian Rules for Archival
Description) is=

much more prescriptive than DACS, which is absolutely true. I think
thoug= h that the comparison really needs to be made between DACS and
RAD2. I know=

that a draft of RAD2, which was the Canadian product based on the work
of=

the CUSTARD group from 2001-2003, was in circulation for comment by
Canad= ian archivists last year (for those interested, there's a bit of
information = on the progress of RAD2 adoption at
http://www.cdncouncilarchives.ca/archdesreport.html), but I don't know
wh= ere it is in the process of being officially adopted as a
replacement for RAD=  by the CCA. So maybe someone from Canada will
weigh in here and update us.
Nonentheless, Kate's observation that the Canadian archival description
standard is more detailed and more prescriptive is true, and will
certain= ly be true of RAD2 as well.

There are probably a lot of reasons for DACS's lack of prescriptiveness.
Chief among them being the more heavily manuscripts-based U.S. archival
tradition (when compared to the Canadians and much of the rest of the
world), and the lack of gov't funding in the U.S. for a maintenance
infrastructure for archival descriptive standards [in Canada, the
meeting= s of the Canadian Committee on Archival Description (CCAD) are
at least in part funded by the National Archives and happen 4 times a
year, I believe= ]. 

Kate indicates that the notion in DACS that you can incorporate it with
other standards "makes DACS highly unlike any other standard of its
kind.= "
Kind of, but not unintentionally so. DACS is among the first out of the
g= ate in a standards revision process that is likely to radically
change the ba= sic infrastructure for descriptive standards (though
hopefully not so radical= ly the end product of description, whether it
is archival or bibliographic).=

CCO (Cataloging Cultural Objects: http://www.vraweb.org/ccoweb/) also
envisions being incorporatable with other content standards, though I'm
n= o expert on this particular standard. I did attend a CCO workshop at
WebWis= e
2006 in LA in which Murtha Baca and Elisa Lanzi were very clear that CCO
could supported very flexible implementation in conjunction with other
standards, like DACS. The big sea change, though, will likely be the
rele= ase of RDA (Resource Description and Access:
http://www.collectionscanada.ca/jsc/rdaprospectus.html), which will
repla= ce
AACR2 sometime in the next year or so. Again, I'm no expert in where
this=  is going, because I'm not a bibliographic cataloger. But it seems
pretty cle= ar that once RDA is "live", many standards that are based on
the AACR2 model=

(like Graphic Materials, AMIM, and the IASA Cataloguing Rules) will have
= to be rethought in response to whatever direction RDA takes. So I
guess I'd just like to add this as a coda to what Kate says about the
relationship = of DACS to other standards: it seems too early to tell,
and seeing what happ= ens with RDA will be a bellweather, I think, about
where the content standard= s world is going.

Kate also states that DACS "conflicts with just about every other
catalog= ing standard ... by never instructing one to transcribe a
formal title if the= re is one." I don't see the conflict. What DACS
does clearly state is that there is nothing archival about transcribing
a formal title, and that an archivist needs to exercise professional
judgement about when a formal ti= tle exists and is worth transcribing.
The fact of the matter is that the noti= on of formal title is a
bibliographic construct, and presumes some "chief source of information"
(like a title page) that is created in the course = of the publishing
process to capture information about the production of the=

work. ISAD(G), on which DACS is based, leaves the choice between
providin= g a formal title, if it exists, or a supplied title up to the
"national conventions" (see "Rules" under 3.1.2 Title in ISAD(G)). So
the fact that=

most of the other standards to which Kate refers are based on ISBD(G),
an= d DACS is, uniquely in the world of U.S. descriptive standards,
based on
ISAD(G) means that there isn't a conflict. DACS takes a fundamentally
different approach and doesn't preference any kind of formal title. This
pretty much bears out in RAD2 as well (see the draft of Part I at
http://www.cdncouncilarchives.ca/RAD2-Part%20I%20Description.pdf). If
you=

look at rule 4.3B32 on p. 14 you'll see that the instruction to prefer a
formal title is qualified by the notion that you're actually describing
a= t a level at which the notion of a formal title makes sense (e.g.,
not the fo= nds or series, and arguably frequently not the file), that
the formal title i= s "common to all the materials in the unit being
described", and that  it "accurately and clearly names the unit being
described". So in RAD2 the preference for a formal title is highly
qualified by what amounts to the same thing as the notion of "the
archivist's professional judgement" in D= ACS.

What DACS does say is that if in your professional judgement there is a
meaningful formal title on the unit you're describing that you want to
transcribe, you should use the rules created by the bibliographic
communi= ty (currently AACR2, soon to be RDA) to guide your
transcription. To me that=

doesn't look like a conflict, it looks like a wide open embrace.

My apologies that this got so long-winded, but I hope it helps to
untangl= e this issue a bit for those who have questions. 

Bill Landis
Metadata Coordinator
California Digital Library
University of California Office of the President
415 20th Street, 4th floor
Oakland, CA  94612-2901
(510) 987-0809
[log in to unmask]

A posting from the Archives & Archivists LISTSERV List sponsored by the
Society of American Archivists, www.archivists.org.
For the terms of participation, please refer to
http://www.archivists.org/listservs/arch_listserv_terms.asp.

To subscribe or unsubscribe, send e-mail to [log in to unmask]
      In body of message:  SUB ARCHIVES firstname lastname
                    *or*:  UNSUB ARCHIVES To post a message, send e-mail
to [log in to unmask]

Or to do *anything* (and enjoy doing it!), use the web interface at
     http://listserv.muohio.edu/archives/archives.html

Problems?  Send e-mail to Robert F Schmidt <[log in to unmask]>

A posting from the Archives & Archivists LISTSERV List sponsored by the Society of American Archivists, www.archivists.org.
For the terms of participation, please refer to http://www.archivists.org/listservs/arch_listserv_terms.asp.

To subscribe or unsubscribe, send e-mail to [log in to unmask]
      In body of message:  SUB ARCHIVES firstname lastname
                    *or*:  UNSUB ARCHIVES
To post a message, send e-mail to [log in to unmask]

Or to do *anything* (and enjoy doing it!), use the web interface at
     http://listserv.muohio.edu/archives/archives.html

Problems?  Send e-mail to Robert F Schmidt <[log in to unmask]>