The new Google Book Search Data API has some really cool features and I’m wondering how much of it I can shoehorn into the OPAC?
Our students increasingly expect the OPAC search box to be searching the full-text of our book stock — i.e. they type in several words that it would be useful to borrow a book about. Searching just the bog-standard MARC metadata, you’ll be lucky to get much back… and perhaps then, only if we’ve got the full table of contents in the the MARC record.
So, for example, if I do a keyword search for “english media coverage of immigrants and social exclusion” on our OPAC, I’ll find nothing. However, if I run the same query through the Google API and then filter the results (using the ISBN) to just items we hold in the library, I get 6 hits from the first 40 results that Google sends me:
- European societies fusion or fission?
- Criminal and social justice
- Human geography of the UK : an introduction
- Preserving privilege California politics, propositions, and people of color
- Black youth, racism and the state : the politics of ideology and policy
- Television : the critical view
(I’d probably find more if I also used thingISBN or xISBN to match on associated ISBNs)
I’m not going to claim that those 6 are the most relevant books we hold in the library for that particular search (I’m not sure if I’d find anything of use in the “California politics” book)… but that’s only because I have no idea what the most relevant books are and, no matter how closely I scrutinise our MARC records, I probably never will 😉 So, short of quizzing a Subject Librarian, some of those books might be a worth a quick browse …which I could do virtually with the Embedded Viewer API:
GBS_insertPreviewButtonPopup(‘ISBN:0415198437’);
I guess the big question is “how many API searches will Google let me do every day?”
The terms of service don’t let you combine GBS results with other results in a meta-search type way. But they probably do let you put a seperate box on the screen with GBS results.
I’ve been thinking of ways to use this without violating the terms of service too.
I actually already HAVE incorporated GBS services in Horizon on the item detail page, once you get to an item detail in horizon, it’ll look up whether that item is available/searchable/partial in GBS (or Amazon; or the internet archive; or HathiTrust), and let you know. I did this with the open source Umlaut software though, not native in HIP. But I’ll be blogging about that soon, we go live with those features next week.
For HIP, I don’t think I’d be able to combine the GBS results with the HIP generated ones anyway (although I guess that would be the ideal).
What I was thinking of doing is having a separate box of results from GBS appear if the keyword search brought back zero results or just a small number of results (e.g. less than 10). That should hopefully keep the number of GBS API calls down a minimum.
It would be a shame if the terms of service stopped GBS being used as a search target in MetaLib tho 🙁
I’ve also noticed that the results returned from the API have changed from day-to-day. Yesterday the example search brought back 5 results (which included a new result) and today it’s 7.
Hi. Should you send me the gbs.pl script you use ? It would be great to have a look on it. Thanks.
Well, the Google Scholar terms of service ALREADY DO explicitly prevent Scholar from being used as a target in Metalib. But Ex Libris provides it anyway, and many customers use it.
When customers sometimes run into problems, and contact Google to tell them something isnt’ working, they are surprised to have Google respond “You aren’t allowed to do what you’re doing.” They generally keep doing it anyway.