Authority Control in Voyager

This paper was given as part of the Technical Services Roundtable at the 2003 meeting of the Music Library Association.

Q. Does your system "have" authority control?

A. Yes.

Q. Does it hold authority records--how?

A. Authority records are held in a separate table. As far as links go, if you update a 1XX in an authority record, the system doesn't automatically update all bibliographic records with that heading, but does put them in the "global heading change queue." The headings are then changed manually.

Q. From whom do you get authority records?

A. We can get authority records one of two ways. First, as part of the MARS authority control processing, OCLC provides us with authority records, including those we created or updated.

An authority record can also be imported from either OCLC or RLIN if the cataloger feels it is needed immediately in the catalog.

We maintain the entire Library of Congress authority file in separate region of our catalog and could also import authority records from there. Currently, however, there is a bug in Voyager that doesn't allow us to import and overlay authority records from the local resource file. We can't correctly define the merge profile because lower-case letters in MARC institutional codes, like the small "t" in CtY, are not recognized. Therefore we have to go to OCLC or RLIN.

We decided not to create any new local authority records, but have kept those created in the old system for which there are no matching national-level records. Voyagers matches incoming authority records on the 010 field. This means when a national-level authority record is created for a heading for which Yale has a locally-created record, Voyager will not match it, since the local record will not have a 010 field. The local record needs to be deleted manually.

Q. How frequently do you get authority updates (new and revised authority records)?

A. We get new and updated authority records from OCLC on a monthly basis. Whether they are loaded into the system in a timely fashion is an issue unrelated to either OCLC or Voyager.

Q. How do locally-created edits get processed into incoming records?

A. Local modifications to national-level records are overlaid when the record is imported or loaded from OCLC. The exceptions to this are the 644 and 646 fields for local analysis and classification decisions in series authority records, the 090 field for call number in any authority record, and any 690 field. It is Yale policy to not include information that applies locally to any other type of authority record and to update authority records only at the national level, thereby avoiding the problem of losing information.

Public Mode

Q. Do cross references display in public mode? Yes.

A. We have found that even when a heading appears only in suppressed bib record, cross references are still generated in the OPAC.

Q. Does it display authority records, or selected fields from them, to the public?

A. No.

Q. Does it redirect searches without requiring retyping the query?

A. Yes.

Q. Automatically, or at user's command?

A. At user's command.

Staff Mode

Q. Can staff replace an unauthorized form with the authorized form in staff mode?

A. Yes. When saving a record to the database, Voyager checks most headings against the local authority file (not the complete LC authority file in the LC region). Untraced series (490 _0) and local subject headings (690s) are not validated.

A dialog box displays with the headings checked that are checked. See example 1 in your handout.

The dialog box tells you the type of heading, the field it is in, the actual heading, and a "near heading." If the actual and near headings match, the validation column says "Heading Validated." Example 1 includes headings that were all validated.

Example 1: headings validated in staff mode

Example 2 shows what displays if the heading in the bib record matches a see reference in an authority record. Unfortunately, the heading in the "near heading" column is not the established heading, but the reference in the authority record to which it matched. You must open the authority record to get the correct heading.

Example 2: heading is a see reference in the authority record

If there are some differences, the message is "Heading Validated- Cosmetic Differences." These differences might just be the difference between the heading in a 700/‡t or 100/240 in the bib record and in a 100/‡t in the authority record, as in example 3.

Example 3: headings validated with differences in MARC tagging

These differences might also include the presence or absence of diacritics, as in example 4. Or it could mean the subfield coding, which not invalid, doesn't match that of the authority record.

Example 4: headings validated with differences in diacritics

It is possible to save a record to the database with the incorrect form of heading. It is also possible, if you know how, to turn off heading validation altogether. This is not current policy at Yale.

Q. Does it automatically change unauthorized forms to authorized forms? Immediately, overnight (time frame)

A. No. It must be changed by a human using good old copy and paste technology.

I have a few remarks about heading validation in Voyager. As I mentioned before, it doesn't validate all headings, specifically the 490 _0, which means untraced series are not checked to make sure that is the correct tracing decision.

The categories of what gets validated is rigid. You cannot limit it to just one category of heading (say, only subject headings). We have a fast cat unit that only checks series- for the tracing decision- and they cannot limit heading validation to only series.

The validation process doesn't take tag into account. In example 5, there are two series headings being checked. The first is correct and Voyager correctly matched it to the series authority record. The second series is incorrect- it lacks the qualifier. Voyager matched it to a name/title authority record and indicated that the heading was validated.

Example 5: the validation process ignores tag. Both series headings validated; the first matches a series authority record; the second matches a name/title authority record

You search a series as a "staff title heading" but a name/title series heading has to be searched as a "staff name/title heading" search.

Q. How are questionable situations handled?

A. We rely on MARS reports for a lot of questionable situations

Q. What fields?

A. For example, with an authority record with ‡a and ‡z in the 010, we use MARS reports to identify and delete the canceled record and must manual update any headings that need to be changed. We are currently working with MARS to get reports that we can load into Voyager to automatically delete the canceled records.

Q. What about uniform titles?

A. As seen in the examples 6 and 7, Voyager checks for both uniform titles (130 and 730) and name/uniform title headings (100/240 and 700/‡t).

Example 6: uniform title validated

Example 7: name/uniform title heading validated

With Voyager directly out of the box, you cannot search a heading used as a main or added entry and as a subject heading simultaneously. This requires two searches: a staff heading search and a staff subject search. Example 8 is an example of re-searching the identical heading.

Example 8: name/uniform title heading used as subject heading validated. Requires different search than when used as main or added entry.

Yale has customized one of the indexes so that we can now search a name/title heading as both. The drawback to this is that we couldn't make so that the "simultaneous search" retrieved authority records as well as bibliographic records.

It is possible to search a uniform title without searching it as part of a name/uniform title search, such as searching the title "Sonaten und Partiten violin BWV 1001-1006" and retrieve all uniform titles, even those with additional elements. At Yale, this won't retrieve that title found in ‡t of a 600 field, because of the compromise made with the reference people about what indexes in subject headings in the OPAC. This still requires two searches.