We are adding encodinganalog attributes to MARC equivalents only at the
<archdesc> level. It's easy to do by default for these key elements
that tend to be present in every instance.
The utility of doing so is speculative, based on the possiblity of
extracting information from finding aids for inclusion in MARC records.
It may never come to pass, but, as I say, the overhead of doing so is
negligible as they are added automatically as part of our authoring
I say speculative because we now are actually extracting information
from the MARC records for inclusion in our inventories rather than the
other way around.
Head of Processing
Minnesota Historical Society
345 Kellogg Blvd West
St. Paul MN 55102-1906
[log in to unmask]
**NOTE NEW AREA CODE EFFECTIVE JULY 12, 1998**
> From: abpp.c&[log in to unmask][SMTP:[log in to unmask]]
> Sent: Thursday, September 24, 1998 11:13 AM
> To: Multiple recipients of list EAD
> Subject: USMARC encodings
> We have several questions related to the usage of MARC encodings.
> We hope that your answers may help us decide whether or not it is
> to add them in the finding aids.
> Who is actually using the attribute value "USMARC" in <EAD
> We would like to know approx. what percentage of users are actually
> in the MARC codes in the attribute ENCODINGANALOG that is included
> the EAD elements. Also: do you use as many codes as possible, or do
> you use
> a limited number of them?
> What is the added value of using the attribute ENCODINGANALOG? Will it
> worth all the extra tagging?
> Thank you very much for your help,
> Els van Trigt,
> Alfa Base publikatie processors.