Library of Congress FOLIO Migration: FAQ for OCLC NACO Users

WHAT’S NEW

1. All new and/or modified MARC fields and subfields in the authority format will now be available for use, following the LC Guidelines. DCM Z1 and the LC Guidelines will be updated around the end of August to reflect the new fields and subfields that are now available.
2. All 375 fields in personal name records have been removed. Please note that if anyone adds a 375 to a name authority will have their record rejected through the validation process of distribution.
3. Full Unicode implementation is now possible. The PCC Policy Committee is in the process of looking at the policy changes that are now possible due to this system change. In other words, don't suddenly start adding any and all scripts! All current policies regarding characters and scripts remain in effect. But the technical barrier to changing the policies is now gone. As decisions are made on what changes NACO wishes to implement, NACO will make announcements and update the documentation as quickly as possible.
4. Batch changes to family name NARs to allow them to be used as access points will now be considerably easier and should happen shortly after the restart.
5. All RDA-eligible AACR2 NACO records have been converted to RDA (i.e.,008/10=z; 040 $e rda).

CHARACTER ENCODING POLICIES AND SETTINGS

Character Input Guidelines

For NACO contributors: Continue using decomposed characters (letter + separate diacritic) rather than precomposed Unicode characters until the PCC establishes official policy.

Best practices:

• Use only characters available on your standard keyboard
• Add diacritics and special characters using OCLC Connexion's "Enter Diacritics and Special Characters" feature
• When copying from online resources, convert any precomposed characters and smart quotes to their decomposed equivalents
• Avoid copying and pasting special characters directly from web sources

Export Settings Configuration

Recommended setting: Set Export → Record Characteristics to UTF-8 Unicode (rather than MARC-8)

When UTF-8 is ideal:

• Exporting to files for use with MarcEdit or similar tools
• Working with systems that handle UTF-8 encoding
• Need flexibility to re-encode records later (UTF-8 files can be converted to MARC-8 using external tools)

When MARC-8 may be necessary:

• Your local system requires MARC-8 encoding
• Records are imported directly (not via file export)
• Your system cannot handle UTF-8

Important Considerations

• UTF-8 advantages: Better compatibility with modern systems and allows for re-encoding flexibility through external tools.
• MARC-8 limitations: Some records containing non-MARC-8-compatible characters may display corrupted or unusual characters, with no available workaround since LC is transitioning to UTF-8 without guaranteeing MARC-8 compatibility.
• Bottom line: UTF-8 is generally recommended for its flexibility and future compatibility, unless your local system specifically requires direct MARC-8 import.

OCLC CONNEXION DISPLAY

In Connexion client, some CJK characters may display as individual radicals or syllable components rather than as composed characters. As long as the characters you enter have the appropriate Unicode codepoints, this display difference should not affect functionality.

Note the Connexion 400s are completely decomposed and spaced out. The 2.63 version's 670s also look completely different from 3.1's, even though the characters are the same behind the scenes.

KNOWN ISSUE: DUPLICATE AUTHORITY RECORDS WITH SAME LCCN

OCLC has been made aware of a rare situation that occurred with at least one name authority record distributed from LC to OCLC. As you know, the authority record you see in Connexion and Record Manager is a copy of the authority record housed by the Library of Congress. Every day, OCLC processes a file from LC to synchronize our copy of the authority file with LC’s. LC also processes a file from OCLC and other NACO nodes to incorporate changes made by NACO participants. This process is described in a somewhat dated fashion here: https://www.loc.gov/aba/pcc/naco/nodes.html. Occasionally, instead of replacing the authority record, we end up with two versions of the same record. This is why you are seeing two authority records with different timestamps and the same LCCN. If you look at the LC authority record in their database you will see the correct version of the record: https://lccn.loc.gov/no2020000021  .

We need to delete the incorrect copy of the authority record in OCLC’s database, so you see only the correct one with the 2025 timestamp. Please report these authority records to askqc@oclc.org and provide the following information:

1. The LCCN of the authority record
2. A description or screenshot of what you are seeing
3. Which OCLC application you are using (e.g., Connexion 2.63, Connexion 3.0, or Record Manager)

Example:

#1

LDR  nzn
001  oca12667562
008  200101nc azannaabn          ∎b aaa     c
005  20200103073010.0
010  no2020000021
040  HkU ǂb eng ǂe rda ǂc HkU
046  ǂf 1989 ǂ2 edtf
100 1 Duan, Lei, ǂd 1989-

#2

LDR  nzn
001  oca13024952
008  200101nc azannaabn          ∎b aaa     c
005  20250804171813.9
010  no2020000021
040  HkU ǂb eng ǂe rda ǂc HkU
046  ǂf 1989 ǂ2 edtf
100 1 Duan, Lei, ǂd 1989-

In the meantime, if you need to use the heading in a bibliographic record, simply control the heading as usual.

Note that this only applies to duplicate authority records with the same LCCN. When you encounter duplicate authority records with different LCCNs for the entity, the usual procedures apply. NACO members should report these to LC, and non-NACO members should report these to authfile@oclc.org.