Union catalog matching and preferred records

• Article Type: General
• Product: Aleph
• Product Version: 16.02

Description:
Problems with the Union catalog (technically, Union View):

1) merging records of items in different formats
2) merging records for completely different items
3) attaching libraries holdings to the wrong bibliographic records
4) multiply listing items

Resolution:
The union programs look for matching bib records and point the z120 of a matching, non-preferred record to the z120 of the preferred record.

$alephe_tab/union_global_param specifies that ABC01 is using union_candidate_cdl, union_match_cdl, and union_preferred_cdl.

The union_candidate_cdl is coded to look at the following indexes in finding matches: 010, 020, 022, and NTL (normalized title, a Word index).

The union_match_cdl mongraph program compares the 008, 010, 020, and 245 fields in deciding on a match.

The union_match_cdl serials program compares the 010, 022, 245, 008, and 260 fields in deciding on a match.

The problem I see with this is that none of these consider the 035 field which, for your consortium's data, is the best match point.

SDLN is using the routines union_candidate_sdln and union_match_sdln. These routines *do* include the 035 in their logic. They look at a "PNO" IND Direct index which is built from the 035 field (the number-part only). (I see that you do have this PNO index defined and populated.)

This can be tested as follows:

1. Make a test change to the candidate and match lines in union_global_param. Change the lines with "T" in column 2 to sdln:

xxxnn T candidate_prog union_candidate_sdln
100
xxxnn T match_prog union_match_sdln

2. restart ue_01

3. resend all of the records in each described group of problem records to the server to see if their z120 match-and-preferred records are built correctly when this change is in place

3. if so, rerun p_union_01 and p_union_02 to recreate the z120.

4. if not, use util f/1/21 to diagnose the problem.