Bug 15772 - GetNormalizedISBN returns a 10 digit ISBN - should return 13
Summary: GetNormalizedISBN returns a 10 digit ISBN - should return 13
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-09 16:01 UTC by Nick Clemens
Modified: 2018-09-19 16:42 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
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 Nick Clemens 2016-02-09 16:01:08 UTC
As not all 13 digit ISBNs can be 10 digit we should normalize to 13 instead of 10

(Novelist also can't interpret 10 digit ISBNs with an ending X so this would solve that too)
Comment 1 Patricia Brauer 2016-08-05 21:40:56 UTC
Nick -- Is this still open? There's no work, no test plan.

Tricia Brauer
Comment 2 Colin Campbell 2018-09-19 14:38:54 UTC
For future proofing we should be considering moving to 13 digit ISBNS as all 10 character ones can be represented as 13 - increasingly external sources (acquisitions vendor bib data providers) are using 13 as default - we are also encountering non-bookland eans in the same contexts.
The routine is used throughout Koha so we should look carefully at any implications or incompatibilities auch a change would have
Comment 3 Thomas Dukleth 2018-09-19 16:42:12 UTC
Normalising ISBNs to a single value which at least provides for normalisation from ISBN 13 would be an improvement but misses an important issue especially where an ISBN based value is used for too much in Koha.  The ISBN 10 vs ISBN 13 problem touches on a larger issue.

Normalising ISBNs to single value misses how ISBNs are used in the real world where they are poor as bibliographic identifiers because they are not unique identifiers and treating them as such can only lead to problems.  ISBNs should be a list not a single value.

See the multiple ISBN normalisation examples sections in both the problems and remedies in bug #3092 which was closed for age and for needing decomposition into smaller bugs.  Other complications to non-uniqueness which I may have omitted in bug #3092 include the bad practise of some important publishers reusing old ISBNs for completely different titles at a later time after the formerly applied title has gone out of print.

We should also be adding other identifiers to appropriate lists for appropriate functions for which ISBNs are especially under-inclusive as any kind of identifier such as material for which ISBNs are seldom or never assigned.

If considering at least the larger problem of replacing a string by a list, the parallel code method described in bug #3092 for how to approach fixing such deeply embedded bugs without breaking everything.