Common Ground: The Importance of Standards and Recommended Practices

Electronic Data Interchange

Electronic Data Interchange (EDI) is a standard that falls in the Acquire portion of the e-resource lifecycle. EDI is used in many sectors including finance, healthcare, and government. In the library and information community EDI is used by acquisitions and serials librarians, library staff, subscription agents, book vendors, and library system providers. EDI is a technical process that uses electronic files to share information from one system to another. The encoding and structured format allow systems to interpret and process the information in the file. Julia Reijnen explains that “with EDI standards, the structure and exact order of the data is defined, ensuring uniformity and consistency.” The use of standard formats makes it possible for a “system to understand the incoming data without human intervention.” EDI is often used to manage business transactions, such as ordering, billing, and claiming.¹ Without EDI, an organization would manually add the data about a transaction from a document into their system. The significance of EDI “is that it standardizes the information communicated in business documents.”² Manually entering data is time consuming and “highly prone to error” whereas EDI “improves an organization’s data quality.”³ EDI provides automation and efficiencies and thus enhances library workflows.

Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) is an EDI standard created by a United Nations committee in 1987. EDIFACT is the format in use by the library and the publishing community. The use of EDI in the library world began in the 1990s with the adoption of EDI by the book industry.^4,5 Subscription agents and Integrated Library System (ILS) providers followed in the mid-1990s to early 2000s.^6,7,8 EDItEUR is “the international group coordinating development of the standards infrastructure for electronic commerce in the book, e-book, and serials sectors.” The EDIFACT format standard documentation can be found at the EDItEUR website.

There are different kinds of EDIFACT files, called messages, identified by a code such as ORDERS or INVOIC. Within a message are segments usually marked by three-character codes that describe the data that follows. The codes and data must be arranged according to syntax rules. A portion of an INVOIC EDIFACT file is shown in Figure 1. BGM stands for beginning of message and 380 is the document code for commercial invoice. The code JINV is the document name code for journal invoice and 0755928 is the actual invoice number.

Figure 1.

Figure 1. EDIFACT invoice file

An INVOIC file can have data about more than one invoice in it. The information will be separated by another BGM line for the next invoice. LIN begins the first line item of an invoice. The details of the second line item will follow LIN 2. The item description, IMD, for this line item is the title Standards Monthly. The monetary amount, MOA, is $2,591. The code RFF LI is for the buyer’s reference code which in this case is the library’s ILS order number and is a common match point between the vendor’s system and the library’s system. The RFF SNA code is the agent’s reference number and also a common match point. Determining a match point that links the data between systems is critical for EDI to work.

A mock-up of an EBSCO invoice for the title Standards Monthly is shown in Figure 2. Variable data from the invoice such as title, line item cost, and vendor reference number would need to be transferred into the library system. Figure 1 shows the invoice data coded as an EDIFACT message. Figure 3 shows a record in the library’s system with the variable data populated in the proper fields.

Figure 2.

Figure 2. Invoice for the title Standards Monthly

Figure 3.

Figure 3. Invoice line item record in the library system

Configuring a library system for EDI requires mapping how incoming messages are processed. The segment codes are matched with the library’s system fields so that the variable data in the file are transferred to the appropriate field in the library’s system. Once fields are mapped and other configurations are set the processing of a file is a straightforward task. An email alert is set to the customer with file information such as invoice numbers, number of line items, total amounts and has instructions on how to access the file. The file is retrieved and uploaded (this will vary by system). The end result is that an invoice does not need to be keyed in manually, which is significant when processing invoices with hundreds of lines. Such efficiencies are made possible due to the adoption of a common standard.

KBART

The Knowledge Bases and Related Tools (KBART) recommended practices are integral to e-resource management in the following areas of the lifecycle: provide access, administer, and provide support. The creation, dissemination, and timely updating of KBART files by a content provider, followed by ingestion into a knowledgebase and configuration of the knowledgebase by a library are critical steps to providing authorized access and discovery of e-resources.

KBART was a UKSG (formerly United Kingdom Serials Group) recommended practice that began in 2007 and is now a NISO recommended practice that ensures the timely transfer of accurate data to knowledgebase and link resolver providers. KBART files are created by content providers using the guidelines in the KBART recommended practice and have evolved overtime to meet the needs of libraries. For instance, the original KBART recommendation only included fields relevant for journals. KBART Phase II Recommended Practice, the 2014 version, includes data fields for books, consortia, and Open Access. Please see Figure 4 for a complete listing of the 25 data fields for KBART Phase II Recommended Practice.

Figure 4.

Figure 4. KBART Phase II Recommended Practice Data Fields

KBART files are subject to updates for various reasons. Sometimes the content provider needs to update the files to correct data, provide updated links, include new publications, and account for withdrawn or transferred titles. Therefore, most KBART files are treated as dynamic, rather than static files, and should be monitored consistently by all stakeholders. Building on the example title from the EDI discussion above, Figure 5 is a sample of a KBART file, containing the title Standards Monthly.

Figure 5.

Figure 5. Sample KBART file

KBART is intended to provide high-level descriptive metadata that points to where content is hosted. In the case of Standards Monthly, there are unique identifier fields representing the title’s International Standard Serial Numbers (ISSNs) for print and online formats, and Digital Object Identifier (DOI) respectively. The available date range and enumeration information for this title is also included. The Uniform Resource Locator (URL) for the title is critical information for link resolvers to be able to channel users to the online content.

KBART files include data regarding previous titles. On the third row, we can see that Standards Monthly was previously called the Journal of the Data Standards Society. The fourth through ninth columns in the KBART file indicate that the title changed its name in 1996 after the 12th issue of volume 32, becoming Standards Monthly in 1997. The KBART access_type field indicates whether a title is free (F) or requires a payment (P).

Figure 6 demonstrates the dataflow of KBART files. Moving from left to right on this diagram, the KBART dataflow starts with the content host or content provider who are responsible for creating, updating, and disseminating the KBART files. The updated files then get routed to the knowledgebase vendor. Then the library makes configurations and title selections in the knowledgebase which enables discovery tools to provide access to library patrons. Any mistakes in the KBART file can negatively impact those downstream, such as librarians and library users. It is critical for the content provider to dedicate resources and time towards their KBART files. The importance of knowledgebases and KBART files cannot be overstated. They are the backend of most journal A-Z lists and are essential for OpenURL link resolvers to provide targets for users to access authenticated content.

Figure 6.

Figure 6. KBART in the information and metadata exchange ecosystem.

Adapted from KBART: Knowledge Bases and Related Tools (2010, fig. 2)

There are still several challenges in e-resource management including the time intensive manual selection of titles, the exclusion of some journal title history, incomplete journal transfer information, outdated linking, difficulty in identifying relevant collections or packages, lack of coverage for all content types, limited Open Access content, and erratic update schedules.⁹ The KBART Automation Working Group released a recommended practice in June 2019 to address the challenge of manual title selection by libraries.¹⁰ Originally developed by Elsevier in 2016, it was a proprietary means for communicating library holdings information to vendors. Later the NISO KBART Automation Working Group was formed, which included members from all stakeholder groups. The recommended practice dictated the terms for data delivery utilizing an application programming interface (API) to send library holdings data from a content provider on behalf of the library to a knowledgebase. For libraries that opted-in, the manual work required to reconcile their title level holdings in the knowledgebase was minimized. Current content provider participants are Elsevier, JSTOR, Ovid, ProQuest, Rittenhouse, SpringerNature, and Wiley. Implementation of KBART automation on the part of a publisher is very complex, but KBART Automation Recommended Practice providers a clear blueprint for sharing and ingesting metadata.¹¹ Currently the number of participating knowledgebase providers is limited, but hopefully more will join in the future. The KBART recommended practices and KBART files form the cornerstone for communicating crucial title and institutional specific data among providers, vendors, and libraries. KBART files power library backend operations and influences front end discovery for library users.

COUNTER

Counting Online Usage of Networked Electronic Resources (COUNTER) statistics are found in the Evaluate-Monitor section of the e-resource lifecycle. COUNTER usage statistics are provided by content providers. This standard was launched in 2002 to improve the reliability of online usage statistics through codes of practice.¹² This standard has gone through various releases and today the most current Code of Practice is Release 5.1.¹³ The COUNTER code of practice normalizes usage data for librarians and the COUNTER organization (formerly Project COUNTER) works with platform providers and publishers to ensure data is consistent and reliable.¹⁴

The Counter Code of Practice Release 5.0.2 is available at the COUNTER website and provides details about COUNTER reports.¹⁵ There are four types of reports provided in COUNTER usage statistics: platform, database, title, and item. A platform report provides usage from the platform, not the individual items subscribed or available on the platform. Database reports provide summary of activity related to a given database or fixed collection of content. Title reports provide summary of activities related to content at the title level and provide a means to evaluate the impact a title. This is where e-book and e-journal usage is found. Item reports give a summary of activity related to content at the item level such as streaming media content, or non-textual content like images.

The glossary found in the Counter Code of Practice Release 5.0.2 clarifies the meaning of terms used in COUNTER reports. Total item requests show collectively how many times a resource has been used regardless of whether by the same user. The unique item requests metric counts the first use by a user, which means although a user may have accessed a journal article more than one time the report will only record it once. Usage is tracked by log file analysis and page tagging or distributed usage logging (DUL).¹⁶ In the end, usage can be tracked across all platforms and content types. The reports help librarians make informed collection decisions across platforms to better redirect institutional funds to resources for users and are essential when making collection development decisions.

Available at the COUNTER website is the Release 5.0.2, The Friendly Guide for Librarians which provides useful scenarios to assists librarians in understanding the statistics and they best way to use them.¹⁷ For example, if a librarian decided to renew a subscription to the title Standards Monthly, they most likely referred to a COUNTER usage report like the one in Figure 7. This report also displays usage for the preceding title, Journal of Data Standards Society. Librarians must decide if the usage found in the report is worth the cost of the subscription. Evaluating statistics that are not COUNTER would involve librarians trying to compare a COUNTER usage report with a non-COUNTER report to find commonality and would require a judgement call as to whether the usage data is comparable.

Figure 7.

Figure 7. sample COUNTER report

Conclusion

Managing the lifecycle of e-resources requires transferring data at each stage. Standards permit transfer of data within and outside the library. Standards provide a common language that contributes to efficiencies and interoperability between systems. Without broad adoption of standards linking technologies would not function smoothly, procurement would be less automated, and evaluating usage of e-resources would be difficult. Standardization in the management of electronic resources helps publishers, vendors, librarians, and users.^{18,19,20,21,22,23,24,25,26,27,28}