The Future of Access to Articles Steve Toub Friday the 13 th , 2007
A&I Will Die <ul><li>The rise of full-text content providers and the introduction of non-traditional aggregators (e.g., Go...
MetaSearch Sucks <ul><li>In an environment where patrons expect instant answers from Google, a platform where folks will w...
BSTF & Aggregating Articles <ul><li>In early Oct 2006, SOPAG reported to BSTF that “the ULs did look with favor on the tal...
Google Scholar <ul><li>Broad coverage </li></ul><ul><ul><li>But incomplete </li></ul></ul><ul><ul><li>And GS is not willin...
Microsoft Live Search Academic <ul><li>Narrow coverage </li></ul><ul><ul><li>Started with CompSci and added BioMed/Health ...
WorldCat Local <ul><li>Broad coverage (30M articles at launch) </li></ul><ul><ul><li>ArticleFirst & some gov’t DBs: ERIC, ...
From reality to pure speculation <ul><li>“ Caveat management” </li></ul><ul><li>Ideas shaped over email with some other in...
GOOG/MSFT fall short; I want: <ul><li>An API, allowing institutions to: </li></ul><ul><ul><li>Control the UI </li></ul></u...
Components of a Hypothetical Centralized Service <ul><li>Hammer out terms and conditions and doing acquisitions through a ...
Components, continued… <ul><li>The central service should provide indexing and querying of the data. It should provide a w...
Negotiating Tips (Code4Lib-ers) <ul><li>Need to hone message on the incentives for content providers to participate. MLA B...
So… Whaddya Think?
Upcoming SlideShare
Loading in …5
×

The Future Of Access to Articles

1,248 views

Published on

Presentation to CDL staff, April 2007

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,248
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Future Of Access to Articles

  1. 1. The Future of Access to Articles Steve Toub Friday the 13 th , 2007
  2. 2. A&I Will Die <ul><li>The rise of full-text content providers and the introduction of non-traditional aggregators (e.g., Google Scholar, Microsoft Live Search Academic) reduces the value of traditional aggregators and indexes. </li></ul><ul><li>The economic model of how to sustain the terminology services (thesaurus creation and maintenance, indexing) that traditional A&I vendors have provided is not yet clear. </li></ul>
  3. 3. MetaSearch Sucks <ul><li>In an environment where patrons expect instant answers from Google, a platform where folks will wait 32 seconds to get back the 10 “last-in, first-out” results at a time is a transitional solution, at best </li></ul><ul><li>Where possible, it’s always better to aggregrate than to federate </li></ul>
  4. 4. BSTF & Aggregating Articles <ul><li>In early Oct 2006, SOPAG reported to BSTF that “the ULs did look with favor on the talks with the Internet Search Engines to address the ‘articles’ side of next generation discovery.” </li></ul><ul><li>Initial discussions with Google Scholar and Microsoft Live Search Academic in December/January surfaced some areas of possible collaboration. </li></ul><ul><li>Currently in a bit of a holding pattern </li></ul>
  5. 5. Google Scholar <ul><li>Broad coverage </li></ul><ul><ul><li>But incomplete </li></ul></ul><ul><ul><li>And GS is not willing to pay for content </li></ul></ul><ul><li>Not likely to better leverage metadata </li></ul><ul><li>Interested in: </li></ul><ul><ul><li>Us pressuring vendors who won’t let GS in </li></ul></ul><ul><ul><li>Books interface and integration between books and articles and more. </li></ul></ul><ul><ul><li>Our bib/holdings records </li></ul></ul>
  6. 6. Microsoft Live Search Academic <ul><li>Narrow coverage </li></ul><ul><ul><li>Started with CompSci and added BioMed/Health </li></ul></ul><ul><ul><li>Will add topics incrementally over time </li></ul></ul><ul><li>Seems like a “runner-up” product </li></ul><ul><li>Interested in: </li></ul><ul><ul><li>Input on collection development priorities </li></ul></ul><ul><ul><li>Improved linking from Academic to UC holdings </li></ul></ul><ul><ul><li>Integrated interface with books, articles, etc. </li></ul></ul>
  7. 7. WorldCat Local <ul><li>Broad coverage (30M articles at launch) </li></ul><ul><ul><li>ArticleFirst & some gov’t DBs: ERIC, Medline, etc. </li></ul></ul><ul><ul><li>Talking with others </li></ul></ul><ul><li>Could be integrated with Melvyl 2.0 interface </li></ul><ul><li>Interested in: </li></ul><ul><ul><li>??? </li></ul></ul><ul><ul><li>Not a good time for CDL to be discussing articles with OCLC </li></ul></ul>
  8. 8. From reality to pure speculation <ul><li>“ Caveat management” </li></ul><ul><li>Ideas shaped over email with some other institutions and at a breakout session at Code4Lib </li></ul><ul><li>“ At the network level” meme echoed at the RLG D2D symposium </li></ul>
  9. 9. GOOG/MSFT fall short; I want: <ul><li>An API, allowing institutions to: </li></ul><ul><ul><li>Control the UI </li></ul></ul><ul><ul><li>Build aggregations that combine this “article store” with local indexes (e.g., courseware, institutional repositories, networked drives) if they so chose. </li></ul></ul><ul><ul><li>Enhance metadata (e.g., subject categorization) </li></ul></ul><ul><ul><li>Perform text mining operations </li></ul></ul><ul><li>Better leverage metadata for fielded searching, sorting, faceted browse, etc. </li></ul><ul><li>A service level agreement, perpetual access </li></ul><ul><li>Known (and comprehensive) coverage. </li></ul>
  10. 10. Components of a Hypothetical Centralized Service <ul><li>Hammer out terms and conditions and doing acquisitions through a single broker </li></ul><ul><li>Obtaining the right to use full-text formats are preferred so there is the ability to index and do text mining on that rather than just the metadata (even though we prefer to go to the vended site for delivery). </li></ul><ul><li>A central repository should store, manage and preserve the raw data. </li></ul><ul><li>Scrubbing/reformatting tools as well as tools that load data should be developed/shared. </li></ul>
  11. 11. Components, continued… <ul><li>The central service should provide indexing and querying of the data. It should provide a web interface as well as an API. </li></ul><ul><ul><li>Partners would need to be able to share their ERM KBs with the central service in order index institution-specific permissions and display the appropriate delivery options in the discovery UI. </li></ul></ul><ul><li>Partners could grab from the common repository & deploy in their local discovery services (may include other collections: metadata of library holdings, full-text of digitized books, special collections, etc.) </li></ul>
  12. 12. Negotiating Tips (Code4Lib-ers) <ul><li>Need to hone message on the incentives for content providers to participate. MLA Bibliography told OhioLINK after a certain point they wouldn't sell it to them at any price. The threat of canceling our subscriptions isn't very credible. </li></ul><ul><ul><li>Possible additional $ for them at little additional cost </li></ul></ul><ul><ul><li>Additional $ for their to pay-per-view services </li></ul></ul><ul><ul><li>Possible savings (if they < $ in their discovery services) </li></ul></ul><ul><ul><li>Possible savings (<$ to support z39.50/SRU) </li></ul></ul><ul><li>Determine how much leverage we have. </li></ul><ul><ul><li>What % of the customer base of vendors is academic libraries? How much leverage do we have? </li></ul></ul><ul><ul><li>What if a database is only available from one vendor? </li></ul></ul>
  13. 13. So… Whaddya Think?

×