Kbart improved access to electronic resources through better linking
1 / 23

KBART: Improved Access to Electronic Resources through better linking - PowerPoint PPT Presentation

  • Uploaded on

KBART: Improved Access to Electronic Resources through better linking. Peter McCracken KBART co-chair NASIG Conference Asheville, North Carolina 5 June 2009. Today’s Agenda. OpenURL Overview Measure of success; Positives and negatives KBART: Reviewing Problems & Seeking Solutions

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'KBART: Improved Access to Electronic Resources through better linking' - aquarius

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Kbart improved access to electronic resources through better linking

KBART: Improved Access to Electronic Resources through better linking

Peter McCracken

KBART co-chair

NASIG Conference

Asheville, North Carolina5 June 2009

Today s agenda
Today’s Agenda

  • OpenURL Overview

    • Measure of success; Positives and negatives

  • KBART: Reviewing Problems & Seeking Solutions

    • KBART background, goals, membership

  • Proposed Solutions

    • Improve knowledge of OpenURL, enhance implementation, improve data

  • KBART Deliverables

    • Brass tacks

Openurl overview
OpenURL Overview

  • The evolution of the OpenURL in use:

  • If links fail, patrons will turn to the tool that always works

  • Three main problems with OpenURL today:

    • Bad data; Bad formatting; Lack of knowledge

The measure of success
The Measure of Success

  • Better access for patrons

    • Fewer false positives and false negatives

  • Best-case scenario:

    • IF a patron is seeking an article, and her library offers access to it through exactly seven online resources,

    • THEN the OpenURL resolver returns exactly seven accurate links

Kbart a history
KBART: A History

  • UKSG 2007 research report by James Culling,“Link Resolvers and the Serials Supply Chain” (at http://www.uksg.org/projects/linkfinal)

    • Provided ideas on improving usage and accuracy

    • Recommended follow-up to address some specifics

  • NISO partnership to broaden reach and include US audience

Kbart an introduction
KBART: An Introduction

  • Knowledge Bases And Related Tools

  • UKSG and NISO collaborative project

  • Get better data for everyone –

    • Those who provide data (publishers, aggregators)

    • Those who process data (link resolvers, ERMs, etc.)

    • Those who present data (libraries, consortia)

      • All for THOSE WHO USE DATA – library patrons

  • Ensuring timely transfer of accurate data to knowledgebases, ERMs, etc.

Kbart the membership
KBART: The Membership

  • Core working group chaired by me (Serials Solutions) and Charlie Rapple (TBI Communications; formerly Ingenta)

    • Link resolver/ERM suppliers – Ex Libris, Openly/OCLC, Serials Solutions

    • Publishers – Taylor & Francis, SAGE, British Medical Journal

    • Subscription agents/aggregators – Swets, EBSCO, Ingenta, Credo

    • Libraries – Edinburgh, Leicester, Cornell, Princeton, Claremont Colleges, Hanford Technical

    • Consortia – SCELC, California Digital Library

  • Monitoring group

    • More of these plus other related groups e.g. NASIG

    • Anyone can join monitoring group

Kbart focusing on the negatives
KBART: Focusing on the Negatives

  • “OpenURL’s Negatives”

    • Inaccurate data leads to bad links

    • Incorrect implementation doesn’t transfer data properly

    • Lack of knowledge means some vendors aren’t using it

Solving the negatives lack of knowledge
Solving the Negatives: Lack of Knowledge

  • Some content providers simply aren’t aware of what OpenURL does and why it benefits them

    • Education & advocacy

  • Follow recommendations of Culling/SIS report; provide useful information to those content providers

    • How to implement correctly

    • Offer contacts for those needing assistance

Solving the negatives incorrect implementations
Solving the Negatives: Incorrect Implementations

  • Help content providers determine what is working, and what isn’t

    • Cornell project to focus on source OpenURLs

    • Identify correct and incorrect implementations

    • Give opportunity for vendors to grade selves

  • Offer more and better examples of OpenURL

  • Standardize transfer of data within and among supply chain participants

Solving the negatives inaccurate data
Solving the Negatives: Inaccurate Data

  • How do we handle incorrect data?

    • Grading? Policing? Shaming?

    • Biggest and most difficult problem to solve

  • Highlight to content providers how important completely accurate data is to their end users

    • Consider the ‘false positive’: arrrgh, that’s frustrating…

    • Consider the ‘false negative’: much, much worse: how would you ever know?

Kbart deliverables
KBART Deliverables

  • Create a report that provides general guidance on problematic issues

    • Data problems

    • Incorrect implementation

    • Limited knowledge

  • Offer best practices guidelines for how to effectively transfer accurate data among parties

  • Provide better understanding of supply chain

Kbart deliverables1
KBART Deliverables

  • How to deliver it

    • FTP, tab-delimited files

    • Separate files for each database

    • Separate out different lines for different holdings

  • What to deliver

    • Multiple fields – 15 separate fields of data, many “mandatory if applicable”

How to deliver
How to deliver

  • Method of exchange

    • Use FTP, or if not possible, email

  • Frequency of exchange

    • As often as necessary…

  • Maintain data contacts between parties

    • Don’t forget individual libraries

Delivery specifics
Delivery specifics

  • Use tab-separated values format

    • Skip the decorations

    • Problem for notes, commentary, etc?

      • Will relevant information be disconnected from its subject?

  • Use web domain as identifier/name

  • Use standardized file naming structure, viz:

    • JSTOR.ORG_Arts&SciencesV_2009-06-04.txt

    • ebscohost.com_afh_2009-06-04.txt

  • Break out multiple holdings, when >12m gap

What to deliver defined fields
What to deliver – Defined fields

  • Publication title

  • Print-format identifier (ie, ISSN, ISBN, etc.)

  • Online-format identifier (ie, eISSN, eISBN, etc.)

  • Date of first issue available online

  • Date of last issue available online (or blank, if coverage is to present)

  • Number of first volume available online

  • Number of first issue available online

  • Number of last volume available online (or blank, if coverage is to present)

  • Number of last issue available online (or blank, if coverage is to present)

  • Title-level URL

  • First author (for monographs)

  • Title ID

  • Embargo

  • Content Type (abstracts/fulltext)

  • Publisher name (if not given in the file’s title)

Specifics on defined fields
Specifics on defined fields

  • Chronology & enumeration fields

    • “Number” and “volume” only

  • First author (for monographs)

    • An differentiator, in a sense

  • Embargo

    • “P12m” vs. “P365d” – ISO 8601,

  • Content type – abstract vs full text

  • Publisher name

Will it work is it doable
Will it work? Is it doable?

  • Drum roll, please…

Example file structure
Example File Structure

  • From Excel (thanks to Oliver Pesch, EBSCO):

Process enhancements
Process enhancements

  • Data error reporting

    • How?

    • What is link resolvers’ commitment to correcting it?

      • What about home-grown systems?

    • What is content providers’ commitment to correcting it?

    • Creating a definition of how to report?

  • Structure error reporting

    • Cornell project, for instance – perhaps on a larger scale

Education sections
Education sections

  • Should we have them?

  • FAQ / website

    • Who would maintain?

  • List of existing resolvers

    • What’s the value? Maybe just add them to the Wikipedia entry?

Next steps
Next steps

  • Library-specific data

  • Consortial package work

  • Non-textual resources

  • Standards?

  • Neverending list….


  • http://www.uksg.org/kbart

  • http://www.niso.org/workrooms/kbart

  • Peter McCracken (NISO co-chair)

    • peter@serialssolutions.com

      • Co-founder & Director for Research, Serials Solutions

  • Charlie Rapple (UKSG co-chair)

    • charlie.rapple@tbicommunications.com

      • Head of Marketing Development, TBI Communications