The documentation for C4::ClassSortRoutine::GetClassSortKey says * Concatenates class and item part. * Converts to uppercase. * Removes leading and trailing whitespace and '/' * Separates alphabetic prefix from the rest of the call number * Splits into tokens on whitespaces and periods. * Leaves first digit group as is. ... 9.1 => 9_100000000000000 80.1 => 80_100000000000000 700.1 => 700_100000000000000 when sorted ascending by cn_sort are 700.1 => 700_100000000000000 80.1 => 80_100000000000000 9.1 => 9_100000000000000 however, DDC classes are formatted 000 – Computer science, information & general works 100 – Philosophy and psychology 200 – Religion 300 – Social sciences 400 – Language 500 – Pure Science 600 – Technology 700 – Arts & recreation 800 – Literature 900 – History & geography 000 is sub-divided into the hundreds group 000 Computer science, knowledge & systems 010 Bibliographies 020 Library & information sciences ... and sub-sub-divided into the thousands groups... 000 Computer science, information & general works 001 Knowledge 002 The book 003 Systems ... As such, '* Leaves first digit group as is.', should read * the first digit group should be 3 characters wide, 0-padded I.e. the value of cn_sort for callnumber 1.1 should be 001_100000000000000, so that the examples above sort 009_100000000000000 080_100000000000000 700_100000000000000 See discussion here: http://lists.koha-community.org/pipermail/koha-devel/2018-June/044623.html And the summary of DDC 23 here: https://www.oclc.org/content/dam/oclc/dewey/DDC%2023_Summaries.pdf
Given the conversation that took place in that email thread, do we actually need to add a new sort class for this rather than changing the existing one's behaviour to give the least surprise to users? Or perhaps create a new UDC.pm class which is simply a copy of the current Dewey one before altering the behaviour of Dewey at the very least? Universal Decimal Classification / UDC being effectively what the current Dewey.pm acts correctly for UDC sorting...
(In reply to Martin Renvoize from comment #1) > Given the conversation that took place in that email thread, do we actually > need to add a new sort class for this rather than changing the existing > one's behaviour to give the least surprise to users? Or perhaps create a > new UDC.pm class which is simply a copy of the current Dewey one before > altering the behaviour of Dewey at the very least? > > Universal Decimal Classification / UDC being effectively what the current > Dewey.pm acts correctly for UDC sorting... I think the second option -- - Create a UDC cn_source / UDC.pm that retains the current behavior of Dewey.pm - Update Dewey.pm to 0-pad the digits before the decimal point is the way to go, although this will require some care, because cn_source is used widely in Koha -- there are tests for 'ddc' in xslt files, Koha/EDI.pm, and C4/Labels/Label.pm.
The change would not be too hard to do, but is there someone who could test with deeper knowledge of the classification schemes?