Skip to end of banner
Go to start of banner

Call number browse requirements overview - DRAFT

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

DRAFT

Contents:

Purpose

This document seeks to outline the full requirements of the Call number browse feature in FOLIO. It compiles the requirements from the original implementation of the feature, as well as the feature to browse by call number type (LC, Dewey, SuDOC, etc).

Use cases

The ability to browse by call number (and more specifically by type) facilitates the following use cases:

  • Aids in the classification of new materials by helping to control duplication and maintain symmetry in classification.

    • Identifies the next unused call number

    • Identifies where the searched call number would fall within the shelf list

    • Helps librarians manage multi-part and series materials by highlighting which volumes have been cataloged

  • Supports inventory management/auditing by providing a way to verify the presence or absence of materials on the physical shelves as well as the ability to analyze subject depth for acquisitions/weeding planning

  • Aids in data cleanup and record maintenance efforts by making it easier to identify incorrectly assigned call numbers

  • Aids in the discovery of sources related to known items

NOTE: Classification browse requirements have been moved to separate page: Classification Browse Requirements

Differences between item call numbers and instance classification numbers in FOLIO

PropertyItem call numberInstance classification
Multiple numbers per record type

NO one instance can have multiple items, but one item can only have one call number/call number type combination

YES instances can have multiple classification numbers with different types

Configurable types

YES this is why we created some types as source: system so users could not edit the types we support browsing

NO users can create local classification types, but these are out of scope for the first iteration

Multi-part field

YES "call numbers" can comprise many different fields, such as the prefix, suffix, enumeration values, or copy numbers

NO there is only a single "Classification" property

Inclusion in browse results dependent on the presence of another record type

YES call numbers only show up if there are items on a holdings record; even though items can inherit call numbers from the holdings record, holdings record call numbers do not show in results if there are no items attached

NO classification numbers should be included regardless of the presence of holdings or items

Item-level call number requirements

#

Requirement

Description

Functionality

Related tickets

Implementation Status
1

Generate a shelving order for call numbers

  • Initial implementation focused on implementing type-based shelving orders for LC and Dewey call numbers, based on the marc4j library, as well as Other scheme

  • Added normalized shelving orders based on NLM and SuDoc types (Poppy release)

  • The sorting mechanism should consider the call number, volume, enumeration, chronology, copy number, and suffix data

Browse

COMPLETE

2

Add a new Inventory browse option for call numbers

  • Current implementation of the following call number type options:
    • Call numbers (all)
    • Call numbers, Dewey Decimal classification
    • Call numbers, Library of Congress classification
    • Call numbers, Local
      • *where "Local" includes any call numbers with a type of source: Local
    • Call numbers, National Library of Medicine classification
    • Call numbers, Other scheme
    • Call numbers, Superintendent of Documents classification
  • These call number types have been made uneditable (with source: system)
Browse

FE -initial: UXPROD-3459 - Getting issue details... STATUS

BE - initial: UXPROD-3255 - Getting issue details... STATUS

FE - browsing by type: UXPROD-4327 - Getting issue details... STATUS

BE - browsing by type: UXPROD-3569 - Getting issue details... STATUS

IN PROGRESS

3

Populate browse results list with all item-level call numbers

  • Item call numbers can either be specified in the Item record, or inherited from the Holdings record

  • Browse results will contain ALL item-level call numbers (see below for navigating forward and backward through the list)

  • A single Instance can have multiple items with call numbers of different types
Browse


COMPLETE

4

Sort by calculated effective shelving order


Browse


COMPLETE

5

Browse results should contain preceding and succeeding call numbers per shelving order

  • Preceding call numbers should include five records

Browse


COMPLETE

6

Users should be able to navigate forward and backward through the list


Browse


COMPLETE

7

Call numbers on the browse results list should display the Prefix, Call number, and Suffix values, if applicable


Browse


COMPLETE

8

The results should indicate a match if:

  • The browse query matches the Prefix + Call number + Suffix (the call number components that are visible on the results pane) - UNDER REVIEW - as noted in the description, it is confusing when the browsed query indicates that a match is not found but to the user, it looks to match the succeeding call number

  • OR the components of the shelving key (call number, volume, enumeration, chronology, copy number, and suffix data)

  • Currently, since the shelving key does not contain the prefix, when the user browses the call number with the prefix value, it will not find a match, but will show the visually matching call number directly below the “X would be here” message. It is confusing to users.

Browse


UNDER REVIEW

9

If no exact match is found, the browse query should be placed in proper order (with preceding and succeeding call numbers) as a placeholder (“x would be here)


Browse


COMPLETE

10

If there are multiple copies with the same call number (with a value in the Copy field) and the user browses with the copy number, any copy number should return a match

  • Currently, only a seemingly random copy will return a matching result if the Instance record has multiple items with the same call number but different copy numbers:

Browse


NOT STARTED

11

When browsing typed call numbers, the effective location facet should only contain the locations of the specific call numbers types on the Instance


Browse

NOT STARTED

12Users should be able to search Items in Inventory by the Effective call number (item), eye readable
  • Should be exact in terms of characters & spacing, but should be case insensitive UNDER REVIEW
  • Mostly implemented, but current search is case sensitive
Search

UNDER REVIEW

13Users should be able to search Items in Inventory by the Effective call number (item), normalized
  • Should ignore characters & spacing and be case insensitive
Search

COMPLETE

14Users should be able to search Holdings in Inventory by the eye readable call number (holdings)
  • Should be exact in terms of characters & spacing, but should be case insensitive 
Search

COMPLETE

15Users should be able to search Holdings in Inventory by the normalized call number (holdings)
  • Should ignore characters & spacing and be case insensitive
Search

COMPLETE

16Users should be able to search Instances in Inventory by the effective shelving order of the item call number
  • I think this facilitates the ability to navigate from a result in the call number browse list to the Instance in Inventory
Search

COMPLETE

17Effective location facet selection should be retained when selecting a record in the browse results list for call number browse by type
Browse

NOT STARTED

  • No labels