Additional observations about unified discovery services

A few months back, I wrote about the difference between federated search engines and unified discovery services. As you may have heard in July, my place of work (Grand Valley State University) is the first commercial adopter of Serials Solutions’ Summon.

My coworkers and I have been working with Summon over the last few months, and I have a few additional observations about how it’s different from federated search:

• One does not have a choice about the content in a discovery service. Serials Solutions has made agreements with various content providers; our content is limited to what those vendors provide. Federated search is also limited, but perhaps not quite so much: federated search engines gather content through database “connectors.” If there’s no connector to a particular resource, that resource can’t be included in the federated search. My impression is that there does seem to be a bit more freedom and flexibility with federated search; libraries can choose how many databases they want included in their search, and which databases they want included.
• To my knowledge, only one index can be searched through Summon. With federated search, you have the capability of creating a variety of searches. You could, for example, create a search that only retrieved information from geology databases. With discovery services, you search all of the content all of the time.
• Because you’re working with a single index, there doesn’t seem to be a way to tell which source a particular search result has come from. For the sake of conversation, let’s say Philosopher’s Index (which is an index; no full text) is included in Summon. Say my place of work subscribes to a philosophy journal indexed in Philosopher’s Index, and that we have the full text of that journal in an Ebsco database. Our user searches Summon, and finds an article from this philosophy  journal. Summon points our user directly to the Ebsco database – Philosopher’s Index doesn’t show up anywhere in the search results. This could cause two problems:
  • It could throw off your database statistics. Maybe our users find the data that has been included from Philosopher’s Index particularly useful, but currently, there doesn’t seem to be a way to discover that. (Unsurprisingly, this was a concern brought up by our collection development librarian.)
  • It limits discovery of specific databases. Using the example above, our user will never encounter Philosopher’s Index through Summon. When the instruction librarians my place of work taught federated search, we thought of it as a discovery tool. The user could benefit by noting that several useful search results were coming from a single source, and then the student could go directly to that source to do further searching. (I admit I don’t know how often this actually happened.)

Now, these all seem to be drawbacks, but I’d like to make two caveats:

1. With the exception of my second point above, these all seem to me to be very “librarian” issues. Yes, they will effect the user – but are these things that most of our users are going to care about? Honestly, I don’t think so.
2. As I noted above, my place of work is the first commercial adopter of Summon. To my knowledge, Ebsco’s discovery product isn’t live yet. My point is that discovery services are still a pretty young technology – there’s a lot of potential for improvement and change in the coming months (and years).