Some general comments.
1. If the <unitdate> normal attribute form is changed (amendment 20), as it needed to be to express
date ranges, then the plain <date> element requires the same treatment [sorry I forgot to mention that
when I asked for the <unitdate> amendment].
2. If there is any room for more container level attributes, can I put in a bid for 'bundle' and 'volume'.
While bundle is probably the same as file, a vast quantity of estate records etc. come as bundles
created by the original administrators: 'file' as a description tends to convey the compiling activity of
the archivist, rather than the originator.
While that may be too nice a distinction, 'file' is not really satisfactory to convey the bound container
of a series of items: it is, in at least two senses, too loose. There does not seem to be a description for
a bound group of items, which can be disparate in content but physically united. 'volume' ?
3. Another problem with older administrative collections are previous numbering schemes. When an
archivist has re-arranged a collection there may well be good reason to record the previous
numbering. The only obvious way that avoids creating new elements is to include an extra attribute
in the <unitid>: this would however only allow for one alternative number. I have not yet come
across any instances of more than one re-numbering programme in our collections, but it would be
foolhardy to assume it never happens.
4. Referencing names etc. We certainly would find that to be able to deal with name authorities within
the EAD finding aid would complete an already versatile solution. Looking at the TEI guidelines
there is an attribute 'key' that provides an identifier that can be picked up, for example, by an external
database. If I understand this correctly, it would seem to provide a simple option to incorporate
identifiers into authority controlled fields (which would also presumably allow the generation of
correct automatic indexes for the EAD finding aid ?). Its use could be left to the individual
cataloguing repository, and it may require stripping out before data-exchange, in order not to conflict
with local usage at other sites.
5. For those unconvinced by the unsatisfactory use of <note> within <did> to provide item level
descriptions, I have put together a few rather inconsistent finding aids according to the model of our
existing typescript lists. These can be found at
http://www.dur.ac.uk/Library/asc/sgml/
and I will be delighted [not to say exceedingly surprised] if anyone actually manages to download
one. They reflect our tradition of not providing an introduction, and the lack of front and add matter
has reduced the navigator to a bit of a non-entity in some cases. However, dix.sgml - the
Dixon-Johnson Papers, represents a 60 page list plus some additions and is a good example of how
our style of lists might look.
Richard Higgins
Durham University Library
|