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? 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