[yul-naco] Fwd: LC/NACO Authority File enhancements & changes

[Manon Theroux]

Dear NACO catalogers,

Forwarding a message from RLG detailing some NACO-related enhancements. The 
most important is that newly created records will now be available 
*immediately* using the "st s" command via a Command Line search.

Read below.

-Manon

>July 1, 2005
>To: RLG NACO Coordinators & Liaisons
>From: Ed Glazier, RLG
>Subj: LC/NACO Authority File enhancements & changes
>
>On the evening of June 30, 2005, we installed some changes in the LC/NACO 
>authority file.  No client changes or any other action is required on your 
>part.  Two of these changes are the direct result of user feedback.  Two 
>other change were made a couple of weeks ago because of a number of errors 
>reported by LC in RLG user-contributed records.
>
>1.  Access to saved records in deferred queue (before processing).  A few 
>days ago, we changed processing of the LC/NACO deferred queue so that it 
>begins at 1:00 a.m. Pacific Time and runs every hour until 9:00 p.m.  This 
>means that access to your saved status records (via command line search ST 
>S) and headings in newly created and updated saved and pending records 
>(via the Pending Heading browse using the radio button and Pending Heading 
>Phrase (PHP) and Pending Heading Word (PHW) should be delayed by no more 
>than an hour.
>
>Although there were some comments that this was an improvement, a number 
>of you requested access be made available to saved records in the deferred 
>queue as soon as possible, i.e., as soon as they had been entered and we 
>have now implemented that enhancement.   A command line search for saved 
>status records (using ST S) now searches both the deferred queue and 
>indexed records.  You may also include an optional date in the form 
>"mm-dd-yy" or "mm-ccyy" with your search.
>
>2.  Retrieval of records without 010 via LCCN search.  NAF records created 
>up to the late 90s did not contain an 010 field unless 010$z were 
>necessary to record a cancelled LCCN.  LCCN is now a required field for 
>contributed records and is also a common access point.  With the database 
>migration, the form of the RLIN ID for NAF records is the same as the 
>010$a value - or the value of the 010$a if one were present.  Therefore, 
>we have instituted a change to search both LCCN and record ID indexes when 
>a user searches for LCCN.
>
>Note, however, that if the LCCN is for a cancelled record, two or more 
>different records may be retrieved: a deleted record, which is retrieved 
>because the record ID is indexed for deleted records and a current record 
>where the LCCN of the deleted record is in 010$z of the record that now 
>represents the same heading as in the cancelled record.  Until this 
>change, a deleted record would only be retrieved by a record ID search.
>
>Inputters should never enter the value of 010$a in an authority 
>record.  This value is system-supplied for new records when they are 
>entered.  If you need to add 010$z for a cancelled record (usually done 
>only by LC), you should be able to add the 010$z to an existing 010$a in 
>the record.
>
>3.  Automatic removal of blanks following subfield codes in authority 
>records.  LC reported to us a number of records that included blanks 
>between a subfield code and the beginning of a value.  Although we 
>indicated a few weeks ago that we probably would not remove such blanks 
>automatically, we have found a way to do this.  After a record is entered, 
>these blanks will be removed.  We will not be removing such blanks in 
>bibliographic records or before subfield delimiters in either 
>bibliographic or authority records because some subfields may legitimately 
>begin or end with one or more blanks.
>
>4. Language of catalog (008/08).  LC reported a surprisingly large number 
>of records where the value for language of catalog (008/08) had been 
>changed from blank that is supplied in the templates to some other 
>value.  Although values other than blank are defined in MARC 21, the LC 
>NACO Guidelines indicate that blank is to be used in all cases.  In order 
>to prevent records with this error from being contributed, any value other 
>than blank in this element will be changed to blank after a record is 
>entered, regardless of the value that you may have entered or stored in 
>your template.
>
>
>
>32061