Print

Print


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. [15]  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-
>
> Michael
>