Bug 20961

Summary:	cn_sort for DDC callnumbers should between 1 and 99 should be formatted as 001.* - 099.*
Product:	Koha	Reporter:	Barton Chittenden <barton>
Component:	Architecture, internals, and plumbing	Assignee:	Bugs List <koha-bugs>
Status:	NEW ---	QA Contact:	Testopia <testopia>
Severity:	enhancement
Priority:	P5 - low	CC:	martin.renvoize
Version:	Main
Hardware:	All
OS:	All
Change sponsored?:	---	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:

Description Barton Chittenden 2018-06-18 23:03:39 UTC

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

Comment 1 Martin Renvoize (ashimema) 2018-06-19 08:18:16 UTC

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...

Comment 2 Barton Chittenden 2018-06-19 14:40:43 UTC

(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.

Comment 3 Katrin Fischer 2023-09-16 08:18:52 UTC

The change would not be too hard to do, but is there someone who could test with deeper knowledge of the classification schemes?