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]