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.