Bug 25395 - Enumchron needs to sort numerically
Summary: Enumchron needs to sort numerically
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P1 - high enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-06 16:57 UTC by Myka Kennedy Stephens
Modified: 2024-04-16 20:45 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Myka Kennedy Stephens 2020-05-06 16:57:34 UTC
This is a follow-up to bug 13420.

13420 was resolved by changing the sort for serials items. The underlying issue with enumchron still exists and affects all items in multi-volume series (not just serials).

Is it possible to sort this field numerically by whole number first and then alphabetically? Part of the solution needs to include escaping prefixes like v., vol., no., etc.
Comment 1 Katrin Fischer 2020-05-06 21:54:59 UTC
Hi Myka, I think it might even be more complicated. 

The serials module also uses this fields for issues information, so the patterns can be pretty much anything.

Year Month
Year Seasonal
Year Number Issue
Issue Year

Alphabetic and numeric parts mixed. I think we'd need quite a clever algorithm here or compromise. Maybe not only sort by the first numerical bit, but by each of them one after the other?
Comment 2 Katrin Fischer 2020-05-06 21:55:42 UTC
Sorry, missed you had already mentioned serials on first glance!
Comment 3 Myka Kennedy Stephens 2020-05-06 22:35:24 UTC
(In reply to Katrin Fischer from comment #2)
> Sorry, missed you had already mentioned serials on first glance!

It's okay, Katrin! I filed this bug because there are some problems that the solution for bug 13420 did not address. Namely, that enumchron still sorts alphabetically (I'm guessing this is what is happening) when the serial.publisheddate does not exist. Items will only have a value for serial.publisheddate if they have been derived through the serials receiving process. Serial items that are brought over from a migration or added through other manner of acquisition, and also multi-volume sets that extend beyond nine volumes are not going to have a serial.publisheddate value and are not going to sort correctly without extra measures taken in the cataloging process.

How we address it in our library's catalog is by adding an extra 0 to the beginning of the volume number so that they sort in the correct order. An item with enumchron=v.09 will appear before an item with enumchron=v.10. This was a lot of work to add these 0's when we migrated to Koha. What will be truly annoying is when a serial makes the shift from volume 99 to volume 100. In such an event, we'd be faced with going back and adding an additional 0 to every item's enumchron for that serial!

Yes, I see that a sophisticated algorithm is likely going to be needed. I also thought about the possibility of splitting enumchron into two fields: one for enumeration and one for chronology so that a similar solution that was used for bug 13420 could be tried. The problem with that is that every Koha library would likely be facing a data clean-up project to split the data from the enumchron into the two fields.

There's likely no easy answer. Yet, we should not lose sight of the problem.
Comment 4 Katrin Fischer 2020-05-06 22:46:00 UTC
While this is hard, maybe something could work out something that at least works well in a lot of cases and offer that as an option while we refine it further.

I like the idea of a 'sortable' version of the enumchron. We actually have something like that in our union catalog, but on record level. 

Multi-volume series are catalogued with a separate record for each volume, each linked to a set record. So we mostly see the issue described here for serial items. And we suffer from bug 15161.
Comment 5 Andrew Fuerste-Henry 2020-05-07 00:18:47 UTC
Maybe we could do something here along the lines of what we do with call numbers? Maintain a separate column of enumchron_sort, where we pad/format the values into something that will sort as desired. Although that gets us back to Katrin's point that we've got a huge variety in what goes into that field, so it's hard to imagine a unified padding behavior.
Comment 6 Dani Elder 2023-07-05 19:17:14 UTC
Could we create a sticky sort order then? Where we can tell Koha ... this is 1, this is 2, this is 3 in order? Defaults to acq date sort for initial sticky sort, but then we can moved items up and down in the sort field manually and they "stick" for viewing in staff and opac?
Comment 7 Teresa Van Doren 2024-04-16 20:45:03 UTC
The Black Gold libraries would also like this bug to be fixed so the volumes in item records v.01, v.02, v.03, v.10, v.100 appear in number order.