While it's nice to feel Michael's concurrence, I didn't actually claim
what Michael is saying. I was merely pointing out that I had set the
encodinganalog on eadheader to DC and that the RC's advice regarding
possible values in MARC was therefore irrelevant. The propriety of the
choice of MARC or DC for encodinganalog was not something on which I was
expressing an opinion.
FWIW, I chose DC because I felt that since OAI requires DC, using DC as
the encodinganalog for descriptive data about the finding aid would be
helpful in the creation of OAI records for finding aids. It's not
necessarily inappropriate to use MARC. I just cannot envision a near term
scenario in which having MARC encodinganalogs for the data in eadheader
would benefit me.
Also, yes, guidance or RC rule checking for the syntax of MARC 1XX, 6XX,
and 7XX fields, subfields, and indicators in ENCODINGANALOG would be
On Wed, 24 Aug 2005,
Fox, Michael wrote:
> I concur with Terry that MARC encoding analogs for <eadheader> are
> generally, and probably always, inappropriate or irrelevant. Header
> data relates to the finding aid, not the stuff.
> Except where the finding aid is in fact a publication that is being
> cataloged, one catalogs the collection itself. Therefore, any MARC
> metadata should come from <archdesc> rather than <eadheader> elements.
> This also raises the question as to how MARC fields, indicator values,
> and subfields are being or should be coded in @encodinganalog inasmuch
> there is no standard syntax.
> -----Original Message-----
> From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf
> Of Elizabeth Shaw
> Sent: Wednesday, August 24, 2005 1:47 PM
> To: [log in to unmask]
> Subject: Re: RLG EAD Report Card - questions
> As it turns out, the DC values were not written into the guidelines at
> the time that the report card was developed (last August). One could
> change the rules file so that it contains the appropriate DC values.
> There is documentation about how to create additional rules which comes
> with the package. You could use those to figure out how to modify the
> existing rules file.
> Liz Shaw
> Terry Catapano wrote:
>> My understanding in each of these cases is that the RC is saying that
>> element or attribute is mandatory and suggests *possible* values for
>> MARC, not that the values are mandatory. As for the appropriateness of
>> the MARC values, it all depends on how one would go about cataloging
>> finding aid, which is what is within the scope of the eadheader (and
>> descendant encodinganalogs), not the material described in the finding
>> aid. That said, the values seem reasonable.
>> With regard to the possible values provided by the RC, something I
>> like to see is making the suggested values for encodinganalog come
>> the encoding declared in the "current" relatedencoding attribute. In
>> case, for eadheader it is DC, so the possible values for MARC are
>> I realize that such co-occurrence constraining may be tricky to code.
>> On Wed, 24 Aug 2005, Michele Rothenberger wrote:
>>>> I'd like to see questions about the report card go to this list, so
>>>> everyone can learn together, and so that I can start to compile a
>>>> "frequently asked questions" document an improve the readme files
>>>> source code itself.
>>> Per Merilee's invitation, I'll start things off with some items that
>>> the report card (RC) flags as errors. I have looked at the Library
>>> of Congress material on the related MARC fields
>>> (http://www.loc.gov/marc/bibliographic/) and have some questions.
>>> 1) The RC says it's mandatory that PUBLISHER
>>> (ead/eadheader/filedesc/publicationstmt/publisher) should have a MARC
>>> encoding analog of 260$b. The 260 field seems to be for publication
>>> the *material* (books, letters, what have you). Per the EAD cookbook
>>> and the EAD tag library, PUBLICATIONSMT and its child elements
>>> contain information about the publication of the finding aid, not of
>>> the material itself. As such 260 doesn't seem appropriate.
>>> 2) The RC says it's mandatory that
>>> ead/eadheader/filedesc/publicationstmt/date should have a MARC
>>> encoding analog of 260$c. Same question applies as for #1.
>>> 3) The RC says it's mandatory that CREATION
>>> (ead/eadheader/profiledesc/creation) should have a MARC encoding
>>> analog of 500. MARC 500 is for note fields relating to the material,
>>> whereas PROFILEDESC and its child elements are for information about
>>> the finding aid, right? So 500 doesn't seem appropriate.
>>> 4) The RC says it's mandatory that
>>> ead/eadheader/profiledesc/langusage/language should have a MARC
>>> encoding analog of 546. MARC 546 is for "the language of the
>>> described materials" whereas PROFILEDESC and its child elements are
>>> for information about the finding aid, right? So 546 doesn't seem
>>> appropriate. Is it possible this is an accidental overlap of the
>>> other usage of LANGUAGE as a child of LANGMATERIAL? That's where 546
>>> would be correct, since LANGMATERIAL covers languages used in the
>>> actual collection items.
>>> Any clarification on these points would be much appreciated!
>>> Michele Rothenberger
>>> Syracuse University
>>> Special Collections Research Center
>>> Syracuse, NY
>> Terry Catapano
>> Special Collections Analyst/Librarian
>> Columbia University Libraries Digital Program
>> [log in to unmask]
Special Collections Analyst/Librarian
Columbia University Libraries Digital Program
[log in to unmask]