 |
 |
Here at NCSU, we use our locally-hosted Endeca service for our catalog and Serials Solutions Summon as an article search solution. Why do this? 1. Our next-gen library catalog (Endeca) came first. This was before Solr hit the library world, and before library vendors started working on improving their bundled catalog apps. Our bundled catalog was terrible, and we wanted something better. This was back in the day when everyone was doing federated search for articles (think MetaLib). 2. 4-5 years down the road, a number of vendors (Ebsco, Serials Solutions, etc.) were getting into the web scale discovery business. Aka, one big index that includes everything, in particular the citation content that libraries have historically not had local access to index / search. We bought Summon to solve the article search problem that federated searching never resolved for us. We wanted one access point for less experienced users who needed to find articles. Since we had backed away from federated search for articles, this was our big pain point; we already had a catalog we liked. We've actually loaded our catalog content into Summon, as well. So why keep both? We've done a LOT of work adding functionality into our local catalog, including enhanced title searching,lots of supplemental content, a quite complex local requesting system. So we can't just switch to the Summon interface without some effort. In addition, we have found that we prefer the "bento box" approach to searching across formats, as opposed to the integrated index approach of Summon. At least at this moment. We use this in the search across our library website [1]. It's just really, really hard to always surface the right kind of thing the user is looking for when the things you're indexing are different in nature (ex: bibliographic record vs. full-text of newspaper article). With the "bento box" approach, you have better opportunities to surface the different types of content available, while still having local systems optimized for specific content types. Maybe that's a long-winded excuse for not pushing to break down silos more. Time will probably tell. -emily [1] http://www.lib.ncsu.edu/search/?q=java ------------------------------------------------------------------------- Date: Fri, 1 Feb 2013 04:21:01 +0000 From: Jonathan Rochkind <[log in to unmask]> Subject: Re: Why we need multiple discovery services engine? So, there are two categories of solutions here -- 1) local indexes, where you create the index yourself, like blacklight or vufind (both based on a local Solr). 2) vendor-hosted indexes, where the vendor includes all sorts of things in their index that you the customer don't have local metadata for, mostly including lots and lots of scholarly article citations. If you want to include scholarly article citations, you probably can't do that with a local index solution. Although some consortiums have done some interesting stuff in that area, let's just say it takes a lot of resources to do. For most people, if you want to include article search in your index, it's not feasilbe to do so with a local index. So "only" VuFind/Blacklight with a local Solr is out, if you want article search. You _can_ load local content in a vendor-hosted index like EDS/Primo/Summon. So plenty of people do choose a vendor-hosted index product as their only discovery tool, including both local metadata and vendor-provided metadata. As you suggest. But some people want the increased control that a locally controlled Solr index gives you, for the local metadata where it's feasible. So use a local index product. But still want the article search you can get with a vendor-hosted index product. So they use both. There is also at least some reasons to believe that our users don't mind and may even prefer having local results and hosted metadata results presented seperately (although probably preferably in a consistent UI), rather than merged. A bunch more discussion of these issues is included in my blog post at: http://bibwild.wordpress.com/2012/10/02/article-search-improvement-strategy/ ________________________________________ From: Code for Libraries [[log in to unmask]] on behalf of Wayne Lam [ [log in to unmask]] Sent: Thursday, January 31, 2013 9:31 PM To: [log in to unmask] Subject: [CODE4LIB] Why we need multiple discovery services engine? Hi all, I saw in numerous of library website, many of them would have their own based discovery services (e.g. blacklight / vufind) and at the same time they will have vendor based discovery services (e.g. EDS / Primo / Summon). Instead of having to maintain 2 separate system, why not put everything into just one? Any special reason or concern? Best Wayne -- Emily Lynema Associate Department Head Information Technology, NCSU Libraries 919-513-8031 [log in to unmask]