What I learned at Worldcon: Chatting with Bill Contento, Locus Index compiler, at the Locus table at the Anaheim Worldcon one day, I learned that the formula for computing the checksum digit of the new 13-digit ISBN is different than the old formula.
For anyone not into cataloguing books, the ISBN, International Standard Book Number, has been the unique identifier for books published in the last 30 years or so. A typical ISBN runs 0-679-45077-7, where the 0 is a domain or continent ID [the US typically being 0, except for small presses and some newer publishers], the 679 is a publisher ID [this one is Knopf], the 45077 identifies the particular title, and the final digit is a ‘checksum’ computed from the previous digits according to some arcane formula. Responding to a kind of Y2K crisis, the publishing industry is migrating to an expanded, 13-digit ISBN system, and for a year or so now many US publishers have printed both the old-style ISBN-10 and the new-style ISBN-13 on the back covers of their books, right by the bar code. I have here, for example, a copy of the elusive Infoquake by David Louis Edelman (which despite all the publicity, I never have seen a copy of in a physical B&N or Borders store, and which I finally ordered from Amazon), which has these numbers:
Now at first glance it would appear that all that has been done is to tack 978- onto the front end of the 10-digit ISBN number, and this does seem to be the case for all the examples of current US books I’ve seen. But… a more careful glance reveals that the final digit, the checksum digit, is different. I hadn’t realized this, until Bill mentioned it. The new formula, he claimed, is different, one effect being that in the new system the final digit will never be ‘X’, has it was once every 11 times or so under the old system. (The checksum was a sum of products of the earlier digits, modulo 11.)
Now aside from the obvious, inherent fascination of these details, the reason I discuss this here is that one way I compile ISBNs for new books is by scanning reviews on the Publishers Weekly website every Monday or Tuesday, and tagging titles reviewed there in my Books database. If I don’t already have an ISBN for some title, I copy and paste the ISBN from the PW review into my database. For some time now…weeks? months?… I’ve been cropping the 978 off the 13-digit ISBNs listed by PW and pasting the result into the database.
Oops. That doesn’t work. You can find a book via ISBN on the Amazon site, with or without embedded hyphens, but search for 159102442-2 (from the example above) and you find nothing. The checksum digit is wrong. Which means…. some number of ISBNs in my database, reflected in the weekly New Books listings and in the Directory pages (which include forthcoming titles I haven’t yet seen), may be wrong.
I will be double-checking the Amazon links for new listings as I generate them for the website, but if some errors slip through, if you click on an Amazon link and get an error, this may be the reason. Of course if you do encounter such an error, let me know.
On a separate but related topic, I see that Amazon has changed the way it generates links to books, at least for current titles. To illustrate, if I search for Infoquake, the page I’m directed to has this link:
This URL has a huge chunk of text in the middle identifying the title and author. You’d think the ISBN number — see, they’re still relying on the 10-digit version, there right after the /dp/ — would be sufficient to identify a path to the book. Why is Amazon doing this? I have no idea. To make it more difficult for automated spammers to assault their site, perhaps?
My concern is that, as an Amazon associate, who gets a commission from every order to Amazon via a locusmag.com link, any change in the format of links might disrupt that revenue stream. It’s not a lot, but it does allow me to pay the reviewers — Howard and Lawrence and Gary and the others. Fortunately, the associate link format doesn’t seem to be affected; the link I’d build for Infoquake, http://www.amazon.com/exec/obidos/ASIN/1591024420/locusmagazine, still works.
(And I thought this would be a short post.)