UPD Y Implementation

From ILS

Jump to: navigation, search



Aleph includes a function to automatically update a bibliographic heading from a linked authority record heading. When the authorized form of a heading (name, series title, subject) changes in an authority record, the change is automatically reflected in the linked bib record, with the bib heading changed to match the authority heading. This saves library staff time on manual maintenance and keeps the bib data consistent across the board. This function is turned on at the level of the authority record. If the authority contains the field UPD $a Y (or if there is no UPD field), automatic updating is turned on. If the authority record contains UPD $a N, the automatic updating is not turned on. UPD Y implementation is a project to turn on the automatic updating for the SUS.

Automatic updating has been turned on for the FCS Aleph for some time but not for the SUS. The situation is a little more complex for the SUS. The SUS bibs in UXU01 link to resource authority files containing the full Library of Congress authority file (LCA10) and the full National Library of Medicine MeSH file (MSH12). LCA10 contains over 9 million records and is maintained through weekly batch loads. Implementing UPD Y is occurring in stages so that the impact on the system can be monitored.

How UPD Y works

The authority records are loaded into separate Aleph libraries from bibliographic records. The association between authorities and bibs occurs at the heading index level. An Aleph configuration table specifies which bib heading indexes link to authorities. Additional tables specify details about which headings in these indexes link to which headings in the authorities. Aleph processes compare terms in the bib heading indexes against terms in a specific authority index called the GEN index. If the normalized form of Term A in a bib index matches the normalized form of Term B in the authority GEN index, Aleph goes on to check if capitalization, punctuation and other characteriscs of the headings agree. If they do, Term A links to Term B. This is true regardless of whether UPD Y is turned on in the authority.

When an authority is updated, a message is sent from the authority library to the bib library to recheck any linked bib heading(s). If the authority contains UPD $a N, the bib heading relinks to the authority but doesn't change to match the authority's authorized form (the 1xx). It the authority contains UPD $a Y (or no UPD field at all), the bib heading is flipped to match the authority's 1xx. Bib headings that are flipped are those that link to a "see" cross reference (a 4xx field) or the previous form of the 1xx (a COR field) in the authority. Bib headings are not flipped if they match a "see also" cross reference (a 5xx).

The background linking process also sends the bib to indexing. A bib heading isn't flipped to match an authority 1xx until the bib is reindexed. This way the revised bib heading is indexed right away and the bib can be found by a search on the revised heading.

Exceptions to UPD Y

There are some conditions under which automatic updating of bib headings is not a good idea. Most are situations where a person needs to review a change. Examples of these exceptions to turning on UPD Y:

  • one topical subject heading is replaced by two new ones
    • Cards split into Playing Cards and Tarot Cards (a person needs to check which kind of cards a particular item covers before updating the heading)
  • an open historical period for a country is turned into a historical period with an end date and a new, succeeding historical period is opened
    • Chad--History--1960- is changed to Chad--History-1960-1990 and Chad--History-1990- (a person needs to check the time period a particular item covers before updating the heading)
  • a bib tag or subfield is changed to an incorrect value as a result of UPD Y

This Google spreadsheet of Exceptions to UPD Y documents the conditions under which UPD Y is not turned on in an authority record. This Google doc summarizes the review of the small series test.

If an authority record meets at least one of the exception conditions, UPD $a N is added to the record. A tickler beginning "UPDN" followed by a code for the exception is also added for each exception the record meets.

UPDN151-410 -- record contains a 151 and a 410; don’t want 110, 710’s in bibs flipped to 151 or 751.
UPDNi -- record contains 510 or 511 with “$i Predecessor” or “$i Successor”; or contains 530 with “$i Preceded by” or “$i Succeeded by”
UPDNv – record contains 1xx with $v
UPDNw – records contains 510 or 511 or 530 with “$w a” or “$w b”
UPDNy – record contains 1xx with $y

Use the TKR or WTK index in LCA10 to find the authority records with one or more of these exception conditions.

Project phases

The UPD Y implementation has three separate sub-projects for subjects; series and uniform titles; and names. There is a further subdivision into UPD Y for the current weekly LC updates and going forward, and for the retrospective implementation for records already loaded into Aleph. Here's the current status.

  1. UPD Y for subjects
    1. in production: weekly LC update file loads beginning with 1409 (2014 week 9) on 3/13/14
    2. in production: retrospective implementation, beginning with 2014 week 8 on 7/11/14 and working backwards
  2. UPD Y for series/uniform titles
    1. in test: weekly LC update file load test 1 on 7/1/14
    2. in test: weekly LC update file load test 2 on 7/23/14
    3. in test: weekly LC update file load test 3 on 8/20/14
    4. in production: weekly LC update file loads beginning with 1434 (2014 week 34) on 9/10/14
    5. in production: retrospective implementation, beginning with 1433 (2014 week 33) on 9/19/14 and working backwards
  3. UPD Y for names:
    1. in test: preliminary testing with a sample of name records: 7/17/14
    2. in test: weekly LC update file load test 1 on 7/23/14
    3. in test: weekly LC update file load test 2 on 8/21/14
    4. in production: weekly LC update file loads beginning with 1436 (2014 week 36) on 9/18/14
    5. in production: retrospective implementation, beginning with 1435 (2014 week 35) on 9/19/14 and working backwards

For the retrospective implementation of UPD Y, only the initial startup is part of this project. The ongoing work of turning on UPD Y in the older records is considered ongoing maintenance. Progress is tracked in the Google spreadsheet Retrospective UPD Y in LCA10

Personal tools