Print

Print


Hello again,

<http://www.artefactual.com>
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.


<did>
  <!-- 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>
</did>

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


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 <http://www.artefactual.com/>.
604-527-2056







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

> Dan,
>
> 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.
>
> Mike
>
>
>
> 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:
>>
>>
>>
>> <chronlist>
>>
>>    <chronitem>
>>
>>      <date type="broadcasting" normal="19990000/199990000">1999</date>
>>
>>      <event>
>>
>>        <note type="eventNote"><p>This is a note for Bobby
>> Broadcaster</p></note>
>>
>>        <name>Bobby Broadcaster</name>
>>
>>        <geogname>XXXXXXX</geogname>
>>
>>      </event>
>>
>>    </chronitem>
>>
>>    <chronitem>
>>
>>     NEXT EVENTS WOULD GO HERE....
>>
>>    </chronitem>
>>
>> </chronlist>
>>
>>
>>
>> …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 <http://www.artefactual.com/>.
>> 604-527-2056
>>
>>
>