Preferred term correction - correct coding when flipping LCSH to LCGFT
When a 655 field is coded for LCSH and matches a non-preferred term in LCGFT, Alma flips the heading to the preferred LCGFT term but does not update the coding (it should change the 2nd ind to 7 and add $2 lcgft).
The problem is limited to cases where:
A bib heading 655/_0 matches a non-preferred term in an LCGFT authority
What happens is:
The PTC job flips the heading to the LCGFT preferred form, but it does not change the 2nd-indicator from 0 to 7, and does not add $2lcgft
What is not a problem:
655/0 headings that already match preferred LCSH/LCGFT form
655/7, $2 lcgft (these get controlled appropriately)
655/7, $2 fast (these get controlled appropriately)
655/7, $2 any other vocab (these do not get controlled)
Example of the bug:
Before: 655/0 $a Dissertations, Academic
After: 655/0 $a Academic theses.
-
Laura Akerman commented
Agree with Steve McDonald. A job to match and convert LCSH in 655 to LCGFT if desired by the customer and if an appropriate match can be found, would need to change the vocabulary indications - this could be a desirable enhancement, but the current behavior is a bug. Keeping the vocabularies straight is crucial as we look toward linked data conversion
-
Steve McDonald commented
The problem, in my opinion, is that Preferred Term Correction should not be changing perfectly valid LCSH terms into LCGFT terms. LCSH should be validated against LCSH; LCGFT should be validated against LCGFT, and other vocabularies should be validated against their own authorities.