Karen Coyle's posting caught my eye because our Network has been dealing
with an increase in reported ISBN problems lately. When we implemented
book covers and reviews in our public catalog (linking by ISBN), we
began to receive reports from patrons of mis-matches and double-matches
of titles with cover images. Our anecdotal experience has been that both
the vendors (e.g., Amazon) and OCLC's records are incorrect in most
cases. What we find are duplicate ISBNs - where 2 titles have the same
ISBN. Our hypothesis has been that the error may be originating with the
publisher. Am I correct in thinking that the comparison done for the
OpenLibrary project would not have caught these duplication errors -
cases where 2 or more titles had the same ISBN? Duplicate ISBNs are a
problem if the publishing and library worlds wish to use them as unique
identifiers. They are not a problem affecting sales, since a search for
the ISBN on Amazon wold pull up all titles with a match, and a customer
could select the one they wanted. (If not for the cover image problem,
perhaps they would not be a problem in library catalogs either?) This
kind of touches on what Mike Tribby has been saying about the
expectation that publishers will 'get' what libraries need and willingly
provide it. When our Network looked into a web service product whereby
we could download brief bibliographic records from vendor websites
(e.g., B&T, Ingram), we found that the records were inconsistent and
very sparse. Our expectation going in was that the vendor would have
very complete bibliographic information in its catalogs and would be
able to provide adequate information to create a brief bibliographic
record. We were surprised that the data was so poor and we reluctantly
decided not to implement the service. I support the notion of using
publisher data, but we have to recognize (and bridge) the current
communication gap between what data libraries would want and what data
publishers might supply. This probably means that libraries will have to
accept 'imperfection' and errors and changes in how we define standards;
and, assuming publishers are willing to work with us, it will mean
changes on the kind of data they keep and are thus able to provide.


Amy Hart
Head,Bibliographic Services
Minuteman Library Network


Email: [EMAIL PROTECTED]
Phone: (508)655-8008 x222




Karen Coyle wrote:
Jonathan Rochkind wrote:
You think there are no wrong ISBNs in any cataloger-assigned isbns in
marc records? As someone who works with ISBNs in cataloger created marc
records, I assure you there are.

Actually, for the OpenLibrary project there was a compare done between
Amazon data and LC data. First, it matched records on ISBN, then it
compared the titles. In the group that I looked at, where the ISBN in
one of the records was wrong it was wrong in the LC record, not the
Amazon record. That's logical: publishers are motivated to get the
correct ISBN in the database where bad data can mean losing a sale, so
if they find an error they correct it. There is less motivation for LC
to go back and correct ISBNs, even if they would notice that they are
wrong.

I also want to say that this discussion seems to focus on library data
vs. publisher data, as if it is either-or. It isn't. In fact, already
many libraries (including LoC) are adding publisher data to their
catalogs, such as author bios, book blurbs, tables of contents, and
cover art. It makes total sense for this data to come from the
publisher, since it is the publisher who produces it. I'm convinced that
we can have a data workflow that makes better use of data that is
already produced at certain points in the product cycle. I also think
that we can increase the utility of these data sources by agreeing on
some points of connection. If only our energy would go into that instead
of arguing about whose data is better.

kc
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[EMAIL PROTECTED] http://www.kcoyle.net
ph.: 510-540-7596   skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------

Reply via email to