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
|
