Discussions on Book Edition

... or is that what the LCC property is supposed to be? If so, why can't I filter by LCC?

Thanks for the feedback! This currently is a UI limitation - the filter view currently only shows the first several properties listed in the type. I moved up LCC in the type so that it can be used for filtering, and in the future we'll have the UI limitation fixed so that all properties can be used for filtering.

In order for the filter to be meaningful it has to be possible to filter on partial LCC. For example, if the LCC is input as TK5101.G58 then the finest filter that works is up to the "." (ie. a filter of "TK5101" returns hits while a filter of "TK" returns 0 hits). Only in a few (eg QA76.6) will the full qualifier up to the "." return a useful set of hits.... In the great majority of classifications the meaningful classification ends with the two (sometimes one; rarely three) letter code and knowing the full that the LCC TK5101 (for James Gleick's "What Just Happened") will not return similar books - for that you have to be able to successfully filter on TK Could a hint be provided to suggest entry of LCC in the format [major class] [space] [number] [author] (eg TK 5101 G58 (the G58 indicates Gleick) or better yet an input mask that ensured this format was input.

We can certainly add a weigh property to book edition, if you think we'll be able to get data for it. (The only source I know is Amazon.)

Hardcover/paperback/etc. is in the "Binding/format" property of "Book Edition".

We have a separate model for translations, which links translator and target language to both the book and its editions (and which can also be used for plays, comics, and other written works). See http://www.freebase.com/view/helptopic?id=%239202a8c04000641f800000000513676f for the help topic.

The ISBN field can contain both ISBN-10 and ISBN-13 (and SBN, for that matter). I added some help text to the property to make this clearer.

That's great, thanks. Does this have any implications for searching, or should searches on ISBN match a pattern rather than the exact string?

I think the implications for searching are similar to having separate fields for ISBN-10 and -13; in that case, you would always know which value to expect, but you'd also always have to query both values in case only one was filled in. In our current model, you only have to query one field, but still need to search for both values. But you should be able to query for just the nine digits that are the same for ISBN-10 and ISBN-13 using wildcards, which will work for the immediate future, but not once the 979 prefix comes into play.

An alternative would be to have just an ISBN-13 field and have some kind of script to autoconvert ISBN-10s and SBNs that were entered. This would work for linking to catalogs and bookstores, but I think collectors might like to have the original number preserved -- can any collectors out there weigh in?

OK, that makes sense to me.