Another vote for care in taking any steps to avoid apparent redundancy.
It may cause problems not only in somebody else's system now, but in a
future system that you (or your institution) might build or adopt.
When trying to add credibility to this point of view, I sometimes use this
quote from Elaine Svenonius in the "Intellectual Foundation of Information
Organization" [MIT Press; 2000] a book that goes into cataloging history
and the principles behind many cataloging rules and practices in a
thorough analysis -- reflecting on problem areas as well as on the wisdom
that has stood the test of time.
P 93 and footnote 15
"... the use of one device to serve multiple functions, ... while favored
by the principle of parsimony, nevertheless introduces a lack of
flexibility that can become an obstacle as technology changes.  When
technology changes, so do means to ends. It can happen that one of the
functions performed by a multifunctional device could be better achieved
by other means."
As you can probably tell from the quote, the book is long, somewhat
abstract, and not a particularly easy read, but as someone who has tangled
fairly extensively with heterogeneous descriptive records, I found it
enlightening and even fascinating. Don't skip the footnotes.
Caroline Arms [log in to unmask]
Office of Strategic Initiatives
Library of Congress
On Mon, 9 Sep 2002, Fox, Michael wrote:
> I strongly support Stephen's reply with regard to redundancy. This
> question is often raised in our EAD workshops- why do I need to include
> things like <head> and <arrangement> when I can automatically generate them
> during output? My first reply is that you can but you cannot be sure that
> someone else will. What is an obvious solution when the file is living on
> your server and you can supply all the bells in whistles, may create
> problems in a shared environment such as consortial database where there are
> other assumptions about the availability of certain data elements that might
> drive displays.
> Another argument for greater consistency in encoding, probably driven by
> some generally accepted and widely implemented content and encoding
> protocol. But until that halcyon day-