kbart improved access to electronic resources through better linking
Download
Skip this Video
Download Presentation
KBART: Improved Access to Electronic Resources through better linking

Loading in 2 Seconds...

play fullscreen
1 / 23

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


  • 110 Views
  • 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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, 4.4.4.3
  • 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….
thanks
Thanks!
  • 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
ad