Or you could do what we've done using the PCI API to retrieve
search-specific results and merge them with catalog search results. See
this example:
http://fgcu.catalog.fcla.edu/gc.jsp?st=everglades+research&ix=kw&S=2461314820272219&fl=ba
The non-article entries are from our Solr-based repository of records
from the Aleph catalog, DigiTool and other sources. The articles are
from PCI (without using Primo or MetaLib).
- Michele
On 8/31/2011 3:11 PM, Molly Pickral wrote:
> Jonathan's blog post refers to work at the University of Virginia
> which was, at that time, in progress. It is now in production
> (side-by-side search results) at:
>
> http://search.lib.virginia.edu
>
> Molly
>
> On Wed, Aug 31, 2011 at 3:07 PM, Jonathan Rochkind<rochkind_at_jhu.edu> wrote:
>
>> On 8/31/2011 2:58 PM, Paoshan Yue wrote:
>>
>>>
>>> So does this mean that, for a library without Primo to take advantage of
>>> Primo Central Index, the library will need to pre-harvest content (catalog,
>>> digital collections, IR, etc.) and merge results with those from Primo
>>> Central? Doesn't it seem a lot of work?
>>>
>> A probably infeasible amount of work with less than satisfactory
>> results--merging results from two different search engines at display-time
>> is basically the traditional "broadcast federated search", and generally
>> works not well at all. (And if you do want to do this, you could alternately
>> buy Metalib, which comes with access to PrimoCentral-without-Primo, and is a
>> broadcast federated search tool).
>>
>> But there are ways to use an aggregated index like Primo Central without
>> merging result sets at all.
>>
>> You could simply search PrimoCentral as it is, as an aggregated article
>> index, like Google Scholar or Scopus. (Perhaps it performs better in some
>> way than the alternatives).
>>
>> Or could provide a search which gave PrimoCentral results and results from
>> one or more other search engines side-by-side ("bento box style") instead of
>> merged.
>> http://bibwild.wordpress.com/2011/08/08/article-search-and-catalog-search/
>>
>>>
>>> Cheers,
>>> Paoshan
>>>
>>> -----Original Message-----
>>>
>>> From: David Friggens<[log in to
>>> unmask]<https://listserv.nd.edu/cgi-bin/wa?LOGON=A2%3Dind1103%26L%3DNGC4LIB%26D%3D0%26P%3D49289&Y=yue%40UNR.EDU>>
>>> Subj: Re: [NGC4LIB] The next generation of discovery tools (new LJ
>>> article)
>>> Date: Mon Mar 28, 2011 6.55 pm
>>> Size: 1000 bytes
>>> To: [log in to
>>> unmask]<https://listserv.nd.edu/cgi-bin/wa?LOGON=A2%3Dind1103%26L%3DNGC4LIB%26D%3D0%26P%3D49289&Y=yue%40UNR.EDU>
>>>
>>>> So, going back to the original topic of this thread.
>>>>
>>> :-) [I've been finding the side thread on ranking to be very interesting and illuminating]
>>>
>>>
>>> To add my two cents, I've found it interesting and a little surprising
>>> to see that people are taking on the task of merging catalogue and
>>> "discovery index" data themselves.
>>>
>>> My institution/consortium chose Summon, and I've been quite glad that
>>> they take on that work of merging our catalogue and repository results
>>> along with their index. We're currently using their default interface,
>>> but I'm open to using another interface to display the search/results
>>> via the API.
>>>
>>> I can understand that if you bought Primo Central without Primo you
>>> would need to do result merging yourself, but at least with Summon and
>>> EDS I would have thought it much easier and preferable to use the
>>> combined results that those services provide in an alternative
>>> interface.
>>>
>>> Are people expecting that they can do much better by combining the
>>> results themselves?
>>>
>>> Cheers
>>> David
>>>
>
--
~NOTE EMAIL ADDRESS CHANGE TO FCLMIN_at_UFL.EDU~~~~~~~~~~~~~~~~~~~
Michele Newberry Assistant Director for Library Services
Florida Center for Library Automation 352-392-9020
5830 NW 39th Avenue 352-392-9185 (fax)
Gainesville, FL 32606 fclmin_at_ufl.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received on Wed Aug 31 2011 - 15:57:10 EDT