- Article Type: General
- Product: Aleph
- Product Version: 16.02
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
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
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.
- Article last edited: 10/8/2013