Skip to main content
ExLibris

Knowledge Assistant

BETA
 
  • Subscribe by RSS
  • Back
    Aleph

     

    Ex Libris Knowledge Center
    1. Search site
      Go back to previous article
      1. Sign in
        • Sign in
        • Forgot password
    1. Home
    2. Aleph
    3. Knowledge Articles
    4. LC filing routine sorts volume numbers incorrectly

    LC filing routine sorts volume numbers incorrectly

    1. Last updated
    2. Save as PDF
    3. Share
      1. Share
      2. Tweet
      3. Share
    1. Additional Information
    • 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.)

    Additional Information

    LC call number index, volume numbers, sort


    • Article last edited: 10/8/2013
    View article in the Exlibris Knowledge Center
    1. Back to top
      • LC_CTYPE=en_US.UTF-8: Command not found."
      • LC z39.50: "search failed at opac rc=1"
    • Was this article helpful?

    Recommended articles

    1. Article type
      Topic
      Language
      English
      Product
      Aleph
    2. Tags
      1. 18.01
      2. contype:kba
      3. Prod:Aleph
      4. Type:General
    1. © Copyright 2025 Ex Libris Knowledge Center
    2. Powered by CXone Expert ®
    • Term of Use
    • Privacy Policy
    • Contact Us
    2025 Ex Libris. All rights reserved