The last time I enquired of LC, there was still no firm date for Phase 3B (I was a member of the working group that wrote and tested the specification).
Concerning ISNIs, it ought to be noted that when the bulk load is done as part of Phase 3B, from a list of correspondences that OCLC will supply, any existing 024 content that has “$2 isni”, and is not on the list, will be removed by the program. There is, therefore, no point in anyone adding an ISNI manually.
Authority Control Team Manager
The British Library
Tel.: +44 (0)1937 546104
Is there any news on when RDA authorities update Phase 3b will take place?
Maybe changing all the 375s that are male and female could also be updated then in batch.
Are others adding ISNIs one by one or waiting for the batch update of Phase 3b?
We've been trying not to make a lot of small updates so as to cut down on the work of reloading authority records, but maybe we should just go ahead with small updates, especially for our own professors.
Sent from my iPhone
On Apr 11, 2017, at 10:05 AM, Adam L. Schiff <[log in to unmask]> wrote:
The PCC Ad Hoc Task Group on Recording Gender in Name Authority Records has recommended using a subset of the gender terms from LCDGT. Males and Females are in that subset, but Men, Women, Boys, and Girls are not. If I encounter a record that has Men or Women I either replace it with Males or Females or delete it if both are present.
The report is available at https://www.loc.gov/aba/pcc/documents/Gender_375%20field_RecommendationReport.pdf
Report of the PCC Ad Hoc Task Group on Gender in Name Authority Records October 4, 2016 Authors: Amber Billey, [log in to unmask] Matthew Haugen, matthew.haugen@ ...
Hopefully, the revised DCM Z1 375 field will be available soon to put these recommendations into PCC policy documentation.
From: Program for Cooperative Cataloging <[log in to unmask]> on behalf of Lasater, Mary Charles <[log in to unmask]>
Sent: Tuesday, April 11, 2017 6:02:43 AM
To: [log in to unmask]
Subject: Re: RDA metadata fields in name authority records--best practices
Thanks so much for putting this together. I find it very useful.
One of the things I do each month is to ‘check’ a load of authority records that includes many created by catalogers at Vanderbilt. Today I ran into the use of the term “Men” instead of “Males” as $2 lcdgt
Class web shows both terms in lcdgt. Are both valid for the authority record field 375?
Any advice on what should be the ‘best practice’?
Mary Charles Lasater
Reading the definition of “best practice” in Wikipedia, I see that different best practices are applicable to different institutions. A wide variety of best practices for the optional RDA fields have already been developed, both formally and informally. I would like to summarize three levels.
1. Minimalist. The fields are optional, with the possible exception of the 046. (The date is a core element for personal names, and the current NACO training materials state that the 046 is required, but since RDA is not written in terms of tags, one could argue that the date in the 1XX and/or 670 would meet the core requirement). A strict minimalist approach would forbid use of the fields, to save time in both cataloging and training, and be done with it. At Duke, we are a little removed from this. We say that the fields will not be covered in training, but catalogers independent in NACO may use them. This is a fuzzy line, because the fields are actually emphasized in the latest version of the training materials. But I, as NACO coordinator and trainer, use only the 046 and do not train in any of the others. As Mary Charles Lasater pointed out, the new fields can significantly increase training time for NACO, which was already substantial.
2. Moderate. This is well described in the British Library Guide to Name Authority Records
BL practice: balance must be struck between fullness and efficiency, when deciding what to record at the element level. Record only those elements that are:
Expedient to record
Readily ascertainable: only do the amount of research needed to identify the entity, and to create and justify unique authorised and variant access points. Only include in 046/3XX fields appropriate data that has been discovered in the course of this research. Do not do extra research in order to complete additional 046/3XX fields.
Useful: be selective in recording data in 046/3XX fields. For example, only record significant dates in 3XX |s and |t. In 373, only record institutions with which a person has a significant connection. In 372 and 374, only record significant fields of activity and occupations. Any of these fields may be omitted if useful data is not readily ascertainable.
Expedient to record: only search the LCSH file briefly, for suitable terms. If a specific term is not available, use a broader term. If no term is readily ascertainable in a quick search, omit the field. Make full use of Aleph short keys and drop down menus to insert elements into the authority record.
3. The sky’s the limit. I have a couple of examples of ARs with optional fields that go beyond the purposes of authority control as outlined by Richard Moore when he started this thread: n 2010043877 and no2011152077.
Discussion thus far indicates that which level a library chooses must be more an attempt to forecast the future than a reflection of current needs. Of course, the amount of resources available also comes into play. This is the main reason that Duke has taken the minimalist approach.
Mary Charles Lasater mentions:
"A few ‘best practices’ might be useful. "
With which I wholeheartedly agree.
Locally, I have established a few "best practices." For example, we put extra effort into authority records for certain categories, such as entities affiliated with the University and special collections. Hence, I would include our institution in a 373 field for faculty authors. We have a special collection of women composers, so I include a 374 field for them, in the hope that someday (soon?) this field will enrich searching.
But, of course, more widely agreed upon best practices would make a lot more sense. We are all about cooperation, aren't we?
University of California, Davis
[log in to unmask]