That's the same number and reason I got from the developers when I asked about how they were getting "EBSCO content" back in March.
If only there was a way to lower the cost model for the service.
-Aaron
:-)'
-
"They do their own indexing with Summons and at least 85% of what Ebsco has (including 99 of the top 100 journals)*"
"* Or so I'm told"
EC
-
"Late adopters and non-adopters are vocal, but their feedback is irrelevant."
--Steven Abram.
-----Original Message-----
From: Next generation catalogs for libraries [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Edward M. Corrado
Sent: Wednesday, June 17, 2009 1:46 PM
To: NGC4LIB_at_LISTSERV.ND.EDU
Subject: Re: [NGC4LIB] Preliminary report on user research for eXtensible Catalog
Dobbs, Aaron wrote:
> Why have hundreds of disparate UI instances?
> The search system provider can handle the generics of the UI with space for libraries to customize branding if desired. Less library bandwidth used (by outside the library users) and greater efficiencies.
>
> The trick is to get the content providers to share their indexing with a content competitor if this competitor also had a popular search system.
>
> E.G.
> ProQuest owns SerialsSolutions which offers Summon (a centralized index which points to the various content providers); EBSCO doesn't want to provide ProQuest with EBSCO content indexing (and the reverse, insert many other vendors, etc.) since EBSCO would rather their customers use the soon to be released EBSCO product which does similar things.
>
Serial Solutions doesn't really need Ebsco indexing or even cooperation
in 99.9% of the cases. They do their own indexing with Summons and at
least 85% of what Ebsco has (including 99 of the top 100 journals)* is
being indexing already by Summons even though they are a month or so
from actually releasing the product in production. Serial Solutions gets
the content straight from the publishers in most cases and doesn't need
the Ebsco middle-man. How Ebsco will do a similar product, I don't know
but Serial Solutions does not need to rely on content aggregators such
as Ebsco as long as they can get content to index directly from the
publishers - which they have been extremely successful at doing thus
far. Where the Serial Solutions model may fall short is where Ebsco or
other aggregators have exclusive agreements with some journals.
Edward
* Or so I'm told
> -Aaron
> :-)'
>
> -----Original Message-----
> From: Next generation catalogs for libraries [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Karen Coyle
> Sent: Wednesday, June 17, 2009 12:11 PM
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] Preliminary report on user research for eXtensible Catalog
>
> As I recall, one of the issues with metasearch was that the searching
> itself put a great burden on the vendor systems -- since they received
> hits for every search done, even those not terribly relevant to their
> topic or offerings. Moving the search out closer to the user, and having
> the vendors only do delivery, should be appealing to them. What doesn't
> work, IMO, is to replicate this search functionality on hundreds of
> different systems. We need a middle man (or two or three) to provide a
> robust search function that libraries can then hook into. That search
> system can be optimized for search while libraries provide the UI and
> the A&I vendors do fulfillment.
>
> ? Possible?
> kc
>
> Bowen, Jennifer wrote:
>
>> Just to follow up, Jonathan asked me off-list whether we have active
>> plans/thoughts about how to get this metadata from scholarly databases
>> run by third party companies, and here's how I responded to him:
>>
>> This is going to have to be a negotiation process with these third party
>> companies, and some companies are going to be more receptive to this
>> than others, just as some of these companies have been willing to make
>> MARC records available for their content in the past, and some have not.
>> The rationale to use with the content vendors is that making metadata
>> about their content more available through library discovery
>> applications is going to increase interest in their products, and that
>> this is better technology than metasearch because it doesn't impose
>> limits on the number of resources retrieved from their database (such
>> as, perhaps, the first 20 in a metasearch query). We need to also
>> reassure vendors that we are building technology that will address their
>> requirements, such as limiting access to the content itself to paid
>> subscribers.
>>
>> Obviously, this is going to take some effort to get a significant number
>> of content providers on board. Libraries that use XC and that subscribe
>> to this content are probably in the best position to make a case for
>> access to the metadata at the point when they are negotiating contracts
>> - we can't really do it for them. We see this as one activity that
>> could be coordinated by the not-for-profit organization that we are
>> forming to support users of the XC software.
>>
>> Jennifer
>>
>> -----Original Message-----
>> From: Bowen, Jennifer
>> Sent: Wednesday, June 17, 2009 10:10 AM
>> To: 'Jonathan Rochkind'; Next generation catalogs for libraries
>> Subject: RE: [NGC4LIB] Preliminary report on user research for
>> eXtensible Catalog
>>
>> XC's architecture is based upon aggregating metadata, and we are
>> building a robust platform that will perform this aggregation, called
>> the XC Metadata Services Toolkit (MST). This open source software will
>> support metadata from scholarly databases as well as from library
>> catalogs and repositories. We believe that this is a much more
>> promising direction for future discovery interfaces than relying upon
>> metasearch technology, although the two approaches may need to be used
>> alongside each other in the shorter term. We just don't see a promising
>> future in continuing to develop new software that uses metasearch
>> technology.
>>
>> Jennifer
>>
>> -----Original Message-----
>> From: Jonathan Rochkind [mailto:rochkind_at_jhu.edu]
>> Sent: Tuesday, June 16, 2009 10:21 AM
>> To: Next generation catalogs for libraries; Bowen, Jennifer
>> Subject: Re: [NGC4LIB] Preliminary report on user research for
>> eXtensible Catalog
>>
>> One of the things that stuck out to me in the report was user's
>> confusion about whether they could find articles in the catalog, as well
>>
>> as user's unhappiness with having to learn new interfaces for additional
>>
>> scholarly databases.
>>
>> Are you considering trying to address the scholarly database issue with
>> some kind of federated broadcast search, aggregated index, or other
>> means of attempting to integrate scholarly article results in the main
>> interface?
>>
>> Jonathan
>>
>> Montibello, Joseph P. wrote:
>>
>>
>>> Jennifer,
>>>
>>> Thanks so much for sharing this useful and very interesting report
>>>
>>>
>> with the community. We talk so much about how we need to know what the
>> users need. As you say in the report, this is not a comprehensive,
>> end-all be-all type of report, but it answers a few questions and
>> prompts even more.
>>
>>
>>>
>>> Cheers!
>>> Joe Montibello
>>> Class of 1945 Library
>>> Phillips Exeter Academy
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Date: Mon, 15 Jun 2009 14:08:48 -0400
>>> From: Jennifer Bowen <jbowen_at_LIBRARY.ROCHESTER.EDU>
>>> Subject: Preliminary report on user research for eXtensible Catalog
>>>
>>> (Posted on behalf of Nancy Fried Foster,
>>>
>>>
>> nfoster_at_library.rochester.edu)
>>
>>
>>> The eXtensible Catalog project at the University of Rochester's River
>>>
>>>
>> Campus
>>
>>
>>> Libraries is pleased to release the first report on the user research
>>>
>>>
>> that
>>
>>
>>> we conducted in support of XC software development. We thank the
>>>
>>>
>> Andrew W.
>>
>>
>>> Mellon Foundation and our user research partners - Cornell, Ohio
>>>
>>>
>> State, Yale
>>
>>
>>> and the University of Rochester - for their generous support of this
>>>
>>>
>> project.
>>
>>
>>> Use this URL - http://hdl.handle.net/1802/6873 - for a report that
>>> summarizes the objectives, methods, and major software design findings
>>>
>>>
>> from
>>
>>
>>> the data collected in the user research portion of the eXtensible
>>>
>>>
>> Catalog
>>
>>
>>> (XC) project. A full analysis and interpretation of the data is not
>>>
>>>
>> included
>>
>>
>>> in the present report and will be provided at the conclusion of the
>>>
>>>
>> project.
>>
>>
>>> This report includes edited results from the brainstorming sessions
>>>
>>>
>> and a
>>
>>
>>> list of the features that emerged from the analysis of those results.
>>>
>>>
>> (See
>>
>>
>>> the eXtensible Catalog website at www.eXtensibleCatalog.org for more
>>> information about the overall
>>> project.)
>>>
>>>
>>>
>>>
>>
>>
>
>
>
Received on Wed Jun 17 2009 - 14:13:20 EDT