I think this pretty accurately reflects the sentiments at the University
of North Carolina, one of NSCU's partners in developing the Endeca
interface to our catalog.  It's as much a mechanism for delivering
services as it is for discovery, and as such reflects the physical nature
of the collections it includes.  It's not possible at this point for us to
build those services into the Summon environment.  +1 all around to
Emily's comments.

Will Owen

On 2/4/13 9:56 AM, "Emily Lynema" <[log in to unmask]> wrote:

>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-strateg
>y/
>________________________________________
>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]