Searching Summon : a pilot in the faculty of Health

There has been some interesting blog posts recently about the relationship of Boolean and other techniques to discovery tools recently (see for example Library search tools. Could we make them harder to use?) and being involved in a couple of recent pilot sessions in our faculty of Health reminded me of this debate.

One of my teaching colleagues commented ‘You wouldn’t use it [Summon] if someone’s life was at risk’ – true, but there again would you really trust a database front-end to give you what you want? What with the amount of ill-matched content, paywalls to negotiate, openURLs to fail, links aggregated from a third party, relying on eresources to try and save a life would be a risky strategy to say the least – whatever the platform.  But confidence in retrieval is just what, say, a student nurse in our Defence School of Health Care Studies might require.

The pilot sessions we conducted so far bought the expected rash of error messages: a realization that Nexis UK content doesn’t work (all of it – so we have temporarily switched it off), a problem with the Nursing times through Ovid (why did the Nursing Times not have full-text article links but others did – was it because it was weekly?), a ‘Page not found’ for a one journal. We realized for example that an ‘Author’ limiters on the left-hand side only appeared where we had loaded a related MARC record into Summon, and they did not seem to appear with to other resources. The session also gave me a chance to study the Summon interface close up, including what looked like a fairly decent attempt to break it:http://screencast-o-matic.com/watch/cl1qoVHrz !

Summon search log

Looking in the Summon search logs shows a variety of terms entered, many of them keywords aimed a particular specialism :for example one entry shows the search ‘foreign accent syndrome‘.

The real  challenge that Summon brings with it is to traditional information literacy : an academic commented that it was ‘easy to use’ but would be great for undergraduates, who maybe come straight from searching Google but without any of the skills, rather than later years where searching habits need to be more refined. Summon is dynamic, but buries its structure : whereas CINAHL, for example, can be overtly complex but requires more methodical searching.

For example I compared the above two searches for this query ‘foreign accent syndrome :

http://screencast-o-matic.com/watch/cl1YlQHti on CINAHL Ft
http://screencast-o-matic.com/watch/cl1YlfHth on Summon

One thing that immediately stuck me was that the traditional skills of thinking’ about the ‘context’ of the keywords you use still applies, in fact they become even more important with Summon. Another was that the differences are not necessarily about Boolean logic (pace @daveyp and @carolgauld) – both sets of terms are ANDed by default. The differences seem to me to be the level of information that is fed back to the searcher , rather than the technique themselves.

One interface gives you large number of quick results but then requires you to filter, searching across all resources – the other filters first and makes you structure your search. Here I am reminded that we have set up most of our native databases to default to Advanced rather than Basic – did we consult we any students to do this? Did we offer any options? –  the Basic Search screen http://screencast-o-matic.com/watch/cl1Yl0Htl in CINAHL for example, is more ‘googlised’ and closer to Summon’s Basic search.

It would be helpful in my view if Summon unpacked some of its ‘magic box’ – and gave your more feedback as you search (here I think an option to get the instant numbers of searches that you get back from each term as you go along might be useful, to show the results set from each interaction). It doesn’t do itself any favours in the ‘Advanced screen either’ : do students really need a search using an ISBN or ISBN box right up there as a priority? The crucial point however is that the student is more on their own (as they would be with Google), gets results back quicker (even though they have to trim them down more – as with Google). They are using a search engine for *library stuff* that is closer to what they have may have used before they came here.

We are hoping to get more in-depth results from library colleagues in Health who have circulated some student questionnaires so it should make for some fascinating reading…

Super-size EBSCO ?

ebsco sweetieYesterday we had a return visit from EBSCO showing their Resource Discovery solution – along with colleagues from Wolverhampton. It was good to see a live demo and they told us that most of the major publishers were on board – with current exceptions being JSTOR and Proquest Dissertations ; Lexis US Academic (but not yet Lexis UK).

I felt the key question was unanswered though : when we saw the pre-indexed search return interface, one of the limiters was ‘items electronically or physically in the library already‘ : and we wanted to know: how did their Resource Discovery tool know about our subscribed e-collections? Was it from our catalogue (where it took regular updates from) or our link resolver knowledgbase ? EBSCO may well answer this later but I was disappointed they couldn’t confirm where the data was being sourced from. It made think that for all of these products – sorry for the image – ‘opera isn’t over till the fat lady sings’: ie until the user gets to our ‘stuff’.

The quality of the link resolver becomes key – after all Serials Solutions  seem to be building their Summon case on 360 Link, not 360 Search – and the nature of the metadata agreements that allow all this nice sharing of thin and not so thin data between publishers to go on. For the time being EBSCO seem to have got deals with nearly everyone – I just hope they don’t carry their reputation for signing exclusive deals into the resource discovery marketplace.

Also I think their interface looks like it needs to go on a diet…maybe EDS version 2.0 (due out in June 2010) will be a bit more easy on the eye.

image credit :jblyberg

Resource discovery: a new twist ?

cotton twistPreviously we have seen two different solutions to the problem of Resource Discovery:  1) pre-built ‘connectors’ built to allow a federated search across our electronic resources  and 2) a discovery tool that uses metadata that is pre-indexed from the publishers, and also incorporates our local catalogue data. Exlibris say that ideally we would need both solutions; Serials Solutions say that we can run 2) without the need for 1).

I thought the demo from EBSCO last week was interesting as their comments were made from the position of a subscription agent . They cast doubt on publishers’ willingness to open up their data for harvesting – and said that libraries would always need both solutions in place.

What will Innovative say when they come and see us on the 6th November?

image credit: meknits

Resource discovery: demonstration by EBSCO

building bridgesThe 3rd of the demos we’ve organised  from resource discovery system suppliers takes place on Friday October 23rd at 10:30, when EBSCO will be talking about their Discovery Service, together with their federated search tool EBSCOhost Integrated Search

Please come and join us for tea, coffeee, biscuits and another peek at what resource discovery for our students might look like in the future

image credit: alef