Re: [CODE4LIB] Linked data [was: Why we need multiple discovery services engine?]
On Feb 4, 2013, at 10:34 AM, Donna Campbell 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? Yes, yes it does. The 'intelligence' community has actually been talking about this problem with RDF for years. My understanding is that they use RDF quads (not triples) so that they have an extra parameter to track the source. (it might be that they use something larger than a quad). >From what I remember (the conversation was years ago), they have to be able to mark information as suspect (eg, they find that one of the sources is unreliable, then re-run all all of the analysis without that source's contribution to determine if they came to the same result). I don't know enough about the implementation of linked data systems, so if there's some way to filter which sources are considered for input, or if there's any tracking of the RDF triples once they're parsed out. -Joe
Re: [CODE4LIB] Linked data [was: Why we need multiple discovery services engine?]
On Feb 4, 2013, at 10:34 AM, Donna Campbell 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
[CODE4LIB] Linked data [was: Why we need multiple discovery services engine?]
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: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
