Following an authority control project, libraries receive several files of MARC format records. The primary file has all of the library’s bibliographic records, with corrections in place. Unless authority control is done during a system migration, records in this file are used to overlay the existing, pre-processed bibliographic records in their entirety, so that all revisions, however minor, are made to the database. Other files provided contain LC authority records that have linked to headings in the library's database during processing, written in the MARC-8 character set and formatted according to the MARC 21 Format for Authority Data. All existing authority records should be deleted from the library’s ILS prior to loading the new, comprehensive replacement authority records. In LC authority records, cross-references are always found on the “top level” authority record and not repeated on records with added subdivisions. Therefore, separate authority records are extracted, when available, for each level of a multi-level heading.
For example, three authority records would be extracted from the heading:
English poetry$yOld English, ca. 450-1100$xHistory and criticism.
English poetry$yOld English, ca. 450-1100
English poetry$yOld English, ca. 450-1100$xHistory and criticism
Authority record files always include name/series (LCN) and LC subjects (LCS). Additional files of records may be provided based on a library’s profile options: NLM MeSH authorities (LCM), LC Children’s authorities (LCJ), LCGFT (LCG), and Sears authority records (LCR). Some local systems require authority records for names used as subjects to be placed in the LCS file, which is easily accomplished using LTI options. In this case, about 30% of the subject authority records are likely to be for names and titles used as subjects (600/610/611/630 fields).
For databases up to 250,000 records, the library can expect to receive about one LC authority record (name or subject) per bibliographic record. The ratio of linked LC authority records to bibliographic records is inversely proportional to database size. For example, in a database of one-half million records the ratio is close to .65—i.e., .65 X 500,000 = 325,000 authority records. At above two million bibliographic records, the ratio stabilizes at about one authority record per two bibliographic records.
Special Options for Authority Records
In 2007, a project was undertaken at LC to generate and distribute “Subject Authority Records for Validation Purposes.” The project was to provide subject string authority records for popular and frequently-assigned headings, to assist local systems in validating LCSH subjects. These records are barebones, containing only the heading (taken from the LC bibliographic file) and a 667 field [nonpublic general note] that carries the text “Record generated for validation purposes.” To date these authority records are limited to: (a) 651 subject heading fields for country names followed by free-floating sub-divisions; and, (b) subdivisions found in Free-floating Subdivisions: an Alphabetical Index that appear after topical and geographic headings. This type of authority record may be useful in an ILS that requires an authority record for every controlled heading or for a library that lacks a comprehensive authority service such as AEX or AUP, which parse headings and validate floats. However their value to an individual library may be questionable as no library has exactly the same collection as LC, with only the subject heading strings used in the LC records. Because the original estimate of the number of these authority records ranged from several hundred thousand to a million, some LTI clients expressed concern about the number and utility of these validation records. In response, LTI added a profile option to exclude from library “LCS” files those subject authority records containing a 667 with the validation purposes note. This project appears to have stalled or been abandoned, as the number of these records plateaued some time ago at about 79,000.
LC authority records began to be enhanced by the addition of non-Latin cross-references in 4xx fields in 2008. Currently, about one-half million authority records contain non-Latin fields, with non-Latin fields now included routinely in new and updated authorities. Because not all local systems are able to handle non-Latin characters correctly, LTI offers clients the option to have the non-Latin 4XX fields removed from authority records provided to them by LTI.
"Deblinding" Authority Records
“Deblinding” usually refers to the removal of certain see also references (5XX) from authority records, preventing the occurrence of see also references when the see also from headings are not present in the catalog. For example, deblinding would prevent the see also reference Baked products see also Bread when there are no records with the heading Baked products but there are records with the heading Bread. Since the see also information may be helpful to patrons even when the see also from heading is not currently used in a catalog record, LTI retains all 5xx fields. Note also that, because of the dynamic nature of both bibliographic and authority files, the deletion of such a reference may prove problematic when the heading Baked products enters the bibliographic database at a future date.
The following summarizes a posting to the LTI-Users electronic mailing list and makes an excellent point:
"Blind references" in an online catalog do not result in wild-goose chases in the same way they might have in card catalogs. Take, for example, the reference "Ho, Ho see He, He". In a card catalog the user would have to flip through cards to find out what, if anything, was filed under "He, He." Some references would involve opening new drawers, and depending on the size of the catalog, covering a bit of ground. However, many online catalogs tell one right away what to expect, e.g., Ho, Ho see He, He (0 records). Even if the number of records does not display up-front, the correct form should only be a click away. Informing users what the authoritative heading is, and that there is nothing there, actually prevents wild-goose chases. This is especially true of subject headings, with their sometimes counter-intuitive forms.
After each LTI authority control job, libraries receive several standard reports. The Final Link Report details the number and percentage of name, series, and subject access points that have linked fully, linked partially, or not linked to either an LC or LTI authority record. The report shows: frequency of each controlled heading field tag, number and percentage of access points validated or not validated against an LC authority record, and number and percentage of access points changed in processing.
Two other reports are generated each time LTI authorizes a file of bibliographic records: the unlinked heading report listing headings in which $a could not be linked to an LC or LTI authority record, along with the frequency with which the heading was found in the file, and the “Non-Filing Indicator Change” report showing title fields in which a non-filing indicator was revised.
For the great majority of headings listed as “unlinked,” there is nothing “wrong” with these headings. There simply is no LC or LTI authority record established for the heading. Generally, systematic searching of unlinked headings in nationally distributed authority files is not a cost-effective choice, given the required time. Selected follow-up on high frequency unlinked headings or obvious anomalies may be of some benefit, but many libraries do nothing with this report.
Several optional reports may also be requested. “Partially Validated Headings” shows controlled headings where $a linked to an authority record, but one or more subsequent subfields could neither be linked to an authority record nor validated using float tables. Most of these entries are name/title combinations where the name was validated.
Optional 880 Reports
Bibliographic records with 880 fields containing alternate graphic representation data (non-Latin characters), present a challenge for authority control. While LTI does not authorize these headings, several optional processes can help with their management, using two reports, which incur no additional charge but must be specifically requested.
The “880-upd” report lists controlled headings that were changed during authorization but which show a linking field tagged as 880/$6. Each change is shown only when it happens. To assist library staff in making needed edits to the linked fields, the report includes: the bibliographic record control number, the tag and content of the controlled heading field before updating, tag and content of the revised field after updating, and the content of the linked 880 field that may require local revision.
The “880-err” report lists errors in links between 880s and their corresponding fields, such as bad parsing of $6 data or missing fields. The entry on the report will be eliminated when the record is corrected and re-sent to LTI, either in a new base bibliographic file or in an Authority Express (AEX) file. Each entry on the report includes: the bibliographic record control number, the tag and content of the controlled heading field with $6, the tag and content of the linked 880 field, and a brief explanation of the error found. Authority Update Processing (AUP) users will continue to receive reports of each error until it no longer exists in the copy of the database maintained at LTI.
When RDA was adopted as the national cataloging code, the format of certain types of date subfields ($d) in personal names was revised. To assist libraries with personal names in 880 fields, processing was enhanced to offer the option to revise the $d to match the form in the linked, authorized personal name field. When this option is chosen, a third report, called “880-sfd” is produced, listing each occurrence of this type of change. As with the previous reports on 880 data, the report lists: the bibliographic record control number, the tag and content of the controlled heading field, and a brief explanation of the change made.
All reports are provided as ASCII text, which can be loaded into a text editor or word processor for review purposes.