ISBN10 and ISBN13 should be interchangeable

[singpolyma]

For search, all APIs, and cover retrieval, if either an ISBN10 or ISBN13 is set for an edition, then the equivalent other number (13 to 10 conversion only valid for 978 prefix) should work as well. This allows application developers to normalise on one number instead of keeping track of both.

[george08]

Hi singpolyma - Completely agree!

Are you able to contribute some sort of ISBN converter/normalizer code?

[singpolyma]

A simple 10-to-13 example is at: https://gist.github.com/1002978 There is some more involved code at: https://github.com/singpolyma/isbn_ruby

[george08]

Now our search engine looks for both types of ISBN simultaneously.

[anandology]

I think it is important even for the Books and import API to be able to use isbn-10 and isbn-13 interchangeably. We already have an indexed field that stores the normalized ISBNs. It is not too hard to add the isbn conversion. In fact, we convert from isbn-13 to isbn-10 for displaying amazon.com links (http://openlibrary.org/books/O L24972205M/Terms_of_Engagement).

@george08 shall we go for it?

It might even be useful to display the converted ISBNs in the edition view. @EdwardBetts and @george08 what do you think?

[george08]

Yes!

[anandology]

Running a script to index both available and generated isbns.

[anandology]

Books API, Read API and Import API now works both ISBN-10 and ISBN-13 even if just one of them is defined.

Need to make the covers API use the same.

[gmcharlt]

Out of curiosity, are ISBN-10 and ISBN-13 values officially interchangeable in the covers API nowadays? Some testing suggests yes, but after a cursory look at the code, I wasn't able to pinpoint a commit making it so.

[anandology]

Yes.

Here is the commit.

https://github.com/internetarchive/openlibrary/commit/c93e8bdcc6f6549715d6a1296377b8be81c46423

On Wed, Apr 9, 2014 at 10:22 PM, Galen Charlton notifications@github.comwrote:

Out of curiosity, are ISBN-10 and ISBN-13 values officially interchangeable in the covers API nowadays? Some testing suggests yes, but after a cursory look at the code, I wasn't able to pinpoint a commit making it so.

Reply to this email directly or view it on GitHubhttps://github.com/internetarchive/openlibrary/issues/27#issuecomment-39987991 .

Anand http://anandology.com/

[gmcharlt]

Thanks! Perhaps this issue can be closed.

[LeadSongDog]

This still doesn't seem right. The example at http://openlibrary.org/books/OL24972205M/Terms_of_Engagement was built from an initial imported IA MARC record that had three ISBN_13 and one (equivalent) ISBN_10 shown in field 020, yet all that was generated in the record was a single ISBN_13. This was also somewhat redundant to https://openlibrary.org/books/OL24791680M/Terms_of_engagement which was generated from the LC MARC import a month earlier.

[LeadSongDog]

Further, on those two OL records for the same edition, the "Borrow: Physical copy, local" Worldcat URLs are different, one searching for the ISBN_10, the other for the ISBN_13 http://worldcat.org/isbn/1605094471 http://worldcat.org/isbn/9781605094489 They are both resolved to http://www.worldcat.org/title/terms-of-engagement-new-ways-of-leading-and-changing-organizations/oclc/671632684 so there's no clear value in having two different formats.

[LeadSongDog]

@bfalling Perhaps it's worth considering the adoption of other, proven, ISBN-handling repos? https://github.com/xlcnd/isbnlib https://github.com/JNRowe/pyisbn are GPL3 or https://github.com/xlcnd/isbntools is LGPL3. Done right, we should accept all forms for inputs, convert them to only 13 digits, validate the check digit, ensure the target actually exists in a library (that is, it isn't still in-cataloguing with an uncertain pub date), convert the 13 digits to 10 and store both forms for searches (without hyphens).

[brad2014]

@mekarpeles, I assume this is your call: I suggest we close this bug. If there is interest in moving isbn handling onto pyisbn or isbntools, let's open that as a separate feature request (which we can backlog and schedule).

[tfmorris]

@brad2014 Stories are typically about user facing features, not implementation details.

Having said that, this feature request was mostly complete in Nov 2011 and finished up in Mar 2012, so this issue can be safely closed.

The items mentioned by @LeadSongDog in Apr 2016 (not all ISBNs imported from MARC 020 and cosmetic issue of multiple WorldCat URLs) can be made into separate tickets if they still exist and don't already have tickets covering them.