1 / 23

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 Carolina 5 June 2009. Today’s Agenda. OpenURL Overview Measure of success; Positives and negatives KBART: Reviewing Problems & Seeking Solutions

aquarius
Download Presentation

KBART: Improved Access to Electronic Resources through better linking

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. KBART: Improved Access to Electronic Resources through better linking Peter McCracken KBART co-chair NASIG Conference Asheville, North Carolina5 June 2009

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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.

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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?

  12. 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

  13. 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”

  14. 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

  15. 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

  16. 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)

  17. 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

  18. Will it work? Is it doable? • Drum roll, please…

  19. Example File Structure • From Excel (thanks to Oliver Pesch, EBSCO):

  20. 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

  21. 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?

  22. Next steps • Library-specific data • Consortial package work • Non-textual resources • Standards? • Neverending list….

  23. 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

More Related