Wally Grotophorst, Digital Programs and Systems librarian at George Mason University and customer of this blog’s sponsor Deep Web Technologies, gave the publicly searchable Summon deployment at Dartmouth College a test drive. (Note that while anyone can search and view result meta data, full-text access to documents is restricted to the Dartmouth community. Grotophorst, however, was able to access full-text because his university’s subscriptions overlap with Dartmouth’s.)
I want to highlight a few of Grotophorst’s insights.
Have you heard the old adage “cheap, fast, or good – pick two?” I’ve heard it in the context of building software systems. If you can build something inexpensively, quickly, and with high quality you can’t get all three at the same time. As an example, if you want to build a major system quickly and you want it to work really well then it won’t be cheap. Grotophorst applies this idea of tradeoffs to search.
If you’ve ever looked into digital storage solutions, you’ve probably heard that you can achieve any two of these three attributes: speed, reliability or economy. Build a system that’s fast and reliable and it won’t be inexpensive. Develop a reliable but inexpensive solution and you’ll sacrifice performance. … Web-based searching’s not all that different, you have to balance a set of sometimes conflicting attributes.
Consider the notion of “Just-in-Case.” Build an index of content (e.g. Google), the bigger the better, just in case someone wants what you have.
It’s fast but you are sacrificing currency (reliability) of information. You can retrieve an item only if it was collected and indexed prior to your query. If it just appeared on the web, it’s invisible to you.
Now consider “Just-in-time.” Get the user what he or she wants at search time via federated search:
Make a query and the search engine sends out simultaneous real-time requests to other hosts, bringing back content and presenting it. You’re giving up speed to improve reliability (currency) of information.
I like this view of tradeoffs because it gets us past the pissing match of which approach is better. Do you want speed (discovery service) or currency (federated search)? Your answer is different depending on your users and their needs.
Grotophorst elaborates on what makes Summon compelling and lists some tradeoffs. One big tradeoff caught my eye:
The library moves from an open gateway model to something more closely resembling a walled garden
Here’s an interesting metric to determine “enthusiasm” for Summon.
- If you worry most about helping the user who asks, “find me something useful” then Summon™ is a winner.
- If your job depends on satisfying the user who asks, “find me everything” or “is this absolutely current?” then Summon™ is just a distraction.
Tags: federated search