Oct
Jonathan Rochkind authors the Bibliographic Wilderness blog. Last Friday, Jonathan discussed some of the technical and other problems he saw with federated search today and he even created a mock up of a “feasible search portal,” which Jonathan explains as follows:
This seems to me like the best feasible present-day plan to integrating other useful searches into a library provided search portal.
I don’t completely agree with Jonathan’s assessment of some of today’s limitations; I believe that there are vendors and integrators who could give Jonathan more of what he wants than he thinks he can get, but the custom work might not come cheap. What I’d really like to do today is fantasize about what I think it would take for Jonathan’s dreams to come true.
Here’s Jonathan’s dream:
We can fantasize about the type of search interface we’d want. It would include all the sources we’d want, but would still let users limit to just books or just articles[1], or include full text searches (when some sources include full text) or search just metadata only, picking from a wide range of fielded searches combined with full boolean expression power. The relevancy ranking, merging results from different sources, would be fabulous, especially when they chose not to pick a particular field and just search ‘google style’. It would have a quick response time. It would Just Work.
Here’s the perfect world:
- All sources Jonathan wants are easy to build connectors for because all vendors provide easy-to-use APIs for adults and an even easier approach for kids. (See #2.) Only scholars of early federated search technologies even know what screen scraping might have been like.
- Young children, like my 7.5 year old niece Zoe, are building connectors because vendors and content providers have come together in a happy partnership that makes building connectors “so simple that even a child can do it.” And, the kids are helping out the “old folks” who grew up with screen scraping, HTML, XML, and other buzz words.
- All content publishers tag their content consistently and accurately to allow for searching different document types (e.g. books, articles, journals) and they also tag the few remaining ancient records that don’t provide full text access.
- Content publishers all pride themselves on providing beautifully crafted metadata that describes each of their documents perfectly.
- Search results stream instantly and effortlessly to all federated search engines, thanks to super-fast computers and super duper high speed networks. “Latency” and “throughput” become bits of ancient jargon that only historians care about because they don’t affect our perfect environment.
- Relevance ranking is, of course, perfect. All vendors agree upon a common set of standards for ranking. Life is good.
- With all vendors ranking their own content oh so perfectly, merging of results from different sources becomes a trivially simple exercise.
- Now that speed and performance are only historical concerns, we can apply the most hideously complex Boolean logic to our searches.
- It’s been years since people whined about how slow federated search was. No one is begging content publishers to provide indexes of their documents because the whole federated search experience just reeks of sheer speed.
- When 7.5 year old Zoe gets bored building connectors and playing online Webkinz games she builds federated search applications. She’s able to drag and drop sources, lay out results pages, create panes with results from individual sources, pick the search and display fields, and color the whole application pink. It’s all “child’s play.” And, if Zoe gets stuck, like if she’s not able to decide on what shade of pink to use, her 9.75 year old sister Kayleen can help.
Yes, they (federated search vendors, their happy customers, and the cooperative content publishers) lived happily ever after.
Have I missed your favorite way in which federated search becomes wonderful? Do tell.
If you enjoyed this post, make sure you subscribe to the RSS feed!
Tags: federated search
