Doorgaan naar de website
OCLC Support

How call number sorting works in WMS

  1. Laatst bijgewerkt
  2. Opslaan als pdf

Understanding call number sort order in WMS

To ensure that browsing by call number closely mirrors the physical arrangement of materials on your shelves, WMS does not simply sort call numbers alphabetically. Instead, the system evaluates the call number string, matches it to a known classification pattern, and applies specific normalization and sorting rules. 

To illustrate how this works, imagine a library shelf-reading a section of Computer Science books. The system categorizes call numbers into three primary patterns: 

  1. Library of Congress (LC) Pattern: The system identifies this pattern when the call number contains 1 to 3 letters, up to 4 digits, an optional decimal extension (up to 3 digits), and subsequent cutter segments.  
    1. Example: QA76.3 .A12 perfectly matches this pattern. The system recognizes QA as the letters, 76 as the digits, .3 as the decimal extension, and .A12 as the cutter. It will sort this item using standard LC logic. 
  2. Dewey Pattern: The system identifies this pattern when the string begins with digits followed by a decimal. 
  3. General/Fallback Pattern: If a call number does not match the strict structural rules of the LC or Dewey patterns, it is processed using a fallback method. The system strips out spaces and special characters and performs a standard alphanumeric sort. 

Common Reasons for Unexpected Sorting 

If you notice items sorting unexpectedly in a Call Number Browse or in Digby, it is usually because a call number was processed using the General/Fallback pattern rather than the expected LC or Dewey pattern. Using our Computer Science collection as an example, here is why an item might fall out of expected shelf order: 

  • Subfield mapping: The sorting logic relies on call number components being properly distributed across the appropriate MARC subfields.  
    • Issue: If a cataloger places the entire call number string (QA76.3 .A12) into a single subfield (such as subfield $h), the system may fail to parse the cutter correctly.  
    • Result: Because it cannot identify the pattern, the system sends the call number to the General/Fallback bucket. It will sort alphanumerically, potentially placing it out of sequence with identical call numbers that were properly split between the classification number ($h) and the item part/cutter ($i). 
  • Extended decimal classes: In the LC pattern, the system currently supports a maximum of 3 digits after the class decimal.  
    • Issue: Suppose you have a highly specific work cataloged as QA76.3155 .B45. Because the decimal extension (.3155) contains 4 digits, it exceeds the supported LC pattern limit. 
    • Result: The system will not recognize it as an LC pattern and will sort it using the General/Fallback rules, causing it to appear out of order relative to QA76.315 and QA76.316. 
  • Ordinals treated as text: Currently, ordinals in call numbers (such as edition numbers or conference years) are evaluated as text strings rather than numeric values.  
    • Issue: If you have two conference proceedings cataloged as QA76.3 .A12 92nd and QA76.3 .A12 101st, the system evaluates the first character of the ordinal.  
    • Result: Because the character "1" precedes "9" alphanumerically, the system will incorrectly sort the 101st edition before the 92nd edition. 
    • Workaround: If this causes significant workflow disruptions, you can pad the ordinal with a leading zero in the LHR (e.g., QA76.3 .A12 092nd). This forces the system to sort it correctly. Future enhancements to the sorting logic will accommodate these leading zeros, so this workaround will not require reversal later.