Comments on: Still Waiting for a Real Google Book Search API http://www.dancohen.org/2008/03/31/still-waiting-for-a-real-google-book-search-api/ Covering the intersection of digital technology and research, teaching, and learning in the humanities, including search, data mining, website development and design, and programming. Mon, 13 Oct 2008 09:41:29 +0000 http://wordpress.org/?v=2.6.2 By: Towards a “History This” Command Line « history-ing http://www.dancohen.org/2008/03/31/still-waiting-for-a-real-google-book-search-api/#comment-2561 Towards a “History This” Command Line « history-ing Sun, 07 Sep 2008 04:01:53 +0000 http://www.dancohen.org/2008/03/31/still-waiting-for-a-real-google-book-search-api/#comment-2561 [...] 1) Quality, standardized digitization of source materials combined with quality, standardized open API’s. Dan Cohen has great arguments for the importance of a digitized collection like Google Books not only having an API, but having a good one. [...] [...] 1) Quality, standardized digitization of source materials combined with quality, standardized open API’s. Dan Cohen has great arguments for the importance of a digitized collection like Google Books not only having an API, but having a good one. [...]

]]> By: Stephen Rhind-Tutt http://www.dancohen.org/2008/03/31/still-waiting-for-a-real-google-book-search-api/#comment-2120 Stephen Rhind-Tutt Tue, 01 Apr 2008 20:24:08 +0000 http://www.dancohen.org/2008/03/31/still-waiting-for-a-real-google-book-search-api/#comment-2120 Much as I’d love to see Google make a high functionality API available I imagine (but I don’t know) that the question they’re facing is what and how much they should charge for vs. what they should make free. No other organization is close to Google in terms of the size of published print content they’ve digitized. Moreover, the arrangements they’ve struck with many (but not all) publishers gives them unlimited rights to data mine, create machine aided indices and analyze the content. This makes a high functionality API to their content an extremely valuable asset. They could monetize it in any number of ways. For beginners they could simply charge for searches done through the API – much as they do currently on their map service. Further on, they could create or enable the creation of any number of for fee or advertising supported services ranging from improved search to fact checking. That’s why I think we can expect them to proceed slowly and carefully, experimenting as they go. My sadness is that for publishers and librarians they’re holding back a great deal of value that might otherwise be unleashed as they delay. Much as I’d love to see Google make a high functionality API available I imagine (but I don’t know) that the question they’re facing is what and how much they should charge for vs. what they should make free.

No other organization is close to Google in terms of the size of published print content they’ve digitized. Moreover, the arrangements they’ve struck with many (but not all) publishers gives them unlimited rights to data mine, create machine aided indices and analyze the content. This makes a high functionality API to their content an extremely valuable asset. They could monetize it in any number of ways. For beginners they could simply charge for searches done through the API – much as they do currently on their map service. Further on, they could create or enable the creation of any number of for fee or advertising supported services ranging from improved search to fact checking.

That’s why I think we can expect them to proceed slowly and carefully, experimenting as they go. My sadness is that for publishers and librarians they’re holding back a great deal of value that might otherwise be unleashed as they delay.

]]> By: Douglas Knox http://www.dancohen.org/2008/03/31/still-waiting-for-a-real-google-book-search-api/#comment-2115 Douglas Knox Tue, 01 Apr 2008 03:13:52 +0000 http://www.dancohen.org/2008/03/31/still-waiting-for-a-real-google-book-search-api/#comment-2115 Yes to all this, there's a long way to go. Even without full-text access to public domain materials, looking just at the basic book info, the API is designed to be a one-way street. Given an ISBN, LCCN, or OCLC number, the API will map it to a Google ID, but to go the other way you have to screen-scrape, as Zotero does. But in the future, could we imagine the distributed Zotero platform saving at least these ID linkages as the Zotero screen-scraper or the Google API is invoked, book by book, and building up something useful over time, either in each Zotero installation or contributed to a central pool with user consent? Not enough for text mining, but could be helpful with bibliographic lists including syllabi. Yes to all this, there’s a long way to go. Even without full-text access to public domain materials, looking just at the basic book info, the API is designed to be a one-way street. Given an ISBN, LCCN, or OCLC number, the API will map it to a Google ID, but to go the other way you have to screen-scrape, as Zotero does. But in the future, could we imagine the distributed Zotero platform saving at least these ID linkages as the Zotero screen-scraper or the Google API is invoked, book by book, and building up something useful over time, either in each Zotero installation or contributed to a central pool with user consent? Not enough for text mining, but could be helpful with bibliographic lists including syllabi.

]]> By: Dan Cohen http://www.dancohen.org/2008/03/31/still-waiting-for-a-real-google-book-search-api/#comment-2113 Dan Cohen Tue, 01 Apr 2008 00:08:22 +0000 http://www.dancohen.org/2008/03/31/still-waiting-for-a-real-google-book-search-api/#comment-2113 A good point, Jonathan. It reminds me of Google's deprecation of their original SOAP API for Google Search, which allowed for serious data mining of Google's web cache, in favor of their new AJAX Google Search API, which restricts what you can do with the API. On their other APIs, Google actually allows some portability of their content, such as the recent maps API addition that allows users to put slices of Google Maps on their own site. A good point, Jonathan. It reminds me of Google’s deprecation of their original SOAP API for Google Search, which allowed for serious data mining of Google’s web cache, in favor of their new AJAX Google Search API, which restricts what you can do with the API.

On their other APIs, Google actually allows some portability of their content, such as the recent maps API addition that allows users to put slices of Google Maps on their own site.

]]> By: Jonathan Rochkind http://www.dancohen.org/2008/03/31/still-waiting-for-a-real-google-book-search-api/#comment-2110 Jonathan Rochkind Mon, 31 Mar 2008 21:27:13 +0000 http://www.dancohen.org/2008/03/31/still-waiting-for-a-real-google-book-search-api/#comment-2110 Note also that the Google Book API is designed to be called only from Javascript running in a browser (AJAX style). Google does not reccommend or support (or really neccesarily allow) making this call from a server application--if you try, you may or may not run into Google rate-limiting defenses. This further limits the usefulness of this API even for those modest goals. You say "The result is that this API simply seems like a way to drive traffic to Google Books", which is of course not TOO surprising coming from a commercial entity. But, "rather than to help academia or to foster a external community of developers, as other Google APIs have done."--I'd think that other Google APIs are ALSO intended primarily to drive traffic to Google's services, no? Note also that the Google Book API is designed to be called only from Javascript running in a browser (AJAX style). Google does not reccommend or support (or really neccesarily allow) making this call from a server application–if you try, you may or may not run into Google rate-limiting defenses.

This further limits the usefulness of this API even for those modest goals.

You say “The result is that this API simply seems like a way to drive traffic to Google Books”, which is of course not TOO surprising coming from a commercial entity. But, “rather than to help academia or to foster a external community of developers, as other Google APIs have done.”–I’d think that other Google APIs are ALSO intended primarily to drive traffic to Google’s services, no?

]]>