Print

Print


Several interesting points have been raised in this discussion that bear a
more extended consideration.

1.  In descriptive practice, we are guided by two types of standards.


   - Descriptive rules that define the elements to be recorded and the
   accompanying thesauri and authority files that specify how we populate
   certain elements.  In a US context these are ISAD(G) and DACS.
   - Electronic communication standards for data interchange.   Again, in a
   US context these are MARC and EAD.

The answer to the question as to whether the dates of archival materials
are part of the title of those records or completely separate is the
business of the descriptive rules, not our communication standards.   MARC
and EAD are not normative in this case.  EAD was written to enable a wide
range of international practice, created according to different conventions
including national standards and local ad hoc practices that exist either
because of institutional preference or a lack of national standards.   It
is not the place one ought to go for direction on this question.

2.   Our practices confuse the issue at stake.

One encounters many finding aids that look like this.

Example A:

Correspondence
     1919-1925
     1926-1950
     1951-1965

What is really meant here is

Example B:

Correspondence
          Correspondence, 1919-1925
          Correspondence, 1926-1950
          Correspondence, 1951-1965

In example A, the dates given for the contents of these three files are the
dates and not the title proper of the material being described, even if one
considers the date to be a segment of the title.

DACS countenances this through the long-standing principle of
non-repetition in multi-level description that is expressed in Principle
7.3.


Non-repetition can be a useful concept.  After all, who would wish to
repeat the name of the repository at  every level of description?
However, it can also be confusing and is troubling for the future.

The non-repetition of the title proper in Example A is really a holdover
from the days when we considered a finding aid to be a narrative
description of the collection to be read serially on typed pages rather
than as data the describes units of archival materials.

An early question in this thread was whether or nor the nesting of unitdate
within unittitle would be confusing to databases.  I don't think that
relational databases are the cause of the problem but rather that they
expose  the priority that we have given to presentation on the printed
page, rather than taking a more data-centric view of the  information we
record.   Is this where we want to be?

3.   Is the date then, looking at descriptive rules, a segment of the title
element or something completely separate and independent?

a.    As has been pointed out, this appears to be strictly a US problem.
 Or more properly, a problem for some US institutions.  No other cataloging
practice with which I am familiar treats unit dates as anything but a
separate element.

b.  ISAD(G) treats it as separate.

c.  DACS treats it as separate element.  It identifies three possible
segments that might be included in a title.    Date is* not* one of them.
 In discussions at the time DACS was being drafted, the authors were very
clear that dates were not a part of the title element.

This is reenforced in the Introduction to Describing Archival Materials (p.
3) by the statement that data elements are mutually exclusive.   They can
go in one place or the other.

d.  The practice of including dates as a segment of the title in MARC comes
from APPM which in turn reflected in some examples an older manuscript
cataloging practice for constructing title.  Consider this example of a
title from the first edition.

ALS, [ca. 1898 Jan. 1], Worcester Park Surrey to George Gissing, Rome.

But even then in 1983, this practice was clearly antique and inconsistent
with newer formats for constructing titles

4.  Encoding dates as parts of titles in EAD is not desirable.   For a
standard created to facilitate the international exchange of data,  having
most archivists worldwide following one practice and some in the US another
only confounds interchange and complicates training and implementation.

5.   An archival description that treats unitdates as part of the unittitle
is simply *not* DACS compliant.

Michael Fox

On Mon, Mar 26, 2012 at 10:16 AM, Prom, Christopher John
<[log in to unmask]>wrote:

> Cory,
>
> Thanks for laying this out in such detail.  I just wanted to point out
> that although Archon currently wraps unitdate w/in unittitle, I actually
> think it best if in were NOT wrapped, in compliance w/ ISAD(G) and DACS.  I
> didn't give much thought to it at the time we programmed the first EAD
> export in Archon, and we haven't reviewed this coding since the original
> development of the application. Moving it outside would be a trivial
> matter, and I'll take care of that in one of our next maintenance updates.
>
> Thanks,
>
> Chris
>
> --
>
> Christopher J. Prom, PhD
> Assistant University Archivist and Associate Professor
> University of Illinois Archives
> 19 Library
> 1408 W. Gregory Dr.
> Urbana, IL 61801
>
> [log in to unmask]
> +1 217 333 0798
>
> http://www.library.illinois.edu/archives/
>
> Blog: http://e-records.chrisprom.com
>
> On Mar 24, 2012, at 10:12 AM, Cory Nimer wrote:
>
> While there is what you might call a growing consensus that <unitdate>
> should not be encoded within the <unittitle>, there is still disagreement
> within the community. This can be seen in comparing some of the different
> best practices documents, management tools, and content standards
> available. In the best practice guidelines listed on the EAD Help Pages:
>
> Northwest Digital Archives -- Outside of <unittitle>
> "To insure compliance with ISAD(G), do not nest <unitdate> inside
> <unittitle>." -- Online table
>
> Online Archive of California -- Outside of <unittitle>
> "The <unitdate> should be encoded outside of <unittitle>." -- p. 12
>
> Library of Congress -- Either inside or outside of <unittitle>
> "Following/within <unittitle> and before <unitid> in Collection Summary."
> -- Online table
>
> RLG Best Practice Guidelines -- Either inside or outside of <unittitle>
> "US repositories following APPM practice normally include <unitdate> as
> part of <unittitle>, whereas British and Canadian practice, following
> ISAD(G)v2 use <unitdate> at the same level as <unittitle>. Given the
> likelihood of further international standardization, separate title and
> date is preferred but both practices are permitted. Repeat <unitdate> if
> both inclusive and bulk dates are given. This element is considered an
> essential element for data exchange by ISAD(G)v2." -- p. 12
>
> NCEAD Best Practice Guidelines -- Inside of <unittitle>
> "Always place the date within a <unittitle>, as the date is part of the
> title of the unit as well as a date." -- p. 40
>
> There is also some variety in date handling between the different
> community-developed archival management systems:
>
> Archivists' Toolkit -- Outside of <unittitle>
> ICA-AtoM -- Outside of <unittitle>
> Archon -- Inside <unittitle>
>
> In terms of content standards, because of DACS's foundations in ISAD(G)
> date is clearly a separate element from the title. While this might be an
> argument for not wrapping the <unitdate> in <unittitle>, the examples
> provided in the text include instances of both including <unitdate> in
> <unittitle> and keeping it separate. The understanding that <unitdate>
> should be wrapped in <unittitle> is reinforced, I think, by the long-term
> practice of including dates as part of the title in MARC, as established in
> APPM. All but one of the MARC examples in DACS are marked up in this
> fashion. However, it is worth noting that the MARC mapping provided in RDA
> no longer places dates of production of archival materials in the 245$f,
> but in the 260$c. In order to make this clearer in MARC, the 264 field was
> also recently approved to make the role of the date entry clearer.
>
> Ultimately, this might be considered to be a legacy practice, but one that
> is still widely implemented. Perhaps this is something that the current EAD
> and DACS revisions will clarify for the community. In the meantime, I
> personally believe that the RLG Guidelines are correct that it is
> preferable to keep <unitdate> outside of <unittitle>.
>
> Cory Nimer
> Manuscripts Cataloger/Metadata Specialist
> Brigham Young University
> 801-422-6091
> ________________________________________
> From: Encoded Archival Description List [[log in to unmask]] on behalf
> of Elizabeth H Dow [[log in to unmask]]
> Sent: Saturday, March 24, 2012 6:07 AM
> To: [log in to unmask]
> Subject: Re: dates wrapped in title field in box list
>
> Where to place <unitdate> raises the question of whether a date a is an
> integral part of a name/title, as it is in MARC, or if it's a separate data
> element on its own. About 12-15 years ago, the question was a point of
> disagreement between the US and UK EAD communities. Both are legal in EAD;
> has a general consensus appeared about which is the better way to look at
> dates?
>
>  Wiz
>
> Elizabeth H. Dow, PhD.
> Professor
> School of Library and Information Science
> Louisiana State University
>
> ________________________________________
> From: Encoded Archival Description List [[log in to unmask]] on behalf
> of MicheleR [[log in to unmask]]
> Sent: Friday, March 23, 2012 7:29 PM
> To: [log in to unmask]
> Subject: Re: dates wrapped in title field in box list
>
> We do this all the time.  Instead of <date> though you'd want to use
> <unitdate>.
>  The <date> element is just for any old date info, including embedded in
> narrative text, whereas <unitdate> is specifically for the date(s) of the
> archival unit being described -- see
> http://www.loc.gov/ead/tglib/elements/unitdate.html .
>
> So like this:
>
> <unittitle><unitdate normal="1980/1985">1980-1985</unitdate></unittitle>
>
> I have no idea whether it would cause problems, or what sort, in a database
> (depends on how the database is set up, I guess?) but in terms of EAD it's
> perfectly legal and logical.  It doesn't affect searching for us because we
> index and search the EAD directly.
>
> Michele
>
> On 3/23/2012 5:42 PM, Ashley Knox wrote:
> > What is the consensus on date fields being wrapped inside of title
> fields,
> > especially when the title of a folder IS a date? (specifically in a
> container list)
> >
> > <unittitle> Bills and Receipts,
> > <date normal="1850/1859" type="inclusive">1850-1859</date>
> > </unittitle>
> >
> > or
> >
> > <unittitle>
> > <date calendar="gregorian" normal="1980/1985" era="ce">1980-1985</date>
> > </unittitle>
> >
> > All of this being related to the effect on searching in a database
> (built in a
> > mysql database). I've been told that this will hinder searching and that
> it
> > needs to change, that title and date need to separate into their own
> respective
> > fields. I'm working in AT. Would I just not have folder titles, but
> dates instead?
> >
> > I would love to hear opinions on the pros and cons of mysql databases
> vs. xslt
> > styling as well, if anyone would like to comment.
> >
> > Thanks for any and all comments!
> >
> > Ashley Knox
> > Project Manager
> > USC Digital Collections
>
>
> --
> ***************************
> America may be unique in being a country
>  which has leapt from barbarism to decadence
> without touching civilization.
> -- John O'Hara
> ***************************
>



-- 
Michael Fox