We’ve made Summon (branded as CityLibrary Search) our primary discovery route via the Library’s homepage, which I suppose is as near as we’ll get to a formal launch of Summon 2.0, so here’s to it!
It’s been a long while since we’ve updated this blog, and we have made significant progress in implementing Summon. We even have a name for the service, CityLibrary Search, which trips off the tongue nicely! There is a big milestone looming for us at the moment, the go-live date, which is (currently) the end of August, when we will make Summon the primary search tool via the Library’s home page. More on this when it happens.
In the meantime, I thought I would write about one of the thorniest problems we have been trying to deal with. This is the issue of “known database searching” using Summon. The idea here is that it is sometimes (often?) the case that users are uninterested in performing a full pre-indexed federated search, and instead just wish to get to a specific database. For example law students are likely to want quick access to one or both of the two big legal information databases, Westlaw and Lexis Library. This is borne out by user behaviour: we see a large number of searches for known databases in our current library catalogue, Encore.
Therefore it is important that any discovery service (or indeed library catalogue) can provide quick access to any given named database. Encore does a pretty good job at doing this- see for example this search for Westlaw, where said database comes up top of the list of hits, with a prominent link through to the database itself. Summon is, I would argue, less good on this score. A search for Westlaw comes up with lots of hits. At the top of the list is a “Recommendation”, which is a link through to Westlaw, but in my view the link is not particularly prominent, and it is also not very clear that the link will take you to that database. The rest of the regular Summon hits are, essentially, noise- a variety of articles that happen to mention Westlaw in some context or another, but which certainly won’t provide an authenticated link through to the database itself. Summon does have a “Database Recommender” function, but this seems to be erratic in its operation, for example throwing up irrelevant recommendations.
So, what is to be done? Our current thinking is that we will upload our Millennium LMS Electronic Records Management (ERM) records (a tautology I know!) to Summon, and class these as databases which are “our own” content, which will hopefully push the database records up the hits list. You can see an example of the ERM record for Westlaw in Summon here– the problem is that currently you have to specify the facet “Database” to be able to retrieve the relevant hit, something that few if any users are likely to do. Using ERM records will also allow us to specify alternative names for databases- to use the Westlaw example again, Westlaw does much better when searched for in Summon using its “real” name, Westlaw UK (see hit number two).
Another possible approach (perhaps to be done in tandem with the ERM records approach above) will be that taken by the Queensland University of Technology’s Summon implementation. They have uploaded their Libguides A-Z list as structured XML into Summon’s index as local holdings. This appears to do a good job of creating database links, though they seem to be categorised as “Web resources”, not as databases proper. You can view a presentation on this approach here (requires a Google Drive log-in).
So, the short version: it’s complicated, but pretty vital to get right. We don’t want to try to direct users to Libguides whenever they need access to a database because (as user behaviour stats show) they legitimately expect to be able to access databases via Summon itself. I’ll follow this post up if and when we have found a satisfactory solution.
I’m pleased to announce that we have opened up our installation of Summon here at City to public beta testing. If you want to have a look at our install you can do so here:
Please bear in mind that we’re still very much at the testing stage, so things are likely to change, and we can’t guarantee the service will always be online (though we’re confident it’s pretty stable!) If you have any feedback, we’d love to hear from you: please email email@example.com
The next announcement we make is likely to be the name we have come up with for the service, watch this space for that exciting piece of news!
Neil’s previous post mentioned the idea of trying to provide a ‘Google-style search’ for accessing library resources, something which has been talked about a lot over the last few years. What often isn’t discussed, or not in detail, is what we actually mean by this. Does ‘being like Google’ just mean having a single search box instead making the user choose which type of search they want to perform: Title, Author, ISBN, Subject etc? Or is there more to it?
Aaron Tay’s excellent blog post How is Google different from traditional library OPACs and databases? discusses some of the key issues.
Some of the things that Google does but (most) library catalogues don’t do are:
Auto stemming – that is, a search for ‘run’ will include results for ‘running’ and ‘car’ will also find ‘cars’
Auto correcting – if you search Google for ‘librar opacs’ it will change your search to ‘library opacs’
Soft ‘and’ – occasionally Google might drop one or more of your search terms
Auto complete – it suggests search terms as you are typing
We may not always like the way Google sometimes interprets and alters our searches but it is what most of us are now used to. It can be quite baffling to someone who grew up with Google when their search in the library catalogue for “charles handy new alchemist” does not find the book “The New Alchemists” by Charles Handy.
So how much of this Google-like searching does Summon do? My initial tests indicate it can do some of these things but it doesn’t go nearly as far as Google.
Summon does not auto correct my search terms though it does suggest alternative searches to try. However it only suggests alternative searches if my search finds zero results. My search for ‘Milly Moll Mandy’ sadly neither autocorrected nor offered the alternative search ‘Milly Molly Mandy’, because it found one result that matched my mistake.
It has a good auto complete function – start typing and lots of suggestions are offered.
Summon has at least some stemming ability- my search for ‘charles handy organisation’ happily found alternates ‘organisations’ and ‘organization(s)’.
As far as I can tell it does not attempt a ‘soft AND’ and drop any of my search terms.
Thus far we’ve tried to explain the general idea behind modern resource discovery products like Summon, as well as why we chose Summon here at City. But what benefits does Summon bring to library users, above and beyond the various ways of finding information already available?
The answer to the question above lies in my use of the phrase “various ways of finding information” above. The problem for library users is that, up until recently, there was no way of searching across everything the library provides access to. “Everything the library provides” in this context can include (but is not limited to):
- The contents of the library catalogue (hard copy books of course, but also potentially all sorts of other media e.g. musical scores, theses, DVDs, LPs, CDs etc. etc.)
- Journal articles
- Abstracting & Indexing databases (e.g. Scopus, Web of Science)
- The contents of the institutional repository
- Archives catalogues
- Databases of newspaper articles
Summon tries to solve this problem by building a single index of the library’s holding, and then crucially allowing library users to search across that index in a single place. So, instead of having to first go to the library catalogue to find books, e-books and e-journals at the title level then (say) Scopus to find individual articles, then (say) to the Archives Catalogue to find relevant archival material, users can run a single search that will find relevant material from all these sources of information.
Furthermore, Summon is set up to provide good results from the prevalent “Google search style”. The idea here is that (for better or worse) users are used to searching Google by plugging in a few key words then hitting go and seeing what comes up, then modifying the search to refine the results. This is certainly the way I search when I use web search engines, at any rate, and studies have shown that this is how the so-called Google Generation goes about things too! Summon’s relevance ranking and the ability to “facet” your search results are crucial here, and we will write more on this at a later date once we’ve had a chance to analyse it further.
So there are in our view two main advantages to Summon:
- Search in one place for everything; get useful results back.
- Use simple keyword searches as you are used to doing with web search engines; get useful results back.
Of course, in reality it’s arguably not as unproblematic as we have perhaps made things seem. In particular, when we say “search everything”, does Summon really allow us to search “everything”? Or is it actually some sub-set of “everything”? And is simple keyword searching actually the best way of finding scholarly material? And given the simplicity of searching for material using Summon, what then for users’ information literacy? These are all questions that bear further examination, and we will look at them (as well as some other perceived weaknesses with web-scale discovery) in later posts.
Lucy’s previous post gave the background as to why we and other academic library people think resource discovery tools are potentially useful tools for library users. This post reflects on the decision-making process that led us to choose Summon over other available products.
The first thing to say about the process is that it was hard, particularly in negotiating the politics that often come into play when proposing any relatively major change in systems! There was a feeling amongst library managerial staff that a resource discovery tool would in principle be useful and cost-effective, but that feeling was by no means a general one. Some members of library staff (and particularly subject specialists) had quite legitimate concerns about the coverage of discovery tools in general, and of Summon in particular. Discovery tools do well for coverage of STEM subjects, but (arguably) less well with Arts, Humanities and Social Sciences, and there are a few subjects (notably law, a significant area of study here at City) which have gaps in coverage. I won’t write more about these issues at the moment,but they are ones we will return to in future posts.
Once we had decided that we wanted a resource discovery tool, the next question was, which one? We decided to limit the scope of the procurement decision-making process to the current generation of discovery tools (new tools are on the horizon already) which for practical purposes meant choosing between Summon, Primo and EBSCO Discovery Service (EDS).
We started off by visiting a number of institutions (LSE, Middlesex, Brunel) who have recently implemented discovery tools, not so much to see the tools in action (though that was of course interesting) but to get an idea of how they decided between the tools they considered and to find out how they managed the procurement and implementation processes. These visits were invaluable, not least to reassure ourselves that a lot of the issues we were considering were not unique to us. Running parallel to this, we invited each supplier in to present on their product, also inviting a number of colleagues to these demonstrations. This gave us an idea of the functionality and relative strengths and weaknesses of the products.
After the demonstrations, we invited colleagues to vote on their preferred option. We offered the following options:
- I prefer Primo
- I prefer Summon
- I prefer EDS
- I think we should get a discovery tool, but I have no clear preference
- I don’t think we should get a discovery tool
We also invited feedback on the various products and on the reasons for or against getting a discovery tool. The results of this exercise saw a clear majority in favour of getting a discovery tool, but no overwhelming majority in favour of any particular product (though for the record Summon did get most votes).
The final stage of the process was to do a detailed analysis of the functionality of each product, as well as other important factors such as cost and fit with current systems. The result of this analysis (as you might be able to guess) was that Summon was the preferred choice. We felt that Summon and Primo offered pretty similar functionality, but that Summon was clearly a better fit with our current systems (we use Serials Solutions’ knowledge base 360 Core) as well as being priced lower than Primo. We felt that EDS did certain things well (not least exposing EBSCO’s own large dataset of publications), but that it didn’t offer true pre-indexed federated search. We then took a paper to the Library Executive team, who passed the paper.
So now all we have to do is implement Summon!
The library has recently chosen to implement the Summon web-scale discovery service. In this first blog I’ll talk about what Summon is and a bit of the history behind its creation.
One of the problems libraries have been trying to solve for some time is how to make it easier for their users to find information. A university library will usually subscribe to a large number of web based resources including reference databases, abstract and indexing resources, journal bundles and individual e-journals and ebooks. This provides library members with an enormous wealth of information but the sheer number of resources can make the task of finding information incredibly confusing. Where do they start looking?
The first technology created to try and solve this problem was federated (or broadcast) search. A federated search builds connectors to each individual database the library subscribes to and will simultaneously search every database and return results. In theory this sounded great, exactly what we needed. Unfortunately the reality of federated search products did not live up to expectations. Problems with federated searching are well documented. These include slow response times from databases; lack of relevancy of results; clunky interfaces; results are not interfiled, so to view results from all databases search you need to scroll through several pages; the need for constant maintenance to fix broken connectors- I could go on.
In 2009 Serials Solutions decided to try a different approach to this problem and started work on Summon. Instead of using broadcast search to send your search to multiple different databases then try to make sense of the results returned, they decided to pre-index as much information as they could and build one huge central index containing fully indexed articles, abstracts, ebooks etc. This approach has a number of advantages. Searching is much faster. It allows for much better relevance ranking. Summon knows what subscriptions your library has so it can return only results which will result in the full text.
Does Summon deliver on this promise? It certainly has some enthusiastic supporters. We will soon be able to put it to the test.