Hello again,

Thank you all for your helpful suggestions. As ever, I appreciate the wisdom of the people on this list, and the goodwill with which the community shares its knowledge!

I agree Mike, that using <unitdate> with @DATECHAR still seems preferable - and as we are currently preparing a DACS template for AtoM 2.0, we will definitely want to follow the crosswalk specifications included there.

The problem for us is the Canadian RAD standard, and what it allows for dates and events. For those of you unfamiliar with it - if you know the cataloguing standard AACR2 at all, then you practically know RAD - simply take every added field related to archives, bung it into a Notes Area, and you have RAD. Consequently there are many areas and elements in RAD which are a poor fit for archival materials (Standard number area, Publisher's series area etc.), and equally, there is at times poor support for relevant archival information in the standard. Specifically however, because it was based on a model designed for published materials, RAD allows for numerous types of dates (custody, publication, contribution, collection, reproduction, distribution, broadcasting, and manufacturing), as well as associated persons/organizations other than the creator, associated places, and event notes.

AtoM aims to be a standards-compliant application that supports the description and access needs of its users; and as Artefactual is a Canadian company and a large part of our user-base is Canadian, it is doubly important to us that we offer robust support for our RAD template - even if many of the standard's features are rarely used by practicing archivists.

As such, we have been looking for a way to be able to create associations between <unitdate> and  <note type="eventNote">, <geogname>, and <name> (or persname, corpname, famname) that will roundtrip properly, to accommodate the affordances that RAD makes for dates - this is what led me to explore the chronlist option in the first place.

Off-list it has been suggested to me that we might use <ref>s and definition lists to manage these links in <odd>. I thought I would show an example, to see what people on-list think of such an approach for managing RAD-specific fields - we want to ensure that what we are producing is compliant, and comprehensible, even if it involves a bit of bending to get such library-based linkages into an archival metadata schema. This solution would allow us to continue using <unitdate>, though it does become somewhat more complex...

For context, RAD rules:
1.4B1 = dates of creation
1.4F = dates of publication, distribution, etc.
1.4C = place of publication, distribution, etc.
1.4D = name of publisher, distribution, etc.

  <!-- a few elements -->
  <unitdate datechar="creation" normal="1980/1989" encodinganalog="1.4B1"> 1980 - 1989</unitdate>
  <unitdate datechar="publication" normal="1990" encodinganalog="1.4F"><ref id="111">1990</ref></unitdate>

   <list type="deflist">
      <ref target="111">
         <defitem encodinganalog="1.4C.">
           <label>Place of publication></label>
         <defitem encodinganalog="1.4D.">
           <label>Name of publisher</label>
      <ref target="222">

I welcome any thoughts members of the list might have on the viability and advisability of such a solution. Should this prove infeasible, then I think we will probably follow Michelle's advice, and use our <chronlist> events in an <odd> for the RAD elements which we cannot associate with <unitdate>

Thanks again,

Dan Gillean
AtoM Product Manager / Systems Analyst,
Artefactual Systems, Inc.

On Sun, Jul 7, 2013 at 6:48 PM, Michael Rush <[log in to unmask]> wrote:

My advice: don't get too hung up on the definition of <unitdate> in the EAD 2002 tag library.  The recent revision of DACS includes an EAD crosswalk and it's explicit that dates as defined by rule 2.4 in DACS should be encoded in <unitdate>.  I'm not very familiar with RAD, but it seems reasonable that the types  of dates as defined by RAD should go into <unitdate>, especially if it is qualified with @datechar.  


On Thu, Jul 4, 2013 at 1:02 PM, Dan Gillean <[log in to unmask]> wrote:

Hello all,


I am wondering about how other users are encoding dates that are not specifically dates of creation in their EAD output.


As I understand it, <unitdate> in EAD 2002 is reserved explicitly for the “creation year, month, or day of the described materials.” The @DATECHAR allows for inclusion of some contextual information so that, for example, “accumulation” can be noted. However, dates of contribution, publication, manufacture, broadcast, and so forth do not seem like a natural fit for the element.


In addition to dates of creation, the US content standard DACS allows for dates of publication, broadcast, and “recordkeeping activity.” In Canada, the RAD standard allows for dates of custody, publication, contribution, collection, reproduction, distribution, broadcasting, and manufacturing (often at the item level), in addition to creation and accumulation.


I am looking for solutions to managing these kinds of dates in EAD – we have considered putting them in a <chronlist> as events like so:




     <date type="broadcasting" normal="19990000/199990000">1999</date>


       <note type="eventNote"><p>This is a note for Bobby Broadcaster</p></note>

       <name>Bobby Broadcaster</name>









…where the <name> associated with an event would allow a link to be created with an associated authority record. However, I am not sure if this is the best solution. Where to put the <chronlist> in the EAD output remains a problem as well – putting it in the <bioghist> does not seem appropriate as many of the dates that could be included relate to the archival description object and not the creator – different persons/organizations may be associated with publication, broadcasting, and so forth.


Does anyone have a better suggestion for managing dates other than creation associated with an archival description? Do you have examples of your EAD output?


Thanks in advance,

Dan Gillean
Atom Product Manager / Systems Analyst,
Artefactual Systems, Inc.