On Feb 4, 2013, at 10:34 AM, Donna Campbell <dcampb...@wts.edu> 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:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of > Emily Lynema > Sent: Monday, February 04, 2013 9:56 AM > To: CODE4LIB@LISTSERV.ND.EDU > 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
