|
Algorithm Logic for Master Record, Matching, and Action of MARC Load Program Based on 2/2/1998 "Recommendations of the UIAS Interim Task Force for Database Standards and Management" Recommendation 5: Master record identification logic. Input 000/17 Encoding level 008/39 Cataloging source 040/ac Original cataloging agency/Transcribing agency 042 exists Authentication code IF 000/17 is blank THEN BEGIN IF 008/39 is blank AND OR 040/a&c are both DLC THEN OUTPUT master record class 1 EXIT ELSE if 040/a&c are both GPO THEN OUTPUT master record class 2 EXIT ELSE if 040/a&c either are DLC or GPO THEN OUTPUT master record class 3 EXIT ELSE if 008/39 is a, b, or c THEN should these conditions output a master record class? EXIT? END END ELSE if 000/17 is I or K THEN (what about 1..8 ?) BEGIN IF (000/17 is I) AND (042 exists) THEN OUTPUT master record class 4 EXIT ELSE if 000/17 is I THEN OUTPUT master record class 5 EXIT ELSE if 000/17 is K THEN OUTPUT master record class 6 END END ELSE if 000/17 not I, K or blank THEN OUTPUT no master record EXIT END Bibliographic record elements IF multiple master records of same class exist THEN assign record element classes 1..6 to each master by checking for existence of 856 is eclass 1 505 is eclass 2 6xx second indicator of 1 is eclass 3 655 is eclass 4 520 is eclass 5 6xx second indicator of 2 is eclass 6 IF one record has a lower eclass and or has more lower eclasses THEN make this record the master EXIT ELSE if no record is different THEN check each cataloging update dates make the one with the latest date the master record IF still no difference THEN record on database is the master else use first record END EXIT END END I assume that in the event that multiple records exists from non-master candidates and no master exists, I should use the above bibliographic element comparison to merge and load a single non-master record.
Recommendation 4: Match point logic There are only two custom features to add to current matchpoint logic. One, require match on two indexes instead of the first hit one. Two, add custom match on first five characters of 245a. Recommendation 6: Master record source This is a good idea and more than likely will be a requirement for the maintenance program’s delete logic. My question is, will this be a consistent tag value or should the load program add this information to incoming records based on operator input of the source?
Action of maintenance load program: New or updated bibliographic and item records. Item records updated based on barcode match. In an over lay UIAS defines tags of target record to preserve. This is a normal feature in Horizon. IF match THEN BEGIN IF multiple matches THEN produce exception report for manual review, and load incoming as new record? or try to resolve master (the point is that in this case the records have already been processed a second pass will not help. In fact this case should not happen.) EXIT END evaluate record for deletion status IF true THEN EXIT END (see deletion algorithm) evaluate master class of existing match record evaluate master class of incoming record IF existing is master AND incoming is not master or is lesser master THEN load or update item records and attach to existing record with no overlay ELSE if existing is not master or is lesser master AND incoming is master THEN overlay existing record and insert or update item records. ELSE if existing and incoming neither are master records THEN preserve whichever record has the most and lowest number of bibliographic record elements or the latest update date. Add or update item records. END ELSE if no match THEN load new bib and item records. END
Deletion of item and bibliographic records. After much thought as to what would be required of existing systems record output to identify deleted item records I have come up with a proposal that seems the most viable for the various systems to support. This proposal is deletion by exclusion. If an incoming record no longer contains a given item record(s) based on barcode, incoming source, and matched bib number, the item(s) will be deleted. In the event that no items remain on the database the bibliographic record will be deleted. One exception I would assume is when the 000/05 is d then I would assume all items for this source location are to be deleted. This approach would require systems to be able to either purge deleted records or exclude them from output. An other approach would be to require item and or bibliographic records to be marked for deletion. Even if all systems are capable of providing record status’s, I think this would be more difficult to maintain. Although this would be much more simplistic programmatically to achieve. It may be the a combination of approaches will need to be applied. Obviously I would prefer a single approach. Exclusion approach If match THEN BEGIN same logic as that of new or updated record compare incoming item records to existing item records on the database IF item records for this record source exist in the database but not in the incoming record THEN this record is considered to be for deletion the items on the database excluded from incoming record are deleted when last attached item is deleted the bibliographic record is deleted END EXIT END ELSE if no match AND 000/05 is d THEN an exception report is output record is not loaded EXIT ELSE if no match AND 00/05 is not d THEN record is loaded as new record (the record status approach would produce an exception output here) EXIT END
|
|
|
Last Updated: February 12, 1998
|
