You are viewing a javascript disabled version of the site. Please enable Javascript for this site to function properly.
Go to headerGo to navigationGo to searchGo to contentsGo to footer
In content section. Select this link to jump to navigation

KBART Phase III: Unresolved questions

Abstract

During the “NISO update” session at the NISO Plus 2021 conference, which took place online due to the COVID-19 pandemic, members of the KBART (Knowledge Base and Related Tools) Standing Committee presented their plans and work toward KBART Phase III, a revision of the KBART Recommended Practice. In an interactive breakout session, they sought input from attendees on how KBART is being used and what new content types it should support. Presenters from the KBART Standing Committee were Noah Levin (Independent Professional), Stephanie Doellinger (OCLC, Inc.), Robert Heaton (Utah State University), and Andrée Rathemacher (University of Rhode Island). Assisting them in preparing the presentation were Jason Friedman (Canadian Research Knowledge Network), Sheri Meares (EBSCO Information Services), Benjamin Johnson (ProQuest), Elif Eryilmaz-Sigwarth (Springer Nature), and Nettie Lagace (NISO).

1.KBART update

On 23 February 2021, as part of the “NISO update” session at the NISO Plus 2021 conference, Noah Levin (Independent Professional), KBART Standing Committee (SC) co-chair, provided an overview of KBART and the work of the KBART SC toward KBART Phase III, a revision of NISO RP-9-2014, the KBART Recommended Practice (RP); see: https://www.niso.org/publications/rp-9-2014-kbart. His presentation served as an introduction to an interactive breakout discussion during which members of the KBART SC sought input from attendees on how KBART is currently being used and what new content types it should support in the future. Approximately one hundred and forty people attended the main session.

1.1.What is KBART?

The KBART (“Knowledge Bases and Related Tools”) Phase I Recommended Practice (RP) was published in 2010 as the result of the efforts of a joint NISO/UKSG KBART Working Group that was established in 2007. The goal was to improve the data supplied to knowledge bases and link resolvers in order to improve OpenURL linking for journals. KBART Phase I offered an accepted standard for content provider metadata that was regularly distributed and available on demand.

Published in 2014, KBART Phase II expanded the RP to include e-books and conference proceedings, open access content, and metadata for consortia. In 2014, NISO established the KBART Standing Committee (KBART SC) to promote KBART and to monitor the environment for any necessary updates or revisions needed. This committee is a cross-industry group comprising content providers, knowledge base suppliers, and librarians from consortia and individual institutions.

KBART recommends best practices for the communication of electronic resource title lists and coverage data from content providers to knowledge base suppliers. Content providers create a KBART file for each of their sellable packages, listing the titles included and, in the case of serials, the dates of coverage for the title. KBART specifies the file format, delivery mechanisms, and fields to be included in the files. Knowledge base suppliers load these KBART files into their systems, and librarians select their purchased content from within the knowledge base. Data from the knowledge base populates holdings information and links within e-journal lists and library catalogs, enabling seamless linking to a library’s e-resource holdings.

KBART files are simple and therefore versatile. They consist of tab-delimited text files that can be easily ingested into knowledge bases and other systems and are human-readable. Fields include title, identifiers, author, publisher, coverage dates, URL, publication type, embargo information, coverage depth, and access type.

In 2019, NISO-26-2019, the KBART Automation Recommended Practice was published as a companion RP to KBART that provides for the automatic transfer from content providers to knowledge bases of KBART-formatted holdings files. Unlike standard KBART files which describe sellable packages from content providers, files for KBART Automation are institution-specific, providing a “snapshot” of the holdings of a particular subscriber at the time the file was produced.

1.2.KBART Phase III

The KBART SC is currently working on the Phase III revision of KBART. After approval from the NISO Information Discovery and Interchange Topic Committee, working areas for Phase III were identified, subgroups were created, and new Standing Committee members were recruited. In March 2020, subgroups of the KBART SC began work on drafting updated recommendations. After the work of the subgroups is completed, an initial draft of KBART Phase III will be circulated for a thirty-day comment period, after which a final, revised draft will be completed and published.

KBART Phase III work items include:

Clarify current recommendations: Improve and expand guidance around the existing KBART Phase II fields, providing additional examples, and revise guidance around gap coverage, title changes and history, and handling of withdrawn/no longer available titles.

Endorsement process: Streamline the KBART endorsement process and investigate creating different levels of endorsement to encourage content providers to seek endorsement even if they are unable to meet all the requirements while rewarding content providers who do.

Additional content types: Expand KBART to allow for content types beyond journals and books, with support for textual content such as blogs, transcripts, manuscripts, and datasets and for non-textual, multimedia content such as audio, video, and images.

Global content: Identify translations and allow representation of author names and titles in multiple languages.

File guide: Addition of a document from content providers that serves as a guide to the files available, to reduce confusion as files are added, removed, or changed.

Sample license language: Include language that can be incorporated into license agreements to support the adoption of KBART and KBART Automation.

File format options: Create a road map for future file format options such as JSON or XML in addition to tab-delimited text in order to create flexibility for KBART Automation and APIs.

Article-/chapter-level data: Create a road map for future communication of institutional holdings at the article and chapter level and for hybrid open access.

KBART mission statement: Update the mission of KBART to include support for KBART Automation and to acknowledge the use of KBART files beyond populating knowledge bases.

2.Audience feedback on uses of KBART and need for additional content types

2.1.KBART breakout session introduction

More than thirty people attended the KBART breakout session that followed the main presentations. At the start of the breakout Stephanie Doellinger (OCLC, Inc.), KBART SC member, pointed attendees toward an EasyRetro board. Attendees were invited to share their responses to four questions posed by the KBART SC in order to gather feedback that would inform their work on KBART Phase III.

The questions were:

  • How are you using KBART today?

  • How would you like to use KBART that is not possible today?

  • What additional content types do you wish that KBART supported?

  • What additional fields would best support new content types?

Attendees were given five minutes to answer the questions using the interactive EasyRetro board.

As attendees brainstormed answers to the questions, KBART SC member Robert Heaton (Utah State University) asked the audience to consider product life cycles in their roles either as content providers creating products or as librarians purchasing them. Did they use KBART early in the process, when considering making a purchase or marketing a product? At the end of a subscription life cycle, is KBART helpful to librarians when canceling a package and managing perpetual access titles; could it be more helpful in this way? In the middle stages, are KBART files useful in any way in gathering usage data or checking accessibility? What did audience members look to KBART for, or wish that they could? What type of content gives them the most trouble, or for which they wish they had more metadata to help with content management?

Christine Stohn (Ex Libris), a member of the KBART SC, prompted respondents to think about the role of the knowledge base today and what it might be in the future.

Heaton expanded on the KBART SC’s need to understand what users were doing with KBART files as the committee works to balance the simplicity of KBART with possible future uses.

2.2.Breakout session feedback

Attendees in the breakout session provided feedback to the four questions on the EasyRetro board. Their feedback is listed below.

1. How are you using KBART today?

  • I support publishers who need to make KBART data available to customers.

  • We (platform) provide KBART files in demand for libraries.

  • We (publisher) share KBART files with institutions subscribing to our content. We offer generic KBART files and customized files as well.

  • We (publisher) share KBART files with institutions subscribing to our content. It is uploaded every other month into our digital library.

  • We are a publisher that creates KBART reports for every collection offered as a subscription as well as a global record for all those who have single title subscriptions. We also create custom reports on request. Each report is updated any time there is a change to our content offering (when new volumes are published).

  • We as a Content Provider do not currently provide KBART compliant files. We have extensive information in our title lists. If my team has questions related to creating compliant lists, where do we turn?

  • As a content subscriber (library) we use KBART files to cross-check content coverage and verify our metadata, or to auto-load holdings into our Library Management System in order to enable discovery and access.

  • We add holdings/update holdings in WorldCat via KBART.

  • Identify non-KBART Content providers and provide the necessary support and assistance.

2. How would you like to use KBART that is not possible today?

  • We would love to program automatic changes/updates to our KBART files. Currently we are updating them manually.

  • More automation.

  • Cover content types not currently supported.

  • Make connections to preceding/succeeding titles.

  • Linking related ISBNs. I wouldn’t want it in KBART per se, but perhaps as an extension of KBART.

  • Authority control fields for authors, e.g., ORCIDs.

  • Identify and use effectively all possible key identifiers (persistent identifiers etc.).

  • Straightforward map/crosswalk to other schema for metadata (e.g. MARC or Dublin Core).

3. What additional content types do you wish KBART supported?

  • Video, audio, archival materials, images, etc.

  • Audio-visual materials – there is a huge demand for streaming media currently!

  • KBART for standards.

  • What about the newest media types: simulations especially, but there are Augmented Reality (AR) and Virtual Reality (VR) as well.

  • More granular items, from book chapters and articles to “non-standard” and unpublished materials such as archival materials, manuscripts, and ephemera in digital archives.

  • Conference materials… some are audio, some video, some audio with slides. If they are treated just as their media type do they need to be considered a separate content type or do they then have a series or something that links them to the conference or paper, etc.

4. What additional fields would best support new content types?

  • A “content-type” field.

  • Duration, format, more granular content type.

  • Additional contributor fields. For example, if video content types are added Director may be relevant.

  • Relevant identifiers for audio-visual and other non-textual formats.

  • As content types are added should we have a dedicated KBART file for each content type for readability? (Columns depend on the content type).

  • If KBART is to cover more complex content types it will need to have a lot more fields for bibliographic description to handle the complexity of that content.

  • Content, carrier, media fields as per Research Data Alliance (RDA) standards.

  • More description for non-traditional and unpublished content such as archives and ephemera in digital collections.

  • Provenance.

  • DOI.

  • Something to indicate Open Access (OA) status. There is the Access type field (Free or Paid) but could there be something at the journal/serial level for OA status?

  • Certainly Open Access status.

  • Open Access model or identifiers that consider that access to content can change.

  • Accessibility compliance statement such as W3C Web Accessibility Initiative (WAI).

  • Machine generated books/journals related content type (future content types).

  • If the metadata was generated only by machine learning.

  • See Open Discovery Initiative Recommended Practice http://www.niso.org/publications/rp-19-2020-odi.

2.3.Breakout session summation

As he reviewed the responses posted to the EasyRetro board, Heaton commented that additional customizations and modifications to KBART could add value, but they will need to be weighed against an increased barrier to entry for content providers who create KBART files.

Andrée Rathemacher (University of Rhode Island), co-chair of the KBART SC, echoed Heaton’s point. She explained that KBART files are used to populate knowledge bases and essentially indicate the titles available in packages or databases, along with dates of coverage and linking information. This enables library users to link to appropriate copies of information resources, such as a journal on JSTOR, but not ScienceDirect, or a book on Project MUSE, but not EBSCOhost. What KBART does not provide is metadata for discovery, for example what would be found in a MARC record, and it also does not offer a level of granularity that would list all of the articles in a journal or the chapters in a book. In Phase III, the KBART SC wants to expand KBART to make it more useful, in part by incorporating more content types, yet also wants to keep it lightweight and easy to adopt, and discourages thinking of KBART as a tool to provide metadata for discovery.

Heaton added that while KBART is not intended to provide all of the metadata available in a MARC record, it might be possible to envision a tool that could generate MARC records from the information contained in a KBART file, with the recognition that such records would have limitations.

Rathemacher concluded by noting that the KBART SC is wrestling with the fact that KBART files list content at the container level – volumes and issues of a journal and entire books. Metadata about content at a more detailed level, such as articles in a journal and chapters in a book, and links to that content, are provided by discovery systems, indexing and abstracting databases, and tools such as Google Scholar. This is becoming problematic, however, as access to content is increasingly determined at a more granular level. For example, some publishers now sell custom packages of curated articles and chapters on particular topics. Similarly, hybrid Open Access is defined at the article level. In addition, as the KBART SC plans for adding more content types to KBART, it will need to figure out how to handle videos that are components of articles or individual episodes of a podcast. Plans for KBART Phase III include creating a roadmap for addressing this issue.

As the breakout session ended, Levin thanked attendees for their valuable input.