On Feb 4, 2013, at 10:34 AM, Donna Campbell <[log in to unmask]> wrote:

> In mentioning "pushing to break down silos more," it brings to mind a
> question I've had about linked data.
> 
> From what I've read thus far, the idea of breaking down silos of
> information seems like a good one in that it makes finding information
> easier but doesn't it also remove some of the markers of finding credible
> sources? Doesn't it blend accurate sources and inaccurate sources?

Provenance is especially important in this context, which I think is a crucial role that libraries can play.

-Ross.

> 
> 
> Donna R. Campbell
> Technical Services & Systems Librarian
> (215) 935-3872 (phone)
> (267) 295-3641 (fax)
> Mailing Address (via USPS):
> Westminster Theological Seminary Library
> P.O. Box 27009
> Philadelphia, PA 19118  USA
> Shipping Address (via UPS or FedEx):
> Westminster Theological Seminary Library
> 2960 W. Church Rd.
> Glenside, PA 19038  USA
> 
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Emily Lynema
> Sent: Monday, February 04, 2013 9:56 AM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] Why we need multiple discovery services engine?
> 
> 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