Print

Print


So,
The report card works on a basic pattern matching. At present, the 
encodinganalogs that do exist in the chart form of the Guidelines are 
the ones that are encoded in the rules file. So if in the rules file, 
the crosswalk attribute says '856$u' then only those finding aids that 
list the encodinganalog and follow the exact pattern '856$u' will pass 
muster.

Thus, if you wanted to provide an alternative form you could easily go 
into the rules file and change it to 'R2D2'  and then only 
encodinganalogs that said 'R2D2' would pass muster.

All of the MARC21 encodinganalogs in the rules file are represented 
exactly as they are in the chart in the back of the guidelines.

So as Terry points out, it isn't the report card, it is the Guidelines. 
If you modify the guidelines you can easily change the rules file to match.

Liz Shaw


Fox, Michael wrote:
> So, how does one represent 
> 
> 110 2_ $aMinnesota Historical Society 
> 
> in an encodinganalog in <origination><corpname> where the underscore
> represents a blank space?
> 
> Michael
> 
> 
> 
> -----Original Message-----
> From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf
> Of Elizabeth Shaw
> Sent: Wednesday, August 24, 2005 3:48 PM
> To: [log in to unmask]
> Subject: Re: RLG EAD Report Card - questions
> 
> 
> Sorry, I misspoke (or wrote). The report card is designed to use the 
> syntax that is used in the Guidelines. The syntax wasn't recommended per
> 
> se. In the guidelines they use
> 
> 856$u
> 
> 
> Fox, Michael wrote:
> 
>>I find no direction in the guidelines for the representation of MARC 
>>indicator values which are significant in transformations into MARC 
>>for 1XX, 6XX, and 7XX fields.  Perhaps I missed it.
>>
>>Michael
>>
>>-----Original Message-----
>>From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf
> 
> 
>>Of Elizabeth Shaw
>>Sent: Wednesday, August 24, 2005 3:06 PM
>>To: [log in to unmask]
>>Subject: Re: RLG EAD Report Card - questions
>>
>>
>>RLG recommends, if you are contributing their database, that you 
>>utilize
>>
>>the syntax used in the guidelines. (And in fact that is what the 
>>Report
>>Card expects)
>>
>>
>>Liz Shaw
>>
>>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.
>>>
>>>Michael
>>>
>>>-----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
>>>
>>>
>>>Hi
>>> 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
> 
> 
>>>>an 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
>>>
>>>the
>>>
>>>
>>>
>>>>finding aid, which is what is within the scope of the eadheader (and
>>>
>>>its
>>>
>>>
>>>
>>>>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 
>>>>would like to see is making the suggested values for encodinganalog 
>>>>come
>>>
>>>from
>>>
>>>
>>>
>>>>the encoding declared in the "current" relatedencoding attribute. In
>>>
>>>my
>>>
>>>
>>>
>>>>case, for eadheader it is DC, so the possible values for MARC are 
>>>>irrelevant.
>>>>
>>>>I realize that such co-occurrence constraining may be tricky to code.
>>>>
>>>>Terry
>>>>
>>>>
>>>>On Wed, 24 Aug 2005, Michele Rothenberger wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>>I'd like to see questions about the report card go to this list, so
>>>>>
>>>>>that
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>everyone can learn together, and so that I can start to compile a 
>>>>>>"frequently asked questions" document an improve the readme files 
>>>>>>and
>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>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
> 
>>>of
>>>
>>>
>>>
>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-=--=--=--=--=--=--=--=--=--=--=--=--=--=-
>>>>>Michele Rothenberger
>>>>>Syracuse University
>>>>>Special Collections Research Center
>>>>>Syracuse, NY
>>>>>-=--=--=--=--=--=--=--=--=--=--=--=--=--=-
>>>>>
>>>>
>>>>Terry Catapano
>>>>Special Collections Analyst/Librarian
>>>>Columbia University Libraries Digital Program
>>>>212-854-9942
>>>>[log in to unmask]