Here’s an interesting post on the Read/WriteWeb (RWW) blog, entitled From Search to (Re)Search, Searching for the Google Killer.
It’s definitely worth reading, and the links within it, like this one where a Hakia guy explains quite articulately why Google is unstoppable, and then unsuccessfully tries to dismiss his own arguments.
I agree with RWW that the Google killer won’t come from:
- One-up feature companies. Engines like Clusty, which add one feature (e.g., dynamic clustering) on top of Google search.
- Vertical search companies. While the long tail is real, I don’t believe there will be a long tail of search engines (that’s the inverse of the concept). People want relatively few tools that can reach into the long tail of content, products, and information. They don’t want a long tail of tools.
- Human search. Unless you’re doing real research, the cost model is prohibitive.
The first time I heard the phrase “research, not search” was from Nerac CEO Kevin Bouley. Kevin’s company provides custom research services using a database of content integrated from numerous sources combined with a network of subject-matter experts (SMEs) who use an MarkLogic-based application to assemble custom research reports for clients. When Kevin says “research, not search” he means it.
Nerac uses MarkLogic as their content repository and have a built an XQuery application that enables SMEs to quickly locate information (using our XML search capabilities) and then combine and package that information into a custom research report. It’s a very cool service, and while I think of it as “research, not search” I certainly don’t think of it as human-powered search a la Cha Cha.
While I believe that from search to research is a good direction, I think there is another equally important direction that the RWW omits: from search to application, or as we say at Mark Logic “content application.”
To me, search is inherently open-ended and context-free. Applications are not. If I know you’re a professor and you want to build a custom textbook, then I can build an application that helps you do that. And yes, that application will probably include search across a corpus of content. But search is a feature in the application, not the application itself.
Or, if you’re a pathologist, I can build you an application that leverages how you work with terabytes of medical content to help you identify cancers more readily. Search might be a feature within that application, but the application itself is about helping support the process of differential diagnosis.
Content applications know who you are and what you’re trying to do. (They’re role and task aware.) And you can build them on MarkLogic. And, in my mind, only a content application has enough unfair competitive advantage to beat Google over time. A thin vertical search layer? A better algorithm? One sexy feature? No.
But an application that knows who you are, what you’re trying to to, and leverages a rich (potentially integrated and enriched) contentbase to do so? Ah, well that’s no fair. No search engine can do that.
And that’s the point.