LC filing routine sorts volume numbers incorrectly

• Article Type: General
• Product: Aleph
• Product Version: 18.01

Description:
We have an LC call number index which uses our tab_filing routine 22:

22 F del_subfield
22 F to_lower
22 F lc_call_no

The filing is not handling volume numbers correctly.

If you do an LC call number search for BR60.C3, you'll see that the volumes file as: v.1, v.10, v.11, v.12....v.2, v.20, v.21...v.3, v.30, etc.
How can we get the LC call number index to file vol. numbers as whole numbers?

Resolution:
The problem is that the LC call number has 3 kinds of numbers:

1. the numeric part of the class number
2. the Cutter number(s), and
3. (sometimes) a volume number.

#1 is a whole number; #2 is a decimal number; and #3 is a whole number. Example: Z7164.N3.L34 no. 9 : 7164 whole; 3 decimal; 34 decimal; 9 whole .

The lc_call_no routine locates the numbers which constitute the numeric part of the class number and inserts a ! " or # to make one number file before 2 numbers, two numbers file before 3 numbers, and three numbers before 4 numbers. It doesn't do anything with the other numbers in the call number beyond the class number.

What is required is an algorithm to determine that we have come to a volume number, which needs to be treated as a whole number. We *could* look for certain strings ("v.", "vol.", "no.", etc.), which would inevitably be imperfect, but is probably the most practical thing to do. I think we could approach 90% accuracy using this method. I think the programming for this would not be difficult -- but it would probably be considered an enhancement request.

(Note: If *all* the numbers were whole numbers, then one could simply use an expand_num-type routine -- but that is not the case. This *is* the solution we suggest for volume numbers in other, non-call-number headings.)