Metasearch Engines
The following is a discussion of three cross-searching systems: Ex Libris’s MetaLib, Google Scholar, and the open source LibraryFind. The comparison is not meant to be a comprehensive analysis of any search apparatus, but is meant to point out the differences between metaseach and federated search, and some of the inherent problems and advantages of each.
Ex Libris MetaLib
Ex Libris’s metasearching solution “MetaLib†is a popular metasearch solution. According to Tamar Sadeh (2007) “well over 500 institutions have acquired the Ex Libris MetaLib system since 2001†(Metasearching and federated searching section, para.6). MetaLib is a comprehensive metasearching engine that “provides a consolidated search environment for remote information resources, helping users find the information they need quickly and effectively. MetaLib streamlines the discovery process by presenting users with content from multiple information providers in one clear, familiar user interface†(2007, Ex Libris, para. 2). I chose MetaLib because it is commonly used and there are several articles that describe its use and user testing.
MetaLib works as other library metasearching applications do- it creates links to a library’s local holdings and subscriptions, allowing users to access materials through a common search engine. Like other metasearch engines, MetaLib allows librarians the opportunity to customize the interface and tweak search results. Librarians can set custom searches for specialize populations. Some of the unique qualities of MetaLib include two workflows, one for beginning and one for advanced searchers. MetaLib also allows the user to save a search results and sets of databases.
There have been several usability tests of MetaLib. As usability test often do, they mainly showed the problems in the MetaLib interface, like the confusing behavior of the back button: “Many students tried to navigate using the browser back button, which in most cases did not work in MetaLib†(2007, Haya, Nygren, & Widmark, Discussion section, para. 3). More serious misunderstandings centered around the way MetaLib handles multiple word searches:
“The most common misunderstanding centered around multiple word searches which were most often interpreted as an exact phrase by MetaLib whereas students clearly expected that multiple words would be treated as an “AND†search by default. A typical example of this was a student searching for “telecommunication developing countriesâ€, which yielded null results. Had the student instead typed in “telecommunication AND developing countries†he/she would have found more than 200 results†(2007, Haya, Nygren, & Widmark, Phase analysis section, para.10).
Another difficulty centered around the difference between the beginning and advanced search capabilities. Some students thought the name of the beginning search, “QuickSearch†meant a fast search. The advanced search, called “MetaSearch†was confusing to some students as well (2007, Wrubel & Schmidt). Speed of the system was an issue as well. In one test, out of eight students, “five found the system too slow†(2007, Haya, Nygren, & Widmark, Discussion section, para.5).Despite the problems with MetaLib, it remains of of the better solutions available to librarians. It may be that considerable tweaking and testing may be needed to make the system easy to use for the local population, but at least librarians can adjust and include all paid for content. As Glenn Haya, Else Nygren, and Wilhelm Widmark (2007) write: “One very positive aspect of MetaLib is that it searches in “real†databases and one can clearly see which sources one is searching. This can be seen in contrast to a tool like Google Scholar where the sources searched are unknown or incomplete†(2007, Haya, Discussion section, para.5).
Google Scholar
It is difficult to write about metasearch engines without a discussion of Google Scholar. A relatively new addition to the cross-database searching market, Google Scholar does what other searches cannot- fast, easy searching with excellent ranking capabilities. Students have started using Google Scholar frequently, which has prompted librarians to step up their metasearching efforts.
The drawbacks of Google Scholar to librarians are quite clear. It can be difficult to discern exactly the source of an item from Google Scholar, while materials found in a library owned metasearch are always from a library resource. “We are not sure how Google evaluates what it finds and what criteria it uses for categorizing materials as scholarly or not, except for the obvious cases in which it harvests publishers’ sites†(Sadeh, Google Scholar: pros and cons searching section, para.7). Another problem is that results are returned in relevance rank order only- one cannot re-order search results in other ways.
The most glaring problem is that one never knows exactly the sources that Google Scholar will search. This is a problem because Google Scholar misses resources available in the library. Tamar Sadeh explains:
“When a user knows exactly what he or she is looking for, the partial coverage problem is less serious because the person is aware that the item is missing and can check other databases, such as those that are targeted to the user’s area and are more up to date. However, when users are looking for content without knowing which articles, books, or other materials have been published in that area, they might miss valuable information by relying solely on Google Scholar†(Sadeh, Google Scholar: pros and cons searching section, para.6).
There is also the question of how, exactly, Google plans to make money on Google Scholar.
Despite the obvious (to librarians) problems, students still like and use Google Scholar. The reason is simple- unlike library metasearch engines, users get results quickly, in a simple interface. Many undergraduates don’t see the need to reorder their results or to evaluate where each article came from, they just want quick results. Google Scholar delivers this. Google Scholar has an obvious advantage in terms of speed: it is an example of “just in case†or federated searching, where the results are pre-processed for quick delivery. As previously discussed, this is something that libraries are not yet able to accomplish. However, as a result of Google Scholar, more database companies are seeing the advantage of providing metadata. “Google Scholar may well be the catalyst that makes it possible for libraries to get access to licensed full text and metadata†(2007, Rochkind, Can libraries get the content? section, para.1).
Jonathan Rochkind sums up the current situation with Google Scholar succinctly:
“If Google Scholar were perfect (and we didn’t mind having only a single source of metasearch service), most libraries wouldn’t need to provide metasearch. The most obvious and frequently cited problem with Google and Google Scholar is the lack of exhaustivity: you can’t know precisely what the Google index includes and what it leaves out. There’s no guarantee that all of your library’s expensive licensed content, which you want to make sure users can find, is included in Google Scholar†(Rochkind, If Google is doing it… section, para.1).
However, Google Scholar is a useful counterpoint to the sometimes slow, bloated and complicated metasearch engines employed by libraries. Hopefully one day libraries and vendors will be able to strike a nice balance between simplicity and complexity in a metasearch engine.
LibraryFind
One possible alternative to a vendor supplied metasearch engine may be an open source solution, which now exists in a product called LibraryFind. Under development by Oregon State University (OSU), LibraryFind is also being used by the University of Houston (2007, Tennent, para. 2). LibraryFind implements many desired features, such as a two click workflow, caching for faster speed (especially on subsequent searches), and an integrated OpenURL resolver (2007, Tennent, para. 5).Roy Tennant (2007) cautions that “LibraryFind is not (yet) a shrink-wrapped application—that is, it still takes someone with experience at installing UNIX software to configure and load it, though set up may become easier. Also, the number of preconfigured resource connections remains small, so any adopter of LibraryFind with needs beyond the included connections will have to set up new connections†(para. 9). However, as more libraries begin to use LibraryFind, more programmers can contribute to the code base, and the product will improve. LibraryFind will be one metasearch engine to keep an eye on in the coming years.
kmd :: Nov.27.2007 :: Uncategorized ::