But check this out. I know the iPhone has a barcode app that is quite good. There are a couple other barcode scanners as well, and they all seem to be primarily designed for consumers who want to check product pricing. But Android has a barcode scanner as well, with one additional feature that is potentially game-changing, for us: it allows you to scan a book, and then do a full-text search on it, and it’s fast. As roving reference becomes more popular, tools like these are destined to become back-pocket necessities. Android’s barcode app brings full-text search capability directly into the stacks in a way that integrates seamlessly into the roving work-flow. Imagine the possibilities…

Step 1: Get a book and a Droid

Step 2: Download the free barcode app

Step 3: Scan in the book's barcode

Step 4: Search in the book

Step 5: View your results

For example, here is the AADL top items list using onr of my Google gadgets (seems to not work in some browsers):

Very cool and very easy.

Actually, that’s fine, I have no problem with that, which means… They should have no problem with me incorporating Google Books into our hit-list. Right?

Now when users search the AADL catalog, they will be given the option to peek inside the books on the hit-list–that is, if there is a record over at Google Books. Basically, the first time that record is displayed in the list, the middleware queries Google Books to see if it has that item in its database. If it does, the middleware makes note of that in a MySQL table so that the remote query doesn’t need to be run again. That way, future queries save time and bandwidth.

Looking at the Syndetics offerings next to it, this seems like a much richer and more useful resource. Enjoy!

** Update 1: 8/24/06 9:45 PM **

Ha! It looks like that was short-lived! (Thanks to Ryan for giving me the heads-up), Google apparently doesn’t return the favor:

We’re sorry…

… but your query looks similar
to automated requests from a computer virus or spyware
application. To protect our users, we can’t process your request
right now.

We’ll restore your access as quickly as possible, so try again soon. In the meantime, if you suspect that your computer or network has been infected,
you might want to run a virus checker or spyware remover to make sure that your systems are free of viruses and other spurious software.

We apologize for the inconvenience, and hope we’ll see you again on Google.

And here I was, trying to be nice by caching the results… Guess we’ll have to wait for the API.

** Update 2: 8/25/06 8:50 AM **

So, I think I found a way to fix this. Essentially, the way I was previously determining if Google Books has a record for and ISBN what by using this URL template:

http://books.google.com/books?vid=ISBN$isbn&printsec=frontcover&dq=isbn:$isbn

Now I’m using a different URL that does not return 404:

http://books.google.com/books?as_isbn=$isbn

If there was no record for that ISBN, Google would throw a 404. I think the fact that one IP was requesting so many 404s is what spooked Google, not the retrieval rate. Also, I noticed that I could no longer use wget on the command-line to grab the data–Google would return a 403 (Forbidden). So, my thought was to ditch PHP’s file_get_contents for CURL which allows you to spoof a user agent. I took a peek at our apache logs and chose:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

So, instead of looking like a “virus or spyware”, the script now appears, to Google, as an extremely zealous Google Books user. We’ll see how long it lasts, but it seems to be holding…

** Update 3: 8/25/06 11:40 AM **

No go, they’ve blocked us again. I’m sending an email to the kind folks at Google Books, and we’ll see if they reply. Until then, I’ve got a few more tricks up my sleeve… In the meantime, I’ll leave the cached information active…

** Update 4: 8/25/06 4:07:PM **

Google scores major points in my book! One of the managers over at Google Books just emailed me to say that he likes the idea of the hit-list links and that he is going to see if they can accommodate these types of queries.

The new versions allow users to display cover images along with the records. A new option gives you the choice of text only, images only, or images and text. Not a major change, but noteworthy. Also, in case you missed the update in my previous post, the new items gadget can now match subject headings–useful if you want to be notified about new items on a particular topic.

For the purposes of the Talis mashup competition (for the judges), the original xml files are still available under a different name (tops-v1.xml and new-v1.xml). Everyone else, here are the new ones:

• tops.xml
• new.xml

(FYI, it’s the same URL as the previous version. If you’ve already added it to your Google page, the update will be automatic)

While working on this little project, I became painfully aware of PatREST’s limitations when dealing with asynchronous execution — like that of Google gadgets. I previously thought it would be better to limit the amount of data returned in an XML hit-list and use a second record query for and detailed info. I think I may have been a little short-sighted. At any rate, the lesson learned is that the more practical experience I have with PatREST, the more I’ll know what works and what doesn’t.

The upshot of all this is that I’ve expanded the result objects in any PatREST function that returns multiple records to include more information, such as ISBN, cover image, author, and record link. For those asynchronous folks, this will make life a lot easier. The new additions have been added to an updated specification. Existing PatREST applications (I don’t think there are many at this point) will continue to work, of course.

At any rate, he's speaking again tonight at AADL. If you're in the area and have the evening free, I'd highly recommend his talk. From the AADL website:

What does the UM/Google partnership to digitize the UM Library mean; what significance will this have for libraries, researchers and the public; and why is this so controversial? Through this project, UM hopes to guide more users: to their local libraries; to digital archives of some of the world's greatest research institutions; and to out-of-print books they might not be able to find anywhere else--all while carefully respecting authors' and publishers' copyrights. This event is the Library Director's program for 2006.

Each year, AADL Director Josie Parker chooses a current topic of community, state or national concern to highlight at a special program during this national week of celebrating libraries.

His talk will be at the Downtown branch in the Multi-Purpose Room. Regretfully, I'll be missing it due to prior commitments.

[tags] Google, Wilkin, Books, OCR, Ann Arbor, AADL [/tags]