Searching for a Google Search API

on

In his resent post, Daniel Tunkelang was cautiously optimistic about Google’s forays into HCIR, suggesting that Google’s “baby steps” are leading in the right direction. I agree that it would be a great innovation if Google weaned itself (or allowed its users the option) off the single ranked list precision-oriented search paradigm, and made it easier to explore the results in a variety of ways.

But as many resources as it has, Google cannot do everything, and it doesn’t have a monopoly on good ideas. It would be better yet for a variety of stakeholders, not to mention the searching public, to be able to leverage Google’s index in their applications. While the Ajax API is clever and easy to use, it and its RESTful sibling are useless for exploratory search: they are restricted to 32  hits per query and the results cannot be reordered without violating the terms of use. Yet digging into the search results through clever processing rather than requiring the user to page through them manually is one of the keys to recall-oriented exploratory search. The Yahoo! BOSS API recognizes this by offering up to 1000 documents per query, and charging 10 times less per document for this tail.

As things stand right now, Google’s core competency in the search space seems to be its indexing and ranking capability. Yet this is monetized only indirectly through ads. It seems to me that there is an opportunity here to add another source of revenue, this one based on search itself. I am certain there are quite a few startups out there that would rather spend a little cash every month for the right to run queries programmatically rather than building their own index. I know I would.

Share on: 

2 Comments

  1. I absolutely agree. My speculation is that Google’s data structures may preclude the sort of set retrieval access that would be most useful for exploratory search, i.e., that everything is optimized for their flavor of ranked retrieval. But this is sheer speculation; I’m not privy to the internals, and am only trying to reverse engineer based on the functionality they do and don’t provide to users.

  2. Interesting point, but one that could be addressed, particularly since responsiveness may not be the only useful design criterion for exploratory search interfaces.

Comments are closed.