What I think that we are trying to tell the user several things in the
case you cite. Let me modify your example to one that has a bit wider date
range to make my point clearer.
Assume that I have a collection relating to the war in Viet Nam- a small
collection of personal papers, say correspondence, photos and diaries of one
individual's tour of duty in Viet Nam from May 1969-February 1970. One
access point I want to provide is a topical one- that there is material here
about this war. The subject heading is Vietnamese Conflict, 1961-1975.
The date range given in that subject heading is there to explain to the
uninformed user that this was the time period covered by this war. (It is
also there to differentiate this conflict from that of an earlier period
expressed by the heading Indochinese War, 1946-1954.)
Another piece of information I want to give the user is that I have
materials for the time period May 1969 through February 1970. We have
traditionally expressed such information in the date ranges associated with
the title statement for individual items, files, series, and collections.
The problem with separately indexing the data range 1961-1975 in the
heading Vietnamese Conflict, 1961-1975, is that a search on both the
chronological range 1961-1975 and the topical heading term Vietnamese
Conflict may well return a result that erroneously suggests to the user that
there is material here about the war in 1973. There is not.
Our descriptive practices have always assumed a fairly close connection
between the dates of creation given in a description and the time period of
the content of the materials described. When we say, Correspondence,
1981-1985, the user knows (we assume) that this is correspondence created
between those dates and that the subject matter likely relates to that
period as well. Of course, that is not always the case. And there are
several ways to handle that.
In the old calendar style of manuscript description, we wrote annotations
that explained the nature and content of individual pieces of
correspondence. Today we would think of these as mini-scope and content
statements. As Bill Landis points out, in the cataloging rules now being
developed for the US and Canada, such information- say that the
correspondence between 1986 and 1987 actually covered the author's childhood
from 1952 to 1957- would be expressed in a scope note. Inasmuch as EAD
2002 has a <date> element with a Type attribute whose content is any
character data, one could do the following.
<p>Blah, blah, blah... the correspondence includes discussion of the
author's childhood, <date normal="1952/1957"
type="coverage">1952-1957</date>, as well as yahda, yahda, yadha and so
It may even be useful to index those dates- a local decision largely tied I
assume to some cost benefit assessment. How useful, I would ask, would be
the trade off of greater precision in date searching versus the overhead of
An alternative, if one were operating under a descriptive code that did not
prescribe, as CUSTARD does, the recording of dates of coverage in
association with the title statement, might be to express it this way-
Correspondence. Creation dates, 1986-1987. Coverage dates, 1952-1957.
(Perhaps with some more elegant presentation)
In EAD 2002, with the datechars attribute, this would look like this.
<unitdate normal="1986/1987" datechars="creation">1986-1987</unitdate>
<unitdate normal="1952/1957" datechars="coverage">1952-1957</unitdate>
From this markup, an XSLT stylesheet could generate any number of
I hope this clarifies my comments.
From: Chris Turner [mailto:[log in to unmask]]
Sent: Monday, June 23, 2003 4:04 AM
To: [log in to unmask]
Subject: Re: searching on dates?
Michael Fox wrote:
> 2. Is the interesting date in the Spanish Civil War example the fact
> the war went from 1936-1938 (I don't think that this is the focus) or that
> the contents of the correspondence reflects that time period? If the
> is the case, we need to be able to represent that the time span covered by
> the materials falls at least within the 1936-1938 period. I wonder if
> embedding this information in a subject heading achieves what we really
> to accomplish.
I'm not sure I follow this. The dating detail was just an example to
illustrate that date(s) of coverage/content/subject are different from dates
of creation etc. and are important to encode in order to provide sensible
user access - which is I assume what 'we really want to accomplish'.
> 3. If one is going to mess with the DTD for some local reason (a highly
> dangerous proposition at best), there are less disruptive ways of
> this end without creating the chaos that will occur when such non-standard
> records are distributed to other systems, as they invariably will.
If there's a way to encode date(s) of coverage in EAD2002 then will someone
tell me how to do it. This is not a 'local reason'. There is a real need
to provide 'subject date' access to encoded material and at present there
seems no way of doing it. Our solution is minimally disruptive in that we
use the correct content model for the <date> element, but simply allow it to
be used within <controlaccess>. Any stylesheet which is based on
'standard' EAD2002 should still work, as it will ignore the additional
encoding. Regarding distribution to other systems, EAD as it stands is far
too flexible to enable much in the way of interoperability, but that's
another debate entirely.
As I said initially, what is really needed is an 'official' EAD solution.
There is a real need here which is not being met and while that situation
continues people will 'innovate' because they have users legitimate needs to
> -----Original Message-----
> From: Bill Landis [mailto:[log in to unmask]]
> Sent: Wednesday, June 18, 2003 12:42 PM
> To: [log in to unmask]
> Subject: Re: searching on dates?
> The problem Chris points out is a vexing one. I personally hate to see
> <date> and <unitdate> get used willy nilly by archivists around the world,
> since it seems to me that it poses a real quandry in the future,
> in union database settings, trying to figure out what dates to index in a
> way that will return meaningful results to an end user, or allow end users
> to sort result sets in a meaningful way.
> The work that has been going on in the U.S./Canadian CUSTARD project
> differentiates between the following, all of which an archivist might wish
> to associate with an archival unit being described:
> *date(s) of creation
> *date(s) of recordkeeping activity
> *date(s) of publication, distribution, etc.
> *date(s) of reproduction
> *date(s) of broadcast
> Content (or as Chris characterized them, subject) dates are specifically
> excluded from the date element associated with the creation of the unit
> redirected to the Scope and content element. CUSTARD is not dealing with
> subject-based access points, but it seems to me that subject/content dates
> belong there as well in any system that allows subject-based retrieval (as
> Chris notes in his EAD workaround example).
> I'd really like to see the next version of EAD open up the TYPE attribute
> <unittitle> to #CDATA, allowing it to function the way TYPE functions in
> <date> element. That way, at least, standards of national practice could
> set for prescribed kinds of <unitdate>s and more clarity could be provided
> in the definition of <unitdate> in the tag library as to what should and
> shouldn't be included.
> I'd also like to see some kind of chronological "subject" subelement added
> to those that can be encoded within <controlaccess> to make it legal using
> the EAD DTD to do what Chris has done in a workaround. I think this makes
> perfect sense.
> Chris Turner wrote:
> > We have had to address this same issue for the LEADERS Project,
> > http://www.ucl.ac.uk/leaders-project, and in the process realised that
> > was a further issue with EAD and date searching. The only specific
> > elements in EAD are <unitdate> for date of creation and <date> for a lot
> > other things too numerous to list here.
> > However for date searching we really need an element to describe the
> > coverage date(s). For example George Orwell writes a letter in 1948
> > describes his experiences in the Spanish Civil War in 1936-38. Clearly
> > 1936 -1938 would be useful dates for a user to be able to search on.
> > how to encode it in EAD?
> > Our solution is like Matt to 'enhance' EAD, by using the <date> element
> > within the <controlaccess> wrapper where other searchable data is
> > We use the 'type' attribute on <date> to specify 'subject', 'creation'
> > We also use the standard ISO date notation of '/' to specify a date
> > e.g.
> > <controlaccess>
> > <date type='subject'>1936/1938</date>
> > </controlaccess>
> > This enables us to tell our search engine where and how index dates for
> > user search and retireval.
> > But it looks as if we need an 'official' solution to this from the EAD
> > because ad hoc solutions seem to be proliferating.
> > Chris Turner
> > Senior Research Fellow: Leaders Project
> > School of Library, Archive and Information Studies
> > University College London
> > Gower Street
> > London WC1E 6BT
> > +44(0)20 7679 7205
> > [log in to unmask]
> > http://www.ucl.ac.uk/leaders-project
> > ----- Original Message -----
> > From: "Hillyard, Matthew" <[log in to unmask]>
> > To: <[log in to unmask]>
> > Sent: Wednesday, June 18, 2003 12:40 PM
> > Subject: Re: searching on dates?
> > > Access to Archives (A2A) does indeed offer the functionality to search
> > > dates.
> > >
> > > However, this has been achieved (in the privacy of our online
> > > exploiting the "eXtensibilty" of XML, ie. we were unable to achieve
> > > desired effect by actually conforming to the EAD DTD in this one
> > and
> > > had to bring in mercenary tags of our own...
> > >
> > > The inability of EAD to encode a formal distinction between first and
> > > dates (for date range searching) has always been a stumbling-block for
> > > whilst trying to develop various EAD-based applications over the
> > Yes,
> > > there is the ability to encode a machine-readable, normalised version
> > > dates - but no actual *distinction* between first and last dates is
> > catered
> > > for.
> > >
> > > So developers either have to get out their Regular Expressions and
> > > through several hoops to tweeze out the two limits of the range from
> > > normal= attribute value, as in:
> > >
> > > <unitdate normal="19010904-19670327">4 Sept. 1901 - 27 March
> > 1967</unitdate>
> > >
> > > or come up with an 'innovative' use of EAD upfront, such as:
> > >
> > > <unitdate label="first" normal="19010904">4 Sept. 1901 </unitdate>
> > > <unitdate label="last" normal="19670327">- 27 March 1967</unitdate>
> > >
> > >
> > > Personally, I would much rather see the ability to have something
> > >
> > > <unitdate firstnormal="19010904" lastnormal="19670327">4 Sept. 1901 -
> > > March 1967</unitdate>
> > >
> > > or perhaps even something like:
> > >
> > > <unitdate><firstdate normal="19010904">4 Sept. 1901</firstdate> -
> > > <lastdate normal="19670327">27 March 1967</lastdate></unitdate>
> > >
> > >
> > > I'm afraid I have to admit that for A2A, we ended up introducing the
> > non-EAD
> > > tags <firstdate> and <lastdate> to achieve the desired search
> > functionality.
> > >
> > > And as a consequence from that point on, our data stopped being
> > XML
> > > and became only 'well-formed' XML instead. Not to mention having to
> > > these foreign tags out again when thinking about exchanging EAD data
> > > other institutions...
> > >
> > > Matt Hillyard
> > > A2A Developer
> > > The National Archives
> > > London
> > >
> > > -----Original Message-----
> > > From: Ivo Zandhuis [mailto:[log in to unmask]]
> > > Sent: 18 June 2003 09:28
> > > To: [log in to unmask]
> > > Subject: Re: searching on dates?
> > >
> > >
> > > Access to Archives has the functionality to search on dates:
> > > http://www.a2a.pro.gov.uk/search/index.asp
> > >
> > > ------
> > > Ivo Zandhuis
> > > digital access to cultural information - research and consultancy
> > > http://www.zandhuis.nl/index_en.html
> > >
> > >
> > > ----- Original Message -----
> > > From: "C. Perry Willett" <[log in to unmask]>
> > > To: <[log in to unmask]>
> > > Sent: Wednesday, June 18, 2003 12:30 AM
> > > Subject: searching on dates?
> > >
> > >
> > > > I'm implementing a system for search and display
> > > > of EAD finding aids, and one feature that our
> > > > archivists have requested is a search or limit by
> > > > date. It's not easy, so I looked for examples of
> > > > how other sites might do it. I have found only
> > > > one site that has actually implemented a date search:
> > > > Archival Resources (and it's a little misleading,
> > > > since it seems to be only searching for dates that
> > > > might explicitly appear in finding aids, and not
> > > > for dates within ranges).
> > > >
> > > > I don't find any other site that uses dates at all,
> > > > which raises a few questions for me. I had advised the
> > > > archivists to encode dates and to use the "normal"
> > > > attribute, and they're dutifully following directions.
> > > > However, if we're not going to use them, why encode them?
> > > > I realize that there might be a future payoff, but there
> > > > are costs associated with encoding decisions today.
> > > > Do people want to use dates in searching? If so, how?
> > > > Why do no systems use them?
> > > >
> > > > Perry Willett
> > > > Main Library
> > > > Indiana University
> > > > [log in to unmask]
> > >
> > >
> > > This e-mail message (and attachments) may contain information that is
> > confidential to The National Archives.
> > > If you are not the intended recipient you cannot use, distribute or
> > the message or attachments. In such a case,
> > > please notify the sender by return e-mail immediately and erase all
> > of the message and attachments.
> > > Opinions, conclusions and other information in this message and
> > attachments that do not relate to the official business
> > > of The National Archives are neither given nor endorsed by it.
> > >
> | Bill Landis
> | Manuscripts Librarian, Special Collections and Archives
> | The UCI Libraries, University of California
> | P.O. Box 19557, Irvine, CA 92623-9557
> | 949 824.3113 Voice | 949 824.2472 Fax
> | [log in to unmask]