There are two mechanisms for processing records via File Transfer Protocol (FTP) currently in use by LC and its NACO partners. These mechanisms are used to facilitate participation in the NACO component of the Program for Cooperative Cataloging. This NACO FTP process is often referred to as the NACO "record exchange" process or as the NACO "contribution/distribution" process with the FTP partners often called "NACO nodes."
- Distribution recipients
- Note that before this option can take place interested parties must reach agreement with LC for testing, scheduling, coordination of changes to format elements, etc.
- Distribution recipients must hold a copy of the 8 million-record LC/NACO Name Authority File (NAF), and they must keep it current by loading daily NACO distribution files from LC's Cataloging Distribution Service (CDS).
- Distribution recipients must also retrieve and process daily response files that contain error messages that may pertain to records that were contributed to LC the previous day.
- Because distribution recipients hold current copies of the NAF, they can contribute updates as well as new records to the master NAF housed at the Library of Congress.
- Distribution recipients may also be known as "NAF copy holders", "full nodes", "NACO record exchange partners" or "participants in the LC (or NACO) distribution/contribution process."
- At present, there are three distribution recipients: OCLC, SkyRiver, and the British Library.
- Distribution recipients generate their own LCCNs, each
with a distinguishing prefix (i.e., n = LC; nb = BL; no =
OCLC; nr = RLG (no longer active, although nr records still reside in the NAF) ; ns = SkyRiver).
- Contribution-only sites
- A parameter of NACO participation is the ability to contribute via a "full node" (see no. 1 above). This option may be exercised only at LC's discretion and is not generally available to NACO participants.
- Contribution-only sites do not hold a copy of the 8 million-record NAF, but must have search access to a current copy of the NAF via a NACO distribution recipient (cf. no. 1 above).
- Contribution-only sites can only contribute new records (i.e., MARC 21 Authority Format Leader/05 of "n" (Record status).
- Contribution-only sites cannot contribute updates to the NAF (Record status = c,a,d,s,x).
- Contribution-only nodes use pre-assigned LC numbers (i.e., prefix = "n" only).
- There is currently one contribution-only node: National Library of Medicine.
In the beginning of the Linked Systems Project (LSP), 1985-1995, the Record Transfer Protocol was used to exchange name authority records. RLG and OCLC would connect with LC's server and retrieve authority records hourly (usually loading them that evening); LC would gather contribution authority records every four hours and load them immediately into MUMS.
Upon migration to the File Transfer Protocol (FTP), January 12, 1995, the schedule
for loading the files was changed to incorporate an additional 24-hour difference.
Instead of retrieving distribution records throughout the day and loading
them that evening, distribution recipients now retrieve a single file (via
FTP) the following morning. That file contains all records that were created,
updated, loaded, or deleted in the LC system during the previous day. In
addition, each day LC retrieves a single contribution file from each distribution
recipient and processes the files immediately. These files contain both newly
created and changed name authority records.
Note that subject authority records are not part of this process.
This is a simplified picture of the contribution/distribution process.
These contribution files are retrieved by LC each morning via FTP, which means that records created in the bibliographic utilities by NACO libraries on a Monday are put in a queue and delivered to LC on Tuesday morning. The files are then split into two smaller distinct files: one for new name authority records and another for changed name authority records. The new records are bulk imported into the LC Database using a duplicate detection profile to ensure that LC Control Numbers (010 fields) are not duplicated. The changed records are processed and bulk imported to merge with existing records if the 005 field on the incoming records also matches the 005 field on the record in the database.
In order to insure version control of records loaded into the LC master file a program check is set on the MARC 21 005 field (Date and time of latest transaction). The 005 field contains the date and time (down to a tenth of a second) of the latest transaction, it ensures that the change coming into the database has used the latest version of the record in the master copy of the name authority file at LC. This assures that no information is lost because an earlier version of a record will not replace a later version of the same record.
From 1985 to August 1999, LC's automation office handled NACO distribution. Distribution files were created circa 1:30 am and contained all versions of update records. For example, if a record was updated six times during the previous 24-hour period, all six copies were in the distribution queue and distributed to the master-copy holders. Since LC implemented its integrated library system (LC-ILS) in August 1999, CDS has handled NACO distribution. CDS files are deduped (based on the information found in the 005) and as a result only the latest version of a record updated multiple times is distributed. The number of errors involving unequal 005 field (known as "C2" errors) has increased only slightly since FTP became the record exchange protocol. When NACO participants receive notices of this type of error, they must apply their changes to the updated record which has recently been loaded by the distribution recipient.
Once contribution file records are loaded into the LC Database they become part of the master copy of the LC NAF. This means that all NACO contributed records together with the LC-generated records may now be distributed to all distribution recipients. To do this LC creates a distribution file that contains all name authority transactions for an entire day. The distribution file, normally created before 8:00 am each day, is retrieved by all three distribution recipients via FTP and loaded before the following morning. This means that contribution records created on Monday are loaded into the LC Database on Tuesday, distributed on Wednesday, and generally loaded by the distribution recipients before Thursday morning.