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.
Corinna Baksik
shared this idea
-
Kevin Burke
commented
I agree that this issue needs attention. The ability to link to LCGFT authorities when coded for LCSH also creates confusion for terms that are present in both (e.g., "Periodicals").
I believe the root cause of this problem is that there are two sets of LCGFT authorities in the Community Zone: one correctly identified as members of LCGFT and one identified as LCSH. See, for example, gf2014026986 (screenshot attached). I opened a ticket with Ex Libris and the response I got was "When LOC authorities were added to the Alma CZ after discussions with customers, it was identified that some institutions use genre authorities as LC subjects, while others use them as Genre. As a result, it was decided to include these authorities in both vocabularies."
I've had feedback from some colleagues that their institutions may have mixed application of LCSH/LCGFT due to historical practices, but I agree that the vocabularies should be handled separately. I would rather see misapplication of the vocabularies treated as the outlier, not the other way around.
-
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.
