A couple of metasearch reports have been recently released. One, carried out as part of an NSDL project at the California Digital Library, proposes 'approaches, principles and practices' which might be applied by anybody evaluating integrated search options [pdf]. The second, the RLG Metasearch Survey Report, discusses member experiences and expectations with metasearch. Roy Tennant, one of the authors of the former, comments in the latter on hangingtogether.org.
The reports raise many issues, especially when laid alongside a more general discussion about how library services are presented to users. To this I will return; in the interim, a few remarks on metasearch:
Metasearch has come onstage in a big way in the last couple of years: there is now a variety of products available and many libraries are implementing them. However, the concepts, technologies and approaches that they adopt have been in currency for many years. Index Data and Fretwell Downing, amongst others, for example, or indeed OCLC with SiteSearch, have many years of experience deploying metasearch approaches. There is also quite a record of discussion of some potential features: creating an individualized 'landscape' based on some match between a representation of user interests and a representation of collections and services available, alerting, metadata schema and terminology merging, deduplication, forward knowledge based on collection description or an index and so on. What has changed most over the years is the emergence of the Amazoogle search experience and the recognition that fragmentation reduces the gravitational pull of library resources. The renewed emphasis on metasearch is one response to this - and the NISO Metasearch Intiative responds to a recognition that despite several years of deployment it needs to work better. How do you avoid some of the current inefficiencies of interaction which make life difficult for the data provider and the metasearch application supplier?
How to explain this lack of progress over the years? There seem to be social or business factors delaying forward progress: what incentives are there for parties to change or improve the situation? One major incentive for the library is clear, and was mentioned above: to reduce fragmentation and increase gravitational pull for the user. At the same time, Ben Toth points to a counter-trend in a comment on another post.
I know it's a bit of a generalisation, but professionally we've had little incentive to simplify search experience for users and quite a lot of incentive to emphasise the complexity and mystery surrounding search.Various library activities are indeed bound up with that complexity. And he goes on to touch on data provider incentives
One brick in the wall
Metasearch is not an end in itself, although we sometimes talk about it as if it were. The aim is to provide search services at the level of database combination that makes sense for the user, to provide guidance on those combinations, and to present the services in ways which make sense in user environments. This last point is important; one may want to present a metasearch service as a web page, as a box in a reading list or course page, as a machine interface which other applications talk to, and so on. Metasearch, like all other library services, will be part of an eco-system of services. One can talk of its place in the discover-locate-request-deliver chain, and we have seen much work of late providing integration with resolution and fulfilment services of various kinds, so that the user can move from discovery to fulfilment in a more streamlined way. Increasingly, we may want data to flow more easily (to work with reference/citation managers), or to mix metasearch capacity into particular environments (a course apparatus is an example). In some cases, a search may bring back updated results against a particular stored query. Some users might like to the ability to set up searches whose results can be viewed in their RSS aggregator. And so on. Search - and metasearch - is a part only of what a library user wants to do - it needs to be integrated into a variety of workflows.
Now, in the last section, I may have been a touch heavy on the qualification. This is because of the difficulties involved in providing some of these services effectively, and the lack of progress I noted over recent years. It is for this reason that I wondered a while ago if it might make more sense to attack the boundary issue differently, by working on business and technical approaches which would result in fewer, larger resources to search. This would reduce the complexity of boundary spanning by pushing data integration and other issues upstream. At the cost of putting more burden on the search system to make discriminations that have been lost. It does also raise the question of how much difference is useful. This would require significant change in how we currently manage the data supply side, but we are living in a time of significant change.