How can we improve Alma?

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.

35 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Corinna Baksik shared this idea  ·   ·  Admin →

2 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • 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.

Feedback and Knowledge Base