These are very good questions Michael. Basically, the approach you are
taking is very sound in my opinion. The organization tag is eliminated in
EAD 2002, so there is no reason to use it at this point. I would not use
<frontmatter> either for the very reasons you mention. Generally speaking
dates should be normalized using a ISO standands such as ISO 8601. I
can't recall what that recommends but it can be checked fairly easily.
Recalling that the <titleproper> is used for the title of the finding aid,
and that you should have listed dates in the <archdesc>, there is probably
no need to add date tags in the titleproper. It is very unlikely anyone
would want to search on such a field in my opinion. <eadid>
should be used, preferably with the type and system id attributes, so
that your finding aid can be definitively identified as unique among the
entire body of finding aids. You will need to get a repository code from
the Library of Congress if you do not have one. Finally, I think you
should both provide an HTML version of the finding aid transformed on the
fly, but also make the raw EAD available. Even if no one transforms it on
the client side, it can then be harvested and reused in other projects
more easily, if you are amenable to sharing the data in that way.
Anyway those are my thoughts.
Assistant University Archivist
University of Illinois
On Thu, 5 Sep 2002, Michael Rush wrote:
> Hello all,
> After a brief project hiatus, I've returned to the work of implementing EAD
> here at the Mass. Historical Society. Looking with fresh eyes at the
> encoding template I created earlier, I have some questions:
> 1. I'm hunting for ways to reduce redundancy. Encoding a series list in
> <organization> seems superfluous when they are repeated in the <dsc> and can
> be extracted for display in a list. Are there any compelling reasons to
> continue to encode the series list in <organization>?
> 2. Also in an effort to reduce redundancy, I'm considering not using
> <frontmatter>. The only piece of data which I had included in <frontmatter>
> which is not encoded elsewhere is publication copyright info for guides we
> actually published years ago, mostly to accompany microfilm editions. If
> eadheader/publicationstmt refers to the electronic publication of a guide, I
> see no where else to encode it. Does anyone else face the problem of
> encoding two separate sets of publication data, one for a printed version of
> a guide and one for the electronic version? If so, have you managed to do
> it without using <frontmatter>?
> 3. I plan on using the normal attribute for date and unitdate tags. When
> encoding a date that has a missing date month or year, is the best practice
> to replace those digits with zeros? For example, would you encode September
> 2002 as normal="20020900" or September 5, no year, as normal="00000905"?
> 4. Does it make sense to encode collection dates as listed in the
> eadheader/titlestmt/titleproper in <date> tags? In a moment of enthusiasm
> for lots of <date> tags I thought it would be a good idea, but now I'm less
> enthused and it seems pointless, especially since the same data is more
> explicitly identified in the archdesc/did/unitdate elements.
> 5. How do you recommend using the <eadid>? I know lots of institutions use
> the SGML Open Catalog specification, but I'm unclear on how it works what
> the benefits are, and if it works in XML at all. We don't anticipate
> sharing our EAD files in any sort of consortium at the moment, so I was
> planning on using a simple four-digit file numbering system.
> <eadid systemid="MHS" type="file" encodinganalog="identifier">0001</eadid>
> (in which case the file name would be 0001.xml), for example.
> 6. A final, non-encoding question. For institutions that have decided to
> deliver raw xml for client-side transformation, what are the advantages of
> this approach? I'm of the opinion that if a user is ultimately going to see
> an HTML based display, why not just send the HTML to begin with? Am I
> missing something? (We will soon begin delivering XML as a part of a
> digital text project, and I think the consensus here is that we will be
> converting our xml data on the fly on our server.)
> Thanks in advance for taking the time to read this laundry list, and for any
> advice that comes to mind.
> Michael Rush - Manuscript Processor
> Massachusetts Historical Society
> [log in to unmask] - (617)646-0553