search

libraryhackers / library-callnumber-lc

Perl and Python modules for normalizing Library of Congress call numbers
30 stars 2 forks source link

LC Callnumber normalization for sorting incorrect #8

Closed gmcharlt closed 8 years ago

gmcharlt commented 9 years ago

Original issue 8 created by gmcharlt on 2015-01-07T15:25:14.000Z:

It appears that LC Callnumber sort normalization is not quite correct.

The issue is that cutter numbers are sorted decimally, and as such we need to pad out the numbers with 0's to make them sort correctly.

For example: take this two callnumbers that have been normalized:

PS3561.I4 A3 => PS3561 I4 A3 PS3561.I48 O5 => PS3561 I48 O5

These will sort incorrectly, as the second callnumber will be first for an alphanumeric sort, but should be last when sorted by LCC rules.

They should be:

PS3561.I4 A3 => PS3561 I40 A3 PS3561.I48 O5 => PS3561 I48 O5

in order to preserve the correct sort order. In fact, we will need to pad out both cutters since they are actually decimal numbers ( .4 and .48 respectively ). Is there any reasonable limit to the length of a cutter number? That is, what's the longest one you've seen ever?

Here's the same callnumbers with the cutters padded to 10 digits:

PS3561.I4 A3 => PS3561 I4000000000 A3 PS3561.I48 O5 => PS3561 I4800000000 O5

I cannot imagine anything going beyond 10 digits.

The following diff fixes the issue ( I believe ):

--- /usr/local/share/perl/5.10.1/Library/CallNumber/LC.pm 2015-01-07 10:21:20.000000000 -0500 +++ /usr/local/share/perl/5.10.1/Library/CallNumber/LC.pm.new 2015-01-07 10:21:06.000000000 -0500 @@ -275,6 +275,11 @@

my ($alpha, $num, $dec, $othernum, $c1dec, $c1alpha, $c1num, $c2alpha, $c2num, $c3alpha, $c3num, $extra) = ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12);

gmcharlt commented 9 years ago

Comment #1 originally posted by gmcharlt on 2015-03-06T20:44:31.000Z:

A blank sorts before digits in any character encoding I can think of. Thus, "4 " should sort before "48", in the correct shelflist order for your example above. Is there a character encoding for which it is not true that blank sorts before any digit?

hektech commented 8 years ago

I believe this question originated elsewhere and was carried over here (not originally asked by Galen).

As Galen points out in his comment, the presence of blanks in the normalized version should cause it sort correctly. In any odd system where blank does not sort before letters/digits, you can also specify a "topper" character, i.e. a character which the system will sort before any "real" character in the call number. Closing this issue.