I'm running a bit of a deficit with respect to responding to queries and
comments on the list, especially with respect to comments and queries
from Helena and Janice. In response to Janice's comments, I revised the
Rostovzeff example. For the most part, I agreed with Janice's
suggestions. You will find the revised example at library.berkeley.edu
/pub/sgml/ead/samples/rostov.sgm. Please ignore the other examples there,
as they have not been reviewed.
I do differ with Janice with respect to language of material:
I recall that we added <langmaterial> to <langusage> in <profiledesc> as a
last minute change before the release of the alpha. We wanted to be able
to distinguish between the language of the finding aid, and the language
of the material being described. Unfortunately, it did not occur to me
until I begin the encoding based on Janice's suggestions that the language
of the material should be part of the description of the materials
themselves, not part of the description of the finding aid. I believe that
<langmaterial> should be removed from <langusage> in beta for this reason.
Further, we had already put in place an attribute, langmaterial, on
<archdesc> and each of the <c>s (of both types), with the idea that the
language of the material would be specified here using either the USMARC
language code list, or the ISO list (no. ?). If we would like to make the
specification of the language more explicit than is possible using an
attribute, then I suggest that we enter the information in a note in the
<did>. [By the way, I also have a suggested change to the note element in
the <did>, but will save this for another message, or, since the idea
emerged at Yale last week, I'll let them make the suggestion along with the
others they have].
Concerning multiple <do>s vs. <dogrp>, I am not sure which is the correct
way to go. I suspect that it may be a matter of presentation.
Of more concern to me is the fact that <do> and <dogrp>, both of which
were thought of as pointers to digital representations of archival
materials are available outside of the <archdesc>. Use of <do> and <dogrp>
should be limited to this purpose, I think. For pointing to non-archival
material, <extptr>, <extref>, <bibref>, and <title> should be used. Note
that I used an <extptr> for the inline Duke seal in <titlepage> in the
I should also point out that the <directory> element description in the
Tag Library is all wrong. The purpose of the <directory> element was to
have an explicit element for pointing to a file directory in which there
were either multiple digital versions (formats) of the same archival
item, or digital representations of two or more archival items. (One
might think of the directory as a "folder," in the archival sense of the
word). This element was added because the LC Digital Library staff will only
provide description above the item level for some digitized collections. We
also anticipate using this method at Berkeley.
I have come to have second thoughts about the need for this element. It
would be perfectly possible and reasonable, I think, to simply use a <do>
to point to a file directory, and devise a notation type for pointers of
this sort to be used in the entity declaration.
As soon as I have time, I will respond to the discussion on use of
tabular layout, and the specification of descriptive level in relation
to <archdesc> and <c>s of both types.