 |
 |
Wayne, > many of them would have their own based discovery services... and... they will have vendor based discovery services... why... I agree with Jonathan, and would add that, as with so many things, why things are has a lot to do with history. Forgive me if you already know this... For a long while vendors bundled a catalog, then a web-catalog, with their integrated library system. Many vendors made it very difficult for developers to change the bundled web catalog in any standard way, and charged significant fees for the ability to do so. When NCState & Endeca took faceted browsing on the road, the closed-data model floodgates broke, and many institutions essentially began exporting the necessary data from their ILS, indexing it in solr and displaying it via easily tweaked homegrown or VuFind et al systems, which had the added advantage of easily allowing other collections to be indexed & displayed. And the world was better. Vendors (most) responded to this by improving their systems, making them easier to configure in standard ways, via providing APIs, and via allowing other data-sources to be exposed, which is why you sometimes now see both systems in place. -b --- Birkin James Diana Programmer, Digital Technologies Brown University Library [log in to unmask] On Jan 31, 2013, at 11:21 PM, Jonathan Rochkind <[log in to unmask]> wrote: > So, there are two categories of solutions here -- 1) local indexes, where you create the index yourself, like blacklight or vufind (both based on a local Solr). 2) vendor-hosted indexes, where the vendor includes all sorts of things in their index that you the customer don't have local metadata for, mostly including lots and lots of scholarly article citations. > > If you want to include scholarly article citations, you probably can't do that with a local index solution. Although some consortiums have done some interesting stuff in that area, let's just say it takes a lot of resources to do. For most people, if you want to include article search in your index, it's not feasilbe to do so with a local index. So "only" VuFind/Blacklight with a local Solr is out, if you want article search. > > You _can_ load local content in a vendor-hosted index like EDS/Primo/Summon. So plenty of people do choose a vendor-hosted index product as their only discovery tool, including both local metadata and vendor-provided metadata. As you suggest. > > But some people want the increased control that a locally controlled Solr index gives you, for the local metadata where it's feasible. So use a local index product. But still want the article search you can get with a vendor-hosted index product. So they use both. > > There is also at least some reasons to believe that our users don't mind and may even prefer having local results and hosted metadata results presented seperately (although probably preferably in a consistent UI), rather than merged. > > A bunch more discussion of these issues is included in my blog post at: http://bibwild.wordpress.com/2012/10/02/article-search-improvement-strategy/ > ________________________________________ > From: Code for Libraries [[log in to unmask]] on behalf of Wayne Lam [[log in to unmask]] > Sent: Thursday, January 31, 2013 9:31 PM > To: [log in to unmask] > Subject: [CODE4LIB] Why we need multiple discovery services engine? > > Hi all, > > I saw in numerous of library website, many of them would have their own > based discovery services (e.g. blacklight / vufind) and at the same time > they will have vendor based discovery services (e.g. EDS / Primo / Summon). > Instead of having to maintain 2 separate system, why not put everything > into just one? Any special reason or concern? > > Best > > Wayne