LibraryThing was in the first batch, and I brought in a number of the
libraries they picked to be with us. I think NGC4LIB might be a good
place to discuss the Google Book Search API and its limitations. It's
a very knotty thing.
The knot arises from the fact that the Google API isn't XML, like
Amazon's AWS. It's Javascript JSON. This is at the root of both GBS's
power and its limitations.
Power. Because it's JavaScript, everything happens client-side. If you
can extract an ISBN, OCLC or LCCN from the page, the rest is up to
Google and JavaScript. This means it can be added to almost any OPAC,
without any back-end systems integration. For libraries, this is
critical.
Limitation: Because it's happening in JavaScript, your library doesn't
"get" the data. It happens in the patron's browser and your server
never sees it. For this reason and because Google says so, you can't
*store* any of the data. You can't integrate more deeply. You can't
search against it, etc.
Lastly, the API doesn't expose ANY bibliographic data. (Google says
this is for license reasons—which I think means OCLC won't let them.)
You send it an identifier and you get that back, together with URLs to
its place on Google and whether the have a full version, a partial or
just an info page. You don't even get a title back. This made it very
hard for LibraryThing, which always works on a "work" level. For many
of our books, we're sending 100-200 identifiers, and getting back a
mess of URLs. Without titles and with cover coverage spotty, we have
no way to identify all these hits.
Best,
Tim
Received on Sat Mar 15 2008 - 00:16:03 EDT