Using api from Summon or Primo only gives you certain flexiblity. You
can change how the page _looks_, but you can't easily provide entirely
new features.
We thought we could do better/cheaper (taking into account both staff
time and product costs) at getting the interface to best meet our users
needs with a local Solr solution, based on Blacklight, so that's what we
did.
But definitely the big downside of that is that we don't have article
search in a local Solr solution. (In fact, we embarked on our Blacklight
solution originally before either Summon or Primo existed -- would we
have made a different decision later? I am not sure, but I still think
we've ended up with a better product than we could have gotten with the
'api' from Summon or PrimoCentral, and without tying ourselves to a
particular vendor prdouct).
So trying to 'merge' results ourselves locally would be one approach.
With it's own plusses and minuses. Providing side-by-side and/or
'seperate tabbed' lists is a lot more feasible. Although still requires
paying for Summon and/or PrimoCentral, to have access to the api....
unless there's a free alternatative that exists or becomes available
(Mendeley? Google Scholar decides to provide an API? Someone else comes
up with something?).
On 3/29/2011 3:05 PM, Steven Morris wrote:
>
> In a similar vein, NCSU's Quick Search keeps "articles" (from Summon) and "books and media" (from the catalog) as separate, side-by-side result sets, along with results from other less prominent silos like Best Bets, journal list, database list, FAQs, and web site results. Although the search tool can often provide immediate gratification by way of the abbreviated result sets for each silo, another objective is stealth instruction: using taste results to help the user navigate our silos and decide which to dive into for further searching, to then take advantage of whatever advantages (functionality, etc.) the silo-specific discovery environment has to offer.
>
> Like Demian said, this is a situation that will have to be frequently revisited. It's not out of the question that we would consider merging search results in the future, although we would still have to have a separate means to handle the roughly 20% of user search clicks that currently land in result sets other than "articles" or "books and media".
>
> Steve
>
>>>> Demian Katz<demian.katz_at_VILLANOVA.EDU> 3/29/2011 9:47 AM>>>
>> Are people expecting that they can do much better by combining the
>> results themselves?
> Villanova's decision to keep local holdings out of Summon and present two lists separately in our VuFind instance was influenced by the sense that searching for book-like items in our physical location and article-like items in our electronic holdings were two distinct tasks, and merging them into a single list would potentially bury useful results in a sea of noise. Providing two side-by-side lists gives the user all of the options at a glance while also making it clear that they can hone in on one type of search or the other. We also wanted to retain the benefits of custom relevance ranking in our local VuFind index, since the ranking of the Summon results was unsatisfactory at the time we began using it (things have improved significantly since then).
>
> Obviously, this decision will have to be frequently revisited -- physical collections are very much in transition, so the physical/electronic distinction becomes less meaningful over time. Improvements to Summon (such as the HathiTrust full text search announced today) may also add some functionality that we can't replicate locally and may have to be weighed against the local advantages that are lost by switching to the hosted index. It's definitely not a stable playing field!
>
> - Demian
>
Received on Tue Mar 29 2011 - 15:20:28 EDT