Principles for the Transition of the Authority Files to RDA

The category of 1XX fields that require review includes all pre-AACR2 headings, and AACR2-compatible headings 2.6 The migration of the LC/NACO authority file involves principally the re-

The LC/NACO Authority File and RDA

1 Definitions

1.1 Authority record: a MARC record in the LC/NACO authority file; a MARC record

whose 010 field contains subfield $a beginning "n"

1.2 RDA authority record: an authority record whose cataloging rules code (008 byte

10) has the value "z" and whose 040 field contains subfield $e with the value

"rda"

1.3 Non-RDA authority record: any authority record that is not an RDA authority

record

1.4 AACR2 authority record: an authority record whose cataloging rules code (008

byte 10) has the value "c" The category AACR2 authority record defined in this document explicitly excludes the category of AACR2-compatible authority

records—authority records with the value "d" in 008 byte 10.

1.5 Heading or access point: any 1XX, 4XX or 5XX field in an authority record An

AACR2 heading is a 1XX, 4XX or 5XX field in an AACR2 authority record, an RDA access point is a 1XX, 4XX or 5XX field in an RDA authority record, and so on.

1.6 The migration of the LC/NACO authority file is a set of automated changes to the

authority records in that file

2 Principles

General principles

2.1 With the exception of authority records whose 1XX fields that fall into one or

more of the categories identified in section 3.1 of this document, all 1XX fields in AACR2 authority records are deemed acceptable for initial use under RDA The 1XX fields in AACR2 authority records deemed acceptable for use under RDA maylater be changed only as described in section 2.12

2.2 The category of AACR2 headings acceptable for use under RDA includes headings

whose content is susceptible to one or more of the automated manipulations described in section 3.2 of this document

2.3 An AACR2 heading acceptable for use under RDA need not contain all possible

RDA elements RDA elements not present in the heading may be preserved in the authority record in suitable non-heading authority fields

2.4 AACR2 authority records whose 1XX fields are deemed acceptable for use under

RDA are to be re-coded by automated procedure as RDA records to reflect their status Section 3.3 of this document provides the specifications for this re-coding

2.5 There is no category of "RDA-compatible" AACR2 authority records The 1XX

fields in most AACR2 authority records can continue to be used in their current form (or after certain mechanical changes) under RDA All other 1XX fields must

be reviewed and upgraded before they can be used under RDA The category of 1XX fields that require review includes all pre-AACR2 headings, and AACR2-compatible headings

2.6 The migration of the LC/NACO authority file involves principally the re-coding of

AACR2 authority records with acceptable 1XX fields as RDA records The migration also involves changes to headings, and changes to authority data otherthan headings, in authority records of all types

2.7 The RDA 7XX fields added during and after the RDA test are not needed after the

migration These fields are handled as described in section 3.5

2.8 The authority file migration is an automated process; there will be no individual

review of headings An error rate of no more than 5% is an acceptable

consequence of the migration of the authority file The term error in this case refers not to purely mechanical errors (Oct should always become October and should never become Octagon) but to errors of commission.1

Before and after the migration

2.9 At all times, a PCC bibliographic record contains current authorized forms of

name as found in the LC/NACO authority file Before the authority file migration,

a PCC RDA bibliographic record may contain a mixture of established AACR2 headings and RDA preferred access points After the authority file migration, a newly-authorized PCC RDA bibliographic record may contain only RDA preferred access points Both before and after the migration, a non-RDA bibliographic record may contain headings created under any mixture of cataloging rules.2.10 Before the authority file migration, those AACR2 1XX fields deemed acceptable

for use under RDA (i.e., those that do not fit into any of the categories identified

1 For example, during the migration all occurrences of Dept in certain contexts will become Department.

The tasks force recognizes that a very few of the original AACR2 headings correctly contain the

abbreviation and not the full form; because these are in the distinct minority of all headings containing

Dept the task force believes it is better to change all occurrences of the abbreviation during the

migration, and allow for those very few that should contain the abbreviation to be considered errors and changed back as the headings come under later review.

in section 3.1) and that do not need any of the changes described in section 3.2

may be used as the base element in new AACR2 headings and new RDA access points (For example, an acceptable AACR2 100 field may be used as the base element in a new AACR2 or RDA name/title heading, and an acceptable AACR2

110 field may be used as the base element in an AACR2 heading or RDA access

point for a subordinate body; but a Bible heading that includes an abbreviation

for the New Testament cannot be used as the basis for an RDA access point until after the migration.) The cataloging rules code (008/10, and 040 $e when

applicable) in the new authority record for a heading that takes as its initial element or elements an acceptable AACR2 1XX heading, is the code for the rules used to formulate the element or elements added to the base heading

2.11 After the authority file migration, only RDA authority records may be added to

the LC/NACO authority file

2.12 The PCC policy on changes to authority 1XX fields applies both before and after

the migration At present, this policy holds that no change is to be made to an authority 1XX field that is not in error in a matter of fact and is not in conflict with other authority data A non-conflicting authority 1XX field is not to be changed simply because additional information becomes available—the new information may be preserved in suitable non-1XX authority variable fields This PCC policy is subject to modification by PCC as circumstances warrant

2.13 4XX fields in AACR2 authority records re-coded as RDA are to be considered

"evaluated" and need not be reviewed or revised unless found to be in conflict with other authority data

2.14 After the authority file migration, no new 7XX fields for RDA access points will be

added to LC/NACO authority records

3 Details

3.1 For the reasons stated in each of the following categories, certain AACR2 1XX

fields are not covered by section 2.1; authority records with 1XX fields in these categories cannot be re-coded by program as RDA After the authority file migration, AACR2 authority records whose 1XX fields fall into one of the categories listed here except the last (which involves deletion of the AACR2 authority record during the migration) must be re-evaluated individually, and their authority records re-coded as RDA, before they can be used in RDA bibliographic records

 Authority records whose 1XX fields represent ongoing conferences (Authority

records for one-time conferences may safely be re-coded as AACR2.) Appendix A outlines the techniques suggested by the task force for the identification of various categories of conference headings, and their handling during the authority file migration

 Authority records with 1XX fields that contain Polyglot in subfield $l2 The

designation Polyglot has no parallel under RDA.3 4XX fields that contain Polyglot

in subfield $l should be changed as encountered after the migration

 Authority records with 1XX fields that contain an ampersand ("&") in subfield $l Such authority records need to be replaced by a separate RDA authority record for each language Because of the difficulty in determining by program whether the second language in subfield $l represents the original language or the language of a second translation, appropriate new authority records cannot be created automatically; all such headings must be re-evaluated and replacement records created after the authority file migration.4 4XX fields that contain an ampersand in subfield $l may be changed as encountered after the migration

 Authority records whose 1XX field consists of an AACR2 1XX field excluded from the migration, plus additional subfields.5

 Authority records for personal names that contain subfield $c are handled as described in Appendix B; some such authority records are re-coded as RDA, and some are left as is for individual review

 Authority records to be deleted, and automatically replaced by new RDA

authority records (see section 3.4 of this document)

2 Here and elsewhere in this document, the specification of a text to be found in existing records should

be understood to cover all variations in casing of that text For example, the present rule covers the

texts Polyglot, polyglot, POLYGLOT and all other variations in casing When this document specifies a

replacement text ("January", "active"), the casing shown is the only acceptable form.

3 When authority records with such headings are encountered, the existing authority record should be deleted, and replaced by zero or more new records; each such new record should contain the original record's 010 $a in its 010 $z.

4 When authority records with such headings are encountered, the existing authority record should be deleted, and replaced by one or more new records; each such new record should contain the original record's 010 $a in its 010 $z.

5 For example, an AACR2 name/title authority record whose name portion is represented by an authority record coded AACR2-compatible is not to be re-coded as RDA The implication of this exception is that all authority records that are otherwise excluded from being re-coded as RDA headings must be

identified first; the 1XX fields in these records can be used to identify those AACR2 authority records whose 1XX fields contain excluded headings plus additional subfields.

3.2 Headings in non-RDA authority records (whether being re-coded as RDA, or not)

are subject to automated manipulation during the authority file migration.6 The changes described in section 3.2 do not in themselves entail any change to the cataloging rules code (008 byte 10), or to 040 subfield $e With two exceptions, changes described in this section apply equally to all 1XX, 4XX and 5XX fields in non-RDA authority records These two exceptions are: 4XX fields that contain a code other than "n" in byte 2 of subfield $w, and 4XX fields for vernacular forms

of name;7 these exceptional 4XX fields are to be carried forward into the updatedauthority record without change.If any change described in this section involves

an authority record's 1XX field, the original 1XX field will be preserved as a 4XX field, with the addition of subfield $w containing code "e" in byte 2, and the deletion of any existing 4XX field that has the same NACO comparison form as the modified 1XX field The instructions in section 3.2 do not specify adjustments

to punctuation and spacing that may be called for as a result of other changes

 In subfields $a and $b of X10 and X51 fields, in subfields $a and $e of X11 fields, and in parenthesized qualifiers of all subfields of X30 fields, replace the

abbreviations "Dept." and "Dépt." with "Department" and "Département", respectively.8

 In subfield $d of X00, X10 and X11 fields, replace the abbreviations "cent.",

"Jan.", "Feb.", "Mar.", "Apr.", "Jun.", "Jul.", "Aug.", "Sept.", "Oct.", "Nov." and

"Dec." with "century", "January", "February", "March", "April", "June", "July",

"August", "September", "October", "November" and "December", respectively.9

 In subfield $d of X00 fields, replace the abbreviations "ca." and "fl." with

"approximately" and "active", respectively

 As instructed in Appendix B, remove subfield $c from certain X00 fields

 Replace the abbreviation "b." at the beginning of subfield $d in X00 fields with a hyphen following the date in subfield $d.10

6 Headings in RDA authority records that appear to need the manipulations described in this section

have been modified as a side-product of the work of this task force Have they? See table in Appendix

C.

7 The task force used the following definition in its work: a vernacular form of name is any 4XX field

containing any Unicode character at code point U+0370 or higher, excepting code points U+FE20

through U+FE23 inclusive.

8 In rare cases the consistent usage of a corporate body involves the abbreviation, not the full form Such converted headings fall under the aegis of section 2.12 because they are incorrect in a matter of fact; as such headings are discovered, the full form should be replaced by the abbreviated form.

9 During the task group's investigations, some headings in the LC/NACO authority file were found to contain non-standard variant abbreviations for the names of months, and were corrected

10 See 5.8 for the task force's preferred replacements for "b." and "d.".

 Replace the abbreviation "d." at the beginning of subfield $d in X00 fields with a hyphen preceding all other text in subfield $d.

 Replace the abbreviation "arr." in subfield $o of X00, X10 and X11 fields with

"arranged"

 If subfield $t consists of "Selections" or "Selections.", or if subfield $t begins

"Selections (", change the subfield code of that subfield to $k and precede that subfield with subfield $t containing "Works."

 In X30 fields that contain "Bible" in subfield $a and where $a is immediately followed by an instance of subfield $p that contains "O.T." or "N.T": if the subfield $p for a testament is itself followed by a second occurrence of $p, delete the first subfield $p and its contents; if the subfield $p for a testament is not immediately followed by a second occurrence of subfield $p, replace the contents of this subfield $p with "Old Testament" or "New Testament", respectively

 In X30 fields that contain "Koran" in subfield $a, replace the text in subfield $a with "Quran"

3.3 Re-coding an AACR2 authority record as RDA involves the following steps:

 change 008 byte 10 from "c" to "z"

 add 040 $e with the text "rda"

 add a new 667 field containing this text in subfield $a: "Pre-RDA heading deemedacceptable for continued use under RDA"

3.4 If TG1 decides that AACR2 authority records for undifferentiated personal

names11 should be split into separate records, one for each entity, proceed as follows The work described here can only be applied to authority records for undifferentiated personal names that have the following characteristics: they contain at least two "[Author of" (etc.) statements, they contain no 670 fields before the first "[Author of" statement, and they contain no 667 field that contains the text "additional persons"; records that do not meet these tests must be reviewed individually and handled as appropriate

 Delete the existing authority record

 Create one new authority record for each "[Author of" (or equivalent)

statement Each new authority record will contain the original 010 $a in its 010

11 An authority record for an undifferentiated personal name is an authority record with value "b" in 008 byte 32 that contains a 100 field with only subfields $a, $b, $c, $d and $q.

$z, will have the value "b" in 008 byte 32, will contain one original "[Author of" field re-tagged as a 667 field, and will contain the 670 fields that follow its

"[Author of" (or equivalent) statement in the original record, up to but not including the next "[Author of" (or equivalent) statement Each such new

authority record will contain a copy of any 4XX, 5XX and 675 fields present in the original record The handling of other fields in the original authority record (for example: call number fields, 667 fields) remains to be determined The headings

in these new authority records are subject to the manipulations described in section 3.2; the new records are also subject to the manipulations described in sections 3.5 and 3.6

If instead TG1 recommends retaining authority records for undifferentiated names

as presently constituted (at least until some point after the authority file migration), AACR2 authority records for undifferentiated personal name headings will be

automatically re-coded as RDA authority records, or left for individual review recoding; the handling of these records will be determined by other characteristics present the records, as described elsewhere in this document

and-3.5 RDA access points contained in 7XX fields of non-RDA authority records will be

used in the following operations at the time of the authority file migration

 Find RDA authority records whose headings contain the text in the 7XX field plus additional subfields; replace the matching that text with the text from the authority record's 1XX field

 Replace access points in RDA bibliographic records that match the authority 7XX field with the text from the authority record's 1XX field

 If the authority record contains an RDA 700 field that contains subfield $q, and if that 700 field contains no subfields other than $a, $b, $c, $d or $q, and if the authority record does not already contain a 378 field, create a 378 field from subfield $q of the 700 field

 If the authority record contains an RDA 700 field that contains subfield $d, and if that 700 field contains no subfields other than $a, $b, $c, $d or $q, and if the authority record does not already contain an 046 field with subfield $f and/or $g,create an 046 field from subfield $d of the 700 field

 If the NACO comparison form of an RDA 7XX field does not match the NACO comparison form of an existing 1XX, 4XX or 5XX field in the authority record, create a 4XX field from the RDA 7XX field Do not include subfield $w in this 4XX field

 Delete the RDA 7XX field.

3.6 Make the following changes to any record in the LC/NACO authority file at the

time of the authority file migration, whether or not the authority record is being re-coded from AACR2 to RDA Such a change does not in itself entail any change

to the cataloging rules code (008 byte 10) or to 040 subfield $e

 If the 100 field contains subfield $q and no subfields other than $a, $b, $c, $d and $q, and if the authority record does not contain a 378 field, create a 378 field from 100 subfield $q

 If the 100 field contains subfield $d and no subfields other than $a, $b, $c, $d and $q, and if the authority record does not contain an 046 field with subfields $fand/or $g, create an 046 field from 100 subfield $d

4 Scheduling

4.1 The migration of data in the LC/NACO authority file described in this document

should be performed at the same time in all coordinated copies of the file The work of the migration may extend over more than one day; during the migration,the file should be closed to maintenance of any other type

4.2 The migration of the LC/NACO authority file should be timed in coordination

with the weekly issues of updates to that file; records updated during the migration should be included in a single weekly issue Because of the large number of updated records involved in the migration, the Library of Congress should consider re-issuing to subscribers a complete copy of the file as it exists atthe end of the migration

4.3 The migration of data in the LC/NACO authority file will take place in one or,

preferably two, phases The task force suggests that the migration be done in two phases, as described below, because authority records whose headings can

be used under RDA without change will be clearly labeled as a result of the work done in the first phase

If it is determined that the migration can only be done in a single phase, all of thework described in this document will be performed at once If the work can be done in two phases, the task force recommends the following contents for each phase:

 Phase 1: RDA 7XX fields should be treated as described in section 2.8, and the

667 field described in section 3.3 should be added to those RDA records

whose 1XX fields are not also susceptible to the manipulations described in

section 3.2

 Phase 2: all other work described in this document: the re-coding of acceptable AACR2 records as RDA, manipulations, and changes to other fields

4.4 The migration of data in the LC/NACO authority file (or, if the migration is

performed in two phases, the second phase) will be scheduled in appropriate relation to the national libraries' transition to RDA (i.e., not before Jan 1, 2013)

5 Additional recommendations

5.1 The changes described in section 3.2 should be made to headings in

bibliographic records at the same time as they are made to headings in authorityrecords.12

5.2 PCC should request that authority 008 byte 29 (reference tracing evaluation) be

made obsolete The task force does not believe that the information provided in this byte serves any useful function

5.3 PCC should develop guidelines for the use and structure of vernacular 4XX fields

in LC/NACO authority records, and encourage participants to apply those guidelines to existing vernacular 4XX fields

5.4 The LCPS concerning fullness of personal names should be replaced by a policy

statement (based in large part on the current LCRI 22.18) that calls for the addition of subfield $q in the following cases: 1) in case of conflict, 2) when subfield $a of the heading contains an abbreviation or initials, or 3) when the heading consists of a surname alone (whether or not followed by subfield $c) This policy statement should explicitly proscribe the use of subfield $q for namesnot otherwise present in the heading simply because those additional names are available

5.5 The PCC should, in coordination with the operators of large bibliographic

databases and the vendors of automated library systems, set a schedule for the implementation of the full Unicode character repertoire in bibliographic and authority records

12 Additional abbreviated forms (such as "Sep." instead of "Sept.") may be expected in those

bibliographic headings not supported by LC/NACO authority records.

5.6 The PCC should, in coordination with the operators of large bibliographic

databases and the vendors of automated library systems, set a schedule for the implementation of the non-filing zone markers (Unicode code points U+0098 andU+009C)

5.7 Validation routines for authority records submitted to the LC/NACO authority file

should enforce the following rules: code "z" in 008 byte 10 must be accompanied

by an acceptable value in 040 subfield $e; the presence of subfield $e in the 040 field requires code "z" in 008 byte 10 Enforcement of these validation rules (andother validation rules) should apply both to records contributed by operators and to records exchanged between copies of the authority file

5.8 An extremely limited number of AACR2 headings to be re-coded as RDA will be

found to be uncomfortable in the RDA world As is the case at present, there should be provision for LC's Policy and Standards Division or other suitable body

to change existing RDA authorized access points even with there is no conflict and the headings are not wrong in a matter of fact Such changed authority records should bear a 667 field describing the reason for the change, and name the authorizing body

5.9 Consideration should be given to a change to RDA so that the pre-RDA

abbreviations "b." and "d." in X00 subfield $d are replaced with "born" and

"died" instead of hyphens

5.10 The sense of the current LCRI 24.2D, expressing preference for a spelled-out

form for the name of a corporate name over the body's initials, should be

embodied in an LCPS