[Developers] Casting ISBN-10 to ISBN-13

[Richard Newman]

> Your points are all valid.  I find your point that a user might use an
> ISBN-10 in the standard freebase search by and come up lacking
> especially compelling.  Still, I'm not sure it outweighs the extra
> cost and hassle of maintaining two separate property .

Understood.

> At the very least, it sounds like we should rename the /book/
> book_edition/ISBN property to /book/book_edition/ISBN13, and add clear
> documentation to the property about proper usage.  Our gardening
> scripts could correct any user entry errors by automatically casting
> ISBN-10 to ISBN-13 on a nightly basis.

That sounds reasonable to me, though -- playing devil's advocate for a  
moment -- ISBN-13 has officially been "the ISBN" since Jan 2007[1], so  
it does have the current claim to the un-suffixed name! The problems  
here are with user perception (particularly in search, where a user  
has their own perception of what an ISBN is) and ontological nicety  
(tied to user perception: can an old book's ISBN change years after  
publication?), rather than the name of the property per se.

In my opinion it should be sufficient to simply document and garden,  
rather than change the name, and then solve the search problem...  
which might require some fiddling with data. That issue needs more  
thought: I'm sure the same comes up in a number of situations  
involving labeling in Freebase.

(Perhaps a union value of some kind -- ISBN-10 being the miles to  
ISBN-13's kilometers? Sadly I've never quite reached expertise on  
Freebase's internals, so I don't know if this is possible.)


> It sounds like you are very familiar with the particulars of ISBN
> numbers, so let me ask you this -- if we decided now to standardize on
> ISBN-13 but later decided that we also wanted a separate, parallel /
> book/book_edition/ISBN10 property, would it be correct to auto-
> populate the ISBN-10 property where a valid back-mapping from ISBN-13
> existed?

Yes: to convert from 10 to 13, simply prefix with 978 and recalculate  
the check digit; to reverse, make sure it starts with 978, remove it,  
and re-checksum. The mapping is bijective for all pre-2007 books. Of  
course, not every ISBN-13 maps to ISBN-10, so this auto-population  
would only apply to older books.

An alternative would be to spot 10-digit (possibly hyphenated) numbers  
with correct check digits in the UI, and seamlessly convert at query  
time, but that's a tradeoff between complexity and additional data  
that only you MW folks can make.

(The final use case that might trip up with conversion is round- 
tripping: I can imagine scenarios where 10-in, 13-out would be either  
desirable or undesirable.)

Ah, the vagaries of data :)

-R


[1] <http://www.isbn.org/standards/home/isbn/transition.asp>