Chronology and enumeration sorting

Problem

In the Receiving app, receiving pieces appear haphazardly and existing sorting is insufficient and/or unreliable (e.g. sort on enumeration puts no. 121 between no. 12 and no. 13.) This is compounded by the fact that chronology and enumeration are “mostly predictable” rather than “fully predictable”: supplements, combined issues, special issues etc. make sorting more complex.

Because chronology and enumeration are currently free-text fields, sorting is limited to alphanumeric sort, and variances in punctuation, abbreviation, capitalization etc. can throw things off. Alphanumeric sort is not useful for sorting by dates.

Chronology types

• Day (of the month, numeric)

• Day of the week (alpha)

• Week of the month (numeric)

• Week of the year (numeric)

• Month (alpha or numeric)

• Combined month (e.g. “June-July”)

• Season (alpha)

• Year (numeric)

Most chronology contains multiple levels (day, month, year; week, year; season, year, etc.). Any sort has to factor in all chronology levels in order.

Enumeration types

Enumeration is typically broken down into multiple levels, but those levels may have different labels. There is no theoretical limit to the number of levels of enumeration; systems I’ve worked with support up to 7, but practically speaking the max is 4 (which is extremely rare.) The vast majority are either 1 (annuals) or 2 (volume, issue.)

• Volume (level 1, does not repeat)

  • Number/issue (level 2, repeats per volume)

    • Part (level 3, repeats per number/issue)

      • Sub-part (level 4, repeats per part)

        • ???

Note that enumeration does not necessarily need to have a numeric display. Consider an encyclopedia set:

• A-B

• Ca-Ch

• Ci-Cz

• D-F

• etc.

Additionally, some series have inconsistent enumeration

• Volume 1

  • Number 1

  • Number 2

  • Number 3

    • Part 1

    • Part 2

  • Number 4

  • Supplement

  • Number 5

Possible approaches

1. Convert chronology and enumeration fields from free text to controlled vocabulary

• Configurable in Settings

  • Available chronology and enumeration defaults defined by library

  • Chronology and enumeration logic would be normalized

  • Library would also specify the order

    • Might be as simple as “value 1, label $free_text” to allow numerical sort

• Receiving title would require chronology and/or enumeration configuration per title

  • Use chronology or enumeration?

    • Assume that library may want enumeration + chronology year

  • Define levels of chronology/enumeration

    • Allow library to add an additional layer on the fly

    • Layers with null values would be excluded

      • A title with 3 layers might only have the third layer populated occasionally; if that layer is empty it is not displayed at all.

  • Sorting would occur based on the order defined in Settings

• Display chronology and enumeration would be distinct from logical chronology and enumeration

  • What is displayed via edge-rtac would (potentially) have to be distinct from internal FOLIO business logic, and would have to be stored separately (e.g. in Display Summary.)

    • e.g. a German publication might have Band I Teil 2, but would be logically handled in FOLIO as vol. I number 2. Librarians would see vol. number while working, but Band/Teil would display in Locate.

Challenges

• Impacts Orders, Serials and Inventory

  • Workload for multiple teams would have to be coordinated

• Creates significantly greater complexity in the Serials app

  • May also involve duplication of work

2. Sort on Display summary using pattern matching

This approach would disregard Chronology and enumeration fields (or combine into a single field) and standardize on a single field, then sort on that. This approach assumes uniformity in entering data.

3. Split Chronology and Enumeration in Serials and leave as text fields; sort assuming predictability

4. Assign a numeric, editable “sequence” value

• Disregard sorting by chronology and enumeration

• Receiving pieces are assigned a sequence number on creation

  • Only one piece per receiving title can have a given sequence number

    • Pieces created in bulk (e.g. through the Serials app) should have some sort of mechanism to ensure sequence corresponds with publication date.

    • Documentation should suggest that if libraries are creating pieces to be included in an already received state (e.g. during implementation/migration), those pieces need to be created oldest-first in order to minimize impact on the system

  • Library staff can modify that sequence number

    • Need to determine handling if a very, very large, non-contiguous number is assigned.

    • Ideally, automatic numbering will pick up from next contiguous number rather than next number.

    • Alternately, very, very large numbers will automatically be reduced to the next contiguous number.

    • Sequence numbers must be positive integers.

  • When a sequence number is modified, all other existing receiving pieces with a sequence number equal to or greater than the assigned number are incremented by 1 automatically until an unassigned number is met

  • Example 1

    • Receiving piece sequence 1, 2, 3, 4 exists

    • Staff member assigns 3 to 2

    • 2 is a duplicate, so “old” 2 becomes 3

    • 3 is not a duplicate, so 4 is not updated

  • Example 2

    • Receiving piece sequence 1, 2, 3, 4 exists

    • Staff member adds new piece (5)

    • Staff member assigns new piece sequence value of 3

    • 3 is a duplicate, so 3 becomes 4

    • 4 is a duplicate, so 4 becomes 5

• Receiving pieces are displayed in reverse sequence order in ALL accordions (expected, received, unavailable)

  • Sequence order is sortable (ascending, descending)

• Sequence order is available to edge-rtac and other apps within FOLIO

• Sequence is displayed as a column in the Receiving app

Challenges

• Potential performance impact if many pieces need to be resequenced

• Ultimately very manual process, but also allows highest degree of control over piece order

Open