 |
 |
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 process. 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. Michael Fox Michael Fox Head of Processing Minnesota Historical Society 345 Kellogg Blvd West St. Paul MN 55102-1906 phone: 651-296-1014 fax: 651-296-9961 [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 > valuable > to add them in the finding aids. > > Who is actually using the attribute value "USMARC" in <EAD > RELATEDENCODING="USMARC">? > We would like to know approx. what percentage of users are actually > filling > in the MARC codes in the attribute ENCODINGANALOG that is included > within > 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 > be > worth all the extra tagging? > > Thank you very much for your help, > > Els van Trigt, > Alfa Base publikatie processors. >