Skip to content

LC call number normalization class number not being normalized correctly in certain cases #14

@jthomale

Description

@jthomale

Call numbers like this:

c 050 0 0 QA76.54.|bM87 2001

where the period for the cutter is part of the |a rather than the |b, are not being normalized correctly. Moving the period over into the |b fixes the problem, e.g.:

c 050 0 0 QA76.54|b.M87 2001

I think what's happening is, when call numbers are normalized, it tries to normalize the numeric portion of the LC class number based on what appears between the alphabetical portion and the end of the subfield. QA76.54 should become Q 0000000076.54. But with the extra period before the end of the subfield (QA76.54.), it thinks that portion of the call number is not a number and so it’s not zero-padding it like it otherwise would. So it's normalizing it to QA 76.54. instead.

This can be fixed by updating the call number in the bib record in the catalog, but I think the normalization routines should be forgiving enough not to have this issue.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions