<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Brian Karlak wrote:

<blockquote cite="mid:385D912D-49E9-4568-8410-D774A0703221@metaweb.com"

 type="cite">

  <pre wrap="">On Feb 11, 2009, at 1:52 PM, Richard Newman wrote:

  </pre>

  <blockquote type="cite">

    <pre wrap="">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.

    </pre>

  </blockquote>

  <pre wrap=""><!---->

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 

  </pre>

</blockquote>

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.<br>

<br>

Shawn<br>

</body>

</html>