Print

Print


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.

Mike
____________________________________
Michael Rush - Manuscript Processor
Massachusetts Historical Society
[log in to unmask] - (617)646-0553