[Developers] Casting ISBN-10 to ISBN-13

[Shawn Simister]

Brian Karlak wrote:
> On Feb 11, 2009, at 1:52 PM, Richard Newman wrote:
>
>   
>> If you regard the ISBN as being an attribute shared by instances of
>> the edition, then I'd suggest having separate ISBN-10 and ISBN-13
>> properties, because you want to preserve the value printed on the
>> book. A user searching by the number on the book won't know to
>> translate their ISBN-10 to ISBN-13; a book with both fields printed on
>> the dust jacket (despite a well-documented 1-1 mapping) should perhaps
>> have both properties.
>>     
>
> We had discussed implementing both ISBN-10 and ISBN-13 links.  Beyond  
> the extra space requirements needed to store equivalent information  
> (which is significant when you consider the number of editions in  
> freebase), my personal feeling is that dual properties will make the  
> schema more complicated to use.  Applications will now have to search  
> two fields instead of one.  Users entering data would need to make  
> sure they used the proper field.
>
> Since the code to do ISBN-10 to ISBN-13 conversion (and vice-versa) is  
> relatively straightforward, doesn't it make more sense to have a  
> single standardized field that we can rely on?  For instance, it I  
> could a very simple ACRE app that would do the necessary conversion to  
> do the proper freebase lookup.
>
> Brian 
>   
I think that's a good solution. You could also add some input 
normalization to any ISBN fields in the UI so that if someone enters an 
ISBN-10 number it would be automatically saved as an ISBN-13 number. 
Sorta like what Freebase does when you enter a date.

Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/developers/attachments/20090212/c25c6632/attachment.htm