Serials automation

In a strict sense, the term automation refers to the application of machinery to perform work that would otherwise be done by human beings. Therefore, the use of photocopiers, facsimile machines, and (in bygone days) typewriters in libraries could technically fall under the rubric library automation. Currently, however, library automation is generally understood to refer to the use of computers, computer networks, or CD-ROM – the meaning used in this chapter.

Serials automation covers several distinct concepts, including automating serials control procedures in libraries, the electronic journal, automating bibliographic access to serials, and automated vendor services. Some of these topics have been dealt with wholly or partially in other chapters, such as the electronic journal in chapter 9. This chapter discusses the history of serials automation, the role of standards, and steps in the automation of serials processing. The focus is on automation’s use for serials management and control rather than technological details about hardware, software, systems specifications, etc. No attempt is made to compare systems, and mention of a particular system should not be interpreted as endorsement.

History of serials automation
The application of computer technology to library functions is greatly considered to have begun during the 1960s or 1970s. Yet as far back as the 1940s, Ralph Parker, at the University of Texas at Austin, reportedly experimented with modifying for serials control his circulation system based on Hollerith punched cards. During the 1950s scattered reports on the application of noncomputer technology to serials management appeared in the literature. For example, in 1953 Ralph R. Shaw described the use of Photoclerk, which made photographic reproductions of serials records, in periodical claiming, routing, ordering, and renewing at 11 U.S. libraries, including Columbia University, the Enoch Pratt Free Library, and the U.S. Department of Agriculture. A Flexowriter Automatic Writing machine was used to create periodical holdings lists at the U.S. Naval Postgraduate School library in Monterey, California.

The earliest computerized serials systems were developed in-house, often by an academic library collaborating with a university computing cente. Vendor-supplied systems were not available on the market, so libraries wishing to automate serials had no other option. Patrick G. Kilgour writes that the first computerized serials control system was developed at the University of California at San Diego library in the early 1960s. Prepunched cards corresponding to serials issues were processed at the university computing center. This system produced lists of serials holdings, received items, nonreceived items, claims, and expired subscriptions as well as binding lists.

Gary M. Pitkin notes that certain functions were likely to be automated with each other, such as check-in and claiming, binding and holdings information, and routing and renewal. Moreover, the earliest automated serials systems were rather crude by contemporary standards. They tended to focus on creating lists and operated in a batch mode.
The Kansas Union List of Serials, issued in 1965, was reportedly the first computer-produced, multiple-institution serials holding list. It listed 22,000 serial titles held by eight academic libraries. During the 1970s computer technology was used to produce the Pennsylvania Union List of Serials and the Minnesota Union List of Serials as well as similar lists at the University of California in Los Angeles (UCLA), Stanford, and the University of California at Berkeley.

By 1968 an online serials control system was operating at Laval University in Quebec, Canada. Undoubtedly the most famous in-house serials system was PHILSOM (Periodical Holdings in the Library of the School of Medicine), developed by the School of Medicine Library at the University of Washington (in St. Louis) and originally implemented in 1962. William Saffady lists the San Francisco Public Library and the UCLA Biomedical Library, as well as the libraries at the University of Arizona, the University of Massachusetts, and the University of Washington, as others that implemented their own custom-designed online serials control systems during the early decades of library automation.

Several of the successful systems were adopted for use, often with modifications, in other libraries. For example, the Lister Hill Library of the Health Sciences at the University of Alabama at Birmingham adopted a modified form of the PHILSLOM system in the late 1960s and in the mid-1970s implemented a modified version of the UCLA Biomedical Library controls system.

The late 1960s and early 1970s saw the development of the four major North American bibliographic utilities: OCLC Online Computer Library Center (OCLC), Western Library Network ( WLN), Research Libraries Information Network (RLIN), and University of Toronto Library Automation Systems (UTLAS, now called ISM Library Information Services). Their initial purpose was to support the automation of the cataloguing function, but they now offer a wide variety of services, including retrospective conversion, authority control, archiving electronic journals, and so forth. The widespread acceptance during the 1970s of the MARC r ecord (machine readable cataloging), including the MARC-S (machine readable cataloging serials format), was a major boost to library automation. The Cooperative Online Serials Program (CONSER) project (discussed in chapter 8) to create machine readable bibliographic records for serials, became operational in 1973.

During the 1970s many of the in-house serial systems of the 1960s were upgraded and converted to online. During the late 1970s OCLC introduced its serials subsystem for check-in, which Sara Heitshu describes as “never a total success... [but] a highly visible project and much discussed by librarians.”

However, the decade’s major library automation efforrts focused on circulation, which, along with cataloging, was one of the first two functions to be automated. According to Saffady, circulation lent itself well to automation because of its labor-intensive nature and because its resemblance to inventory control was easily understood by computer specialists with little knowledge of library operations. Although there is no reason why serial volumes can not be bar coded and circulated, circulation automation was clearly oriented totward monographs.
In the 1980s, vendors began offering a variety of serials automation options to libraries, so that in-house development was no longer a necessity or even a desirable option. Heitsu reports the number of vendors marketing automated serials control systems increased from 4 in 1980 to 60 in 1986. Early in the decade serial subscription agents began offering access to their databases on a time-sharing basis. For example, in 1981 Faxon introduced the LINX system, which offered serials check-in and access to payment records. Its DataLINX provided online access to the Faxon database of more than 200,000 titles. EBSCO also introduced EBSCONET.

The major automation developments of the 1980s were Online Public Access Catalogs (OPACs) and integrated systems – both of which often treated serials as a stepchild. An integrated system uses a single database to perform such basic library functions as cataloging, circulation, acquisitions, and serials control. The same bibliographic r ecord is linked to separate records for ordering, payment, routing, etc. Using of the same record for multiple functions is cost-effective and reduces the probability of inputting errors. When all modules are fully functioning, an integrated system allows exchange of information among the various modules, so that received serials issues or new serial titles on order can be displayed in the OPAC. Unfortunately, serials control was all too often among the weakest modules or the last to be fully developed. Many of the initial OPACs did not include serials holdings information. However, serials presented an automation challenge because of their ongoing nature, frequent title changes, and the number of exceptions involved in serials work. Heitshu stresses that academic libraries now had a choice between the serials module of an integrated system (e.g., GEAC or NOTIS) or a stand-alone serials control system, such as B. H. Blackwell’s PERLINE.

During the 1980s a number of microcomputer-based serials control systems for small and medium-sized libraries entered the market. Saffady mentions CHECKMATE, marketed by the Cooperative Library Agency for Systems and Services, and the SC350 Serials Control System, developed by OCLC, as examples. In 1982 REMO was developed by Readmore, and in 1986 Faxon introduced Micro-Linx, SMS Canada produced the DavexPC serials management system, and Dawson U.S. acquired PC Max, developed in the early 1980s by Dawson U.K.

Also during the same decade, many libraries began using off-the-shelf word processing or database management software run on microcomputers for a variety of serials management or control functions, such as creating print-format serials holdings lists, budget control, assigning titles to subjects and departments, and organizing data for cancellation projects. Some commercial binderies began marketing their automated binding systems to libraries.
The 1980s witnessed the rise of so-called turnkey vendors, who provided libraries a complete automation system, including hardware, software, installation, staff training, and ongoing maintenance. The term’s derication refers to the library ability to metaphorically “turn a key” and receive an automated system – just as one can turn a key and drive an automobile off a dealer’s lot.

In 1987 Roy Rada and his collaborators published a paper about the use of expert systems for journal selection in the field of medicine. However, this was not representative of a major trend of the decade. Indeed, the use of expert systems for library materials selection has only been tentatively explored by a few scholars.

A 1985 survey of college libraries by John A. Camp and others found that only 12.5 percent of the respondents (26 of 208) had online serials control systems: 8 (30.8 percent) were from bibliographic utilities; 7 (26.9 percent) were developed in-house; and 3 (11.5 percent) were obtained from turnkey vendors. At the same time, 35.8 percent (73 of 204) took part in online union lists of serials. A 1986 survey of Association of College and Research Libraries (ACRL) college library directors by Jamie Webster Hastreiter, Larry Hardesty, and David Henderson found that 52.5 percent (62 of 118) had automated at least part of their periodical operations. Specifically, 10.2 percent had automated periodical ordering; 16.9 percent, check-in and claiming; 41.5 percent, holdings and 22.0 percent, periodical cataloging.

The 1990s represent the fourth decade of library automation, yet in 1995 Chiou-sen Dora Chen wrote, “Finally in the 1990s, the time has come for serials automation.” A major trend of the mid- to late- 1990s is the shift to client/server integrated systems, although Jeff Berry, José-Marie Griffiths, and Gerald Lundeen wrote in April 1995 that the term client/server had become a “buzzword” whose precise meaning is ambiguous.
In the 1990s the vendor market remained somewhat volatile. In 1994 Trisha Davies and James Huesmann wrote, “In the past year, several serials control systems have been phased ouot of production, others have been replaced or updated by dramatically different versions, and new systems have been introduced. It is a dynamic, growing field.” Also system migration (i.e., changing from one automated system to another), and networking among libraries, sometimes on a statewide basis such as the OhioLinks project, continued to increase throughout the 1990s, as did interest in the Serial Item and Contribution Identifier (SICI) standard and X12 for Electronic Data Interchange (EDI), discussed later in this chapter. Web-based OPACs, with direct links to electronic journal Uniform Resource Locators (URLs), which allow the end user to proceed seamlessly from the catalog to the journal itself, represent a significant trend of the late 1990s. The other major automation developments of the 1990s – the Internet, the World Wide Web (WWW), and electronic journal themselves – have been discussed elsewhere in this book.

In summary, the major automation trends affecting serials may be briefly recapitulated as follows. Prior to the 1960s few attempted to apply primitive or noncomputer technology to serials control. During the 1960s a number of systems were developed in-house, first in a batch mode and later online. In the 1970s these systems were further developed and not infrequently adopted or modified by other libraries. The 1980s witnessed integrated systems, off-the-shelf software, OPACs, and stand-alone systems run on microcomputers. The major trends of the 1990s are system migration, the client/server model, the Internet, the WWW, and electronic journals. Who knows what developments the third millennium will bring?

The role of standards in serials automationBecause standards are necessary for automation’s effective use in serials management, they require considerable attention. What is a standard? According to the International Organization for Standardization (ISO), “Standards are documented agreements containing technical specifications or other percise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose.” There is not always a clear distinction between an automation and nonautomation standard because a single standard, for example, the International Standard Serial Number (ISSN), can be used in both an automated or nonautomated environment. Yet standards are especially critical to automation because they promote compatibility among different hardware, software, and systems. Accordingly, this section discusses the major organizations and standards that affect serials automation.

Standards organizations
The major standards organizations whose actions affect serials are described below.

American National Standards Institute
The American National Standards Institute (ANSI) describes itself as a “private-sector, nonprofit, membership organization” that serves as “administrator and coordinator of the United States private sector voluntary standardization system.” Founded in 1918, ANSI is headquarted in New York City with an additional office in Washington, D.C. ANSI is the U.S. representative in the ISO. This organization is probably familiar to readers because of the ANSI number assigned to adopted standards. ANSI has officially sanctioned at least six major standards pertaining to serials, several of which are discussed later in this chapter.

National Information Standards Organization
The National Information Standards Organization (NISO) is one of almost 300 U.S. organizations involved in developing technical standards for various industrial sectors. NISO specializes in standards pertaining to information. Its constituency comprises publishers, libraries, indexing and abstracting services, other information services, and automation vendors. NISO was founded in 1939 under the name the American National Standard Committee Z39. After some name changes and restructing, it incorporated as a not-for-profit educational association and assumed its present name in 1984. At present there are more than 55 voting members of NISO, including the Library of Congress, the National Library of Medicine, the American Library Association (ALA), Readmore, Faxon, and EBSCO. NISO publishes a newsletter entitled Information Services Quarterly, and NISO Press sells standards and draft statements.

A list of NISO standards may be found in a recent Bowker Annual. Among the six standards relevant to serials one should mention: ISSN (Z39.9-1992); SICI (Z39.56-1994); Serials Holding Statements (Z39.4-1986); and Electronic Manuscript Preparation and Markup (Z39.559-1987). The latter two are presently under review or revision.

International Organization for Standardization
The ISO (the abbreviation is from the French language, which is also used by this organization), founded in 1947, is a worldwide federation of more than 100 national standards organizations. The ISO Central Secretariat is located in Geneva, Switzerland. A keyword search of the ISO Catalog of Standards on the WWW under the term serials retrieved seven items, including ISO/DIS 3297 for ISSN and ISO 9230:1991 for “determination of price indexes for books and serials purchased by libraries.”

Book industry systems advisory committee
Although originally founded in 1974 for promotion of International Standard Book Numbers (ISBNs), the Book Industry Systems Advisory Committee (BISAC) later turned its attention to application of the ANSI Accredited Standards Committee (ASC) X12 standard for EDI in the book industry, explained below. BISAC should be noted because it has been termed a “sister Committee” of the Serials Industry Systems Advisory Committee (SISAC).

Serials industry systems advisory committee
SISAC was founded in 1982 at the behest of the Book Industry Study Group to develop serials automation standards for presentation to NISO and ANSI. It focused on three areas: computer-to-computer transmission of serials business transactions through the X12 standard for EDI; automation of serials check-in and control through the SICI standard; and standardization coding of articles to ease document delivery and royalty payments.

Its members include publishers, librarians, serial subscription agents, and document delivery vendors. Headquarted in New York City, SISAC publishes the SISAC Newsletter, SISAC News and SISAC-L – an Internet listserv for the discussion of SISAC business. Two of its major achievements have been the SICI and the SISAC Bar Code Symbol. In the early 1990s it began to focus on the application of EDI to serials.

Canadian serials industry systems advisory committee
Organized in 1991, the Canadian Serials Industry Systems Advisory Committee (CSIASC), is, as the name implies, the Canadian equivalent of SIASC. Through international committees, CSIASC has been collaborating with SISAC and the International Committee on Electronic Data Interchange for Serials (ICEDIS) on the development of EDI. CSIASC has also explored SICI, Standard Generalized Markup Language (SGML), and document delivery.

Automation standards
The major automation standards pertinent to serials are discussed below.

International standard serial number
The ISSN was discussed in chapter 2. Although not exclusively an automation standard, ISSNs contribute to the handling of serials in automated systems by allowing unique identification of a particular title and differentiating between serials with similar titles.

MARC
As stated on the Library of Congress Home Page, “The MARC formats are standards for the representation and communication of bibliographic and related information in machine-readable form.” MARC is, in the words of Walt Crawford, “the single most important factor in the growth of library automation in the United States and other countries.” Histories of MARC’s early development have been written by Henriette D. Avram and Karen M. Spicher. The Library of Congress developed and tested the MARC record during the 1960s. In March 1969 the Library of Congress began weekly distribution of MARC records for English-language books. MARC was adopted by ANSI as a national standard in 1971 and as an international standard by ISO in 1973.

MARC-S was initially published in 1970, and the Library of Congress began distributing MARC serial records in 1973. In 1974 a second edition of the MARC serials format was issued, and in 1977 it was implemented by OCLC.
Especially significant for serials is the MARC standard for holdings data. The Library of Congress published the USMARC Format for Holdings and Locations in 1984. The revised version, the USMARC Format for Holdings Data, Including Guidelines for Content Designation, was published in 1989. For an in-depth explanation of the MARC holdings format, see Frieda B. Rosenberg’s chapter on managing serials holdings in Marcia Tuttle’s Managing Serials.

By the end of the 1980s, there were nine types of MARC records, for holdings data, authority records, and seven bibliographic formats: books, serials, maps, computer files, music, visual materials, and manuscripts. The USMARC Format for Classification Data and the USMARC Format for Community Information were issued during the early 1990s.

Detailed examination of the MARC record’s structure is beyond this chapter’s scope, but the four basic components will be briefly outlined. The “leader,” the first 25 characters, contains information on the record itself rather than the bibliographic item being described and allows the computer program to read the record. Next, the “directory” indicates the position of each MARC field within the record, thus allowing the program to quickly locate specific information. The first 9 fields or “tags” of a MARC record (001 through 009) compromise the “variable control fields.” These generally use fixed-field codes (i.e., one, two, or three place numerals or characters) to present data about both the record itself and the bibliographic item. As Deborah J. Byrne explains, “The coded information in the fixed field expresses the information explicitly and succinctly. This allows a computer to recognize the information and use it efficiently and effectively.” Finally, the “variable data fields” contain the textual information that describes the bibliographic item being cataloged. The number of fields and the length of each will vary from record to record. Tags and subfield codes are used to help the computer program locate specific fields and subfields. For example, tag 247 identifies the field for a former title or title variations. An “indicator” conveys specific instructions to the system about processing or a field’s content. The reader is referred to Crawford and Byrne for further explanation of MARC record structure.

MARC’s major benefit is the creation of a uniform standard for machine readable cataloguing records. It thus promotes the exchange of records among libraries and the use of bibliographic utilities. Moreover, it renders a library’s database independent of specific hardware or software (as long as both are MARC compatible), thus supporting system migration. Yet, MARC may not be necessary for every automation objective. Crawford notes that “MARC is not the answer” for projects such as a small library’s current periodical list. It is doubtful that a full MARC record is needed for acquisitions.

MARC “format integration” has recently received considerable attention within the serials community. For well over a decade, the system of different MARC record structures for seven separate bibliographic formats was clearly creating problems, especially for serials. Ostensibly, such nonserial items as maps, video-cassettes, sound recordings, and computer files can simultaneously assume a serial form. MARC-S, developed for print serials, did not fully provide for describing the characteristics of nonprint materials. Further difficulties were presented by mixed media items, such as a map or datafile accompanying a periodical.

In 1988 the USMARC Advisory Group approved Proposal 88-1, which established the guidelines for format intetgration. After some delays, the Library of Congress began implementing format integration in early 1996 and the first records appeared in the MARC Distribution Service in March 1996. With format integration the seven separate MARC records have been replaced by a single record structure. A new 006 MARC field allows the cataloger to indicate an item’s secondary aspects (e.g., a datafile accompanying a periodical or the fact that a map is also a serial would be noted here). Also, many other fields, subfields, or indicators in MARC records have been added, deleted, expanded, or made obsolete by format integration.

According to Rosenberg, format integration’s practical implication for serials cataloging is that the nontextual format of nonprint serials will be their primary aspect, and seriality will be noted in the 006 field as a secondary characteristic. In other words, a serial computer file will be cataloged primarily as a computer file and secondarily as a serial. Wayne Jones and Young-Hee Queinnec proclaim that format integration’s major benefit is “better provision for the recording of data concerning nonprint serials.” Format integration should also improve searching and retrieval from online catalogs. Rebecca R. Malek-Wiley asserts, “because the same data should be in the same fields for all types of material, consistency both of indexing and retrieval and of display should be facilitated.” Possible disadvantages associated with format integration include the logistics of its implementation, the cost for reconfiguring computer systetms, and problems presented byolder MARC records p r edating format integration.

X12 for electronic data interchange
EDI refers to the electronic exchange of business data, such as purchase orders, invoices, etc. EDI offers some advantages over paper communication, including rapid transmission, verification that the message has been received, and reduction of both labor and the possibility of error because trading partners do not have to rekey paper messages into their systems. In the United States, EDI was first used in the transportation, pharmaceutical, and electronic industries, as well as in warehousing.

In 1979 ANSI established the ASC X12 for the purpose of developing the EDI standard, which is now referred to by that committee’s name – ASC X12 or simply X12. Although Frederick E. Schwartz wrote in 1991 that “in North America and much of the rest of the world, ANSI X12 is synonmous with EDI,” a European standard, the Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT), promoted by the United Nations Economic Commission for Europe, does exist. Although a scheduled convergence of ANSI X12 and EDIFACT in 1997 was reported in the literature, such an event has not taken place.

Because X12 is a general standard for business shipping, receiving, and invoicing, it does not explicitly address specific needs of the serial industry, such as claiming. Therefore, the SISAC is responsible for X12’s customization for serials, and, in 1990, appointed five subcommittees for this task. These committees first developed standards for claims, claims responses, and invoices before addressing purchase orders, purchase order acknowledgements, and other functions.

In the summer of 1995 the SISAC X12 Implementation Guidelines for Electronic Data Interchange were issued. These guidelines include five transaction sets (elsewhere defined as “highly structured computer messages that correspond to specific workflows”): 810, for invoices; 856, for shipping notice; 869, for order status inquiry (i.e., “claims”); 870, for order status reports (i.e. “claim responses”); and 997, for functional acknowledgement. Other sets in various stages of testing and development are 832, for price or sales catalog; 846, for inventory inquiry; 850, for purchase order; and 855, for purchase order acknowledgement.

The earliest applications of EDI to librarianship were, according to Linda Richter and Joan Roca, “proprietary,” that is, developed by specific organizations for communication with their customers. Because these early proprietary systems did not conform to a uniform national standard, a system used to communicate with one vendor would not work for other vendors.

The first serials vendor to use EDI was Faxon, which decided in the summer of 1989 to experiment with ANSI X12 instead of the ANSI/NISO Z39.55-199X Electronic Orders and Claims standard. It began a pilot project involving six publishers plus the Welch Medical Library of John Hopkins University, the University of Minnesota library, and the Miles Laboratories Library in Indianapolis. More recently, the literature describes Faxon’s experimental use of X12 to communicate with libraries from the Mankato State and North Dakota State Universities, Laurentian University (in Canada), and Dartmouth College. In July 1997 the Faxon Web page asserted that the company was sending 7,000 messages a month using X12.

Testifying to EDI’s significance, the Faxon WWW site lists nine serial titles devoted exclusively to the topic, including EDI Forum: The Journal of Electronic Data Interchange, EDI Monthly Report, and EDI World: The Source for Electronic Data Interchange Management. There is also a listserv, EDI-L, devoted to the discussion of EDI issues.

The X12 standard for EDI offers the opportunity for speedier and more-efficient communications among libraries, publishers, and serials vendors. Unlike ISSN and MARC, its full potential has yet to be realized. A related concept, Electronic Funds Transfer (EFT), is sometimes termed “the final stage of EDI” but to date has received considerably less attention in the serials community.

Serial item and contribution identifier and the SISAC bar code symbol
The SICI standard was developed by SISAC for uniquely identifying specific serial issues and articles and has been officially adopted as ANSI/NISO X39.56 (1991). Version 2 was submitted by the SICI Revision Committee to NISO on January 1, 1996. The standard allows creation of the SICI code from either a citation or the serial itself, regardless of whether the publisher has printed it on the item. A SICI code is illustrated in figure 10.1.

Fig 10.1. Illustration of a SICI Code
Item: “The Compaq Portable II.” Library Systems, v. 6, no. 6 (June 1986), p. 4 SICI Code: 0277-0288(198606)6:6L.4CP;1-
“0277-0288” = the ISSN for the serial Library Systems
“(198606)” = identifies the date as June 1986
“6:6” = identifies the issue as volume 6, issue 6
“L.4” = identifies the item’s location as beginning on page 4
“CP” = the first letters of significant words in the item’s title
“;1” = based on version 1 of SICI
“-“ = the final element is a check digit

SICI, when encoded in machine readable form, is known as the SISAC Bar Code Symbol. Because it can be read by a bar code wand, the SISAC Bar Code Symbol would allow more rapid serials check-in of issues marked with it. The SISAC bar code has received considerable support within the serials community. As of the mid-1990s many major publishers, automated library system vendors, and serial subscription agents were committed to supporting the SISAC Bar Code Symbol.

SISAC asserts that SICI has possible application to document delivery, interlibrary loan (ILL), copyright payments, and electronic reserve room use, among other functions. Arnold Hirshon and Barbara Winters conjecture that SICI might eventually allow serial issues to arrive in libraries already checked-in and that it has potential application to other automated serials functions (e.g., ordering and claiming).

Other standards
Some leading STM publishers have proposed a Publisher Item Identifier (PII) for providing unique identification of documents, such as serial articles, book chapters, or any other unit the publisher wishes to sell. It is based on a 17-character alphanumeric code assigned by the publisher. The PII has been adopted by the American Chemical Society, the American Institute of Physics, the American Physical Society, Elsevier Science, and the Institute of Electrical and Electronics Engineering (IEEE) for all articles published after January 1, 1996. Proponets of this standard assert it is compatible with ISSN and SICI, but, unlike SICI, it can be assigned to an item before it is published and allows a document to stand alone rather than be viewed as part of a serial or a book. Moreover, the PII applies to all forms of a document: print or electronic, varying electronic forms, and a serial article reprinted as a book chapter.

The Association of American Publishers has been developing a Digital Object Identifier (DOI) system for uniquely identifying “works which are brought, sold or accessed over digital networks” for such purposes as copyright management, ordering, billing, and bibliographic control. In April 1997 the International Publishers Association decided to support the DOI system. The DOI number consists of two parts: a prefix assigned to the publisher by the DOI agency and a suffix assigned by the publisher. According to the Information Identifier Committee of the International Publishers Association, “the [DOI] system is far from complete” (i.e., an international network of registration agencies must be established and the underlying technology tested). A public presentation of a DOI prototype was scheduled for demonstration at the Frankfurt Book Fair in October 1997.

The PII has not yet been adopted by national agencies, and the DOI system is still under development. Hence, their ultimate acceptance and impact upon libraries and the serials industry can not be predicted. It is also unclear to what extent the PII and DOI system will complement or conflict with each other.

Summary
Standards are important to automation because they support networking, sharing of records, and communications among the major players in the serials arena. Compliance with standards is voluntary. But a standard’s widespread adoption is necessary for its ultimate success. In this rapidly changing environment, new standards evolve and older ones become obsolete.

Automation of bibliographic access to serials
Provision of bibliographic access to serials could be viewed as a subset of serials control, yet it is important enough to warrant a separate discussion. In the broadest terms, this heading includes access to
1. serial titles;
2. serial issues, which are often termed “holdings” and
3. specific articles, which are generally accessed through “indexing.”

Some CD-ROM products, such as Ulrich’s Plus or EBSCO’s Serials Directory offer bibliographic access to serials titles. Beginning in 1992 the International Serials Data System (ISDS) database has been available in CD-ROM format as ISDN Compact.

Bibliographic control at the article level has long been provided by online access to indexes and abstracts through such services as DIALOG. Beginning in the mid-1980s an ever-increasing number of indexing and abstracting services have been issued as CD-ROMs. In the mid-1990s libraries often have three automation options for accessing indexes and abstracts: online access, CD-ROM, or local mounting of the database.

In the past OPACs have provided much better access to monographic holdings than to serials. Basic questions on serials access and the OPAC follow: Are serial titles included in the OPAC? Is holdings information included? Are indexes available through the OPAC? Is dial-in access available? Is a password required for dial-in access?

Serials access will be a major component of an ongoing project, the CIC Virtual Electronic Library. Using the Internet and OCLC WebZ software, the project will eventually allow end users at the CIC institutions to seamlessly search the OPACs of the 12 CIC libraries along with numerous databases. Bibliographical access will be provided to 550,000 serials (along with 60 million books), and end users will be able to initiate ILL and commercial document delivery requests.

Although not traditionally thought of as part of bibliographic control, access to serials collections could be considered a fourth level. Electronic journal collections accessible to the Internet have been discussed in chapter 9.

Automation of serials control procedures
In the systems analysis approach to automation, one examines the tasks that must be performed and then asks how automation can perform those tasks. The traditional serials control functions discussed in chapter 8 (e.g., ordering, claiming, check-in, fund accounting, etc.) can be performed by an automated systetm. Indeed automation of each serials function presents its own set of challenges, but a function by function analysis is not within this chapter’s scope.

Record keeping represents a major component of serials processing. Indeed, some serials textbooks devote an entire chapter to the discussion of serials records. A group of records organized together constitutes a file. Important files for serials automation include bibliographic, holdings, order, vendor, binding, claims, check-in, and fund accounting records, and (for larger libraries that order abroad) currency conversion. For a useful discussion of file integration in a serials control system, see Trisha Davis and James Huesmann.

The discussion and comparative evaluation of specific serials control systems are beyond this book’s scope. An exceedingly valuable source of comparative data on automation vendors and automated systems is the Library Technology Reports, published by the ALA. For more than a decade, Library Journal has offered an annual automation report in its April 1 issue (this does not, of course, imply that the topic is an April Fools’ Day joke). This series has provided a valuable introductory overview of the automation market. Each annual article summarizes major trends of the previous year, profiles major vendors, and provides considerable data on the number of system installations by leading vendors. A particularly useful feature is an appended list of the names, addresses, and telephone numbers of currently active vendors.

A similar annual automation survey has appeared since the mid-1980s in the Library Systems Newsletter, published by Library Technology Reports. This survey is usually divided into two segments covering 1) PC or MAC-based systems and 2) all others. Market trends and profiles of leading vendors are included. In 1989 John Corbin offered a comparative summary of the serials control functions in 24 automated systems, and in 1992 Richard W. Boss offered a similar functional summary of 26 systems. Davis and Huesmann’s Serials Control Systems for Libraries, published in 1994, compares five microcomputer-based serials control systems in terms of local files, functionality, and system requirements: the SC350, Micro-Linx, DavexPC, PC Max, and REMO.

An automated serials system offers the advantages of greater speed, accuracy, efficiency, and the ability to provide new services (e.g., public services access to serials check-in and holdings records). An early impetus to library automation was the desire to reduce staff and increase savings, although it is doubtful that automation results in either.

An automated serials system can generate data that are quite useful in collection management, especially in the areas of macroevaluation and budgeting. A report of serials expenditures by subject or department in a series of previous fiscal years can assist in reaching or evaluating such budgeting issues as the overall serial budget’s division among subject areas, the proportion of departmental materials’ expenditures devoted to serials, and the projection of budgetary requirements for the forthcoming fiscal year. As a downside, it can sometimes be difficult to extract the needed data from the system or customize it to your library’s particular needs. Data from a serials subscription agent may be limited to the library’s subscriptions with that agent. Anecdotal evidence suggests that many librarians feel that automated systems have not lived up to their full potential in providing collection management data.

In addition, an automated system can be quite expensive, and considerable staff time and effort is required to implement it. Vendors may advertise automated products that are not fully developed. An automated system has a finite life expectancy – often estimated at five to seven years. Most present serials control systems are tied to the traditional ownership paradigm and are geared to ordering, claiming, checking-in, etc. serial titles that will be housed in the library’s collection rather than handling electronic journals or document delivery of articles. There may be unforeseen and unintended consequences (e.g., automating serials check-in places greater pressure on serials staff to make current periodical issues immediately available).

Steps in the serials automation process
Because many textbooks address automation planning in libraries, a detailed description is unnecessary. Case studies of serials automation projects in specific libraries are too numerous to summarize. The basic steps would apply to the automation of any library function, but the discussion addresses issues pertaining to serials. In the current automation environment, a library usually purchases a system rather than developing one in-house. For a library implementing the serials module of its integrated system, several of the steps would be skipped or abbreviated.

Establishing a timeline
The initial step should entail outlining the tasks that must be accomplished and setting a deadline for each. Various types of planning charts, such as a Gantt chart, can be used. However, as the library proceeds through the project’s various stages, reision of the deadlines and addition of new tasks may be required.

Staffing
Staffing arrangements for serials automation should be made fairly early in the planning process, if for no other reason than it is the staff who implement the project. Use of a committee or task force represents a standard approach. (A committee is ongoing, whereas a task force disbands when its goals have been achieved. Accordingly, the latter term is technically correct in regard to most library automation projects, although in practice both terms are used.) A large project (e.g., bringing up an integrated system) might use a complex set of task forces and subcommittees covering each module aswell as such specific tasks as database content, site preparation, screen design and so forth. The serials control automation task force would typically be chaired by the serials department head or team leader or another key professional staff member. In larger libraries, representatives from other departments with an interest in serials, such as public services, cataloging, or acquisitions, should be included on this task force. Likewise, the serials area would be represented on other task forces whose responsibilities impact serials (e.g., cataloguing, design of the OPAC design, etc.).

The serials staff, both professional and nonprofessional, should be involved in planning the system implementation from an early stage. Although the staff may not have computer expertise, they should certainly understand the processes to be automated. Staff involvement will also contribute to their psychological acceptance of the automated system.
A strategy for staff training should be a necessary part of any automation project. Because the serials module of an integrated system is often the last to be implemented, it is likely that serials staff will already have experience using the other modules, thus reducing the required training. Unlike for the OPAC,user education would not be an issue for a serials control system. Hazel Woodward and Margaret E. Graham offer practical tips on staff training for serials automation, including brief sessions, a small number of participants, and hands-on experience.

Analysis of the library’s needs
This critical step involves analysis of the library’s present situation and what it wishes to achieve through automation. One should examine such fundamental factors as the available hardware, library size, financial resources for the project, and the extent of retrospective conversion of serial titles. Based on these considerations, the first decisions concern the basic approach to be used: a stand-alone system versus a module of an integrated system; upgrading the present system or migrating to a different one. The level of automation already achieved will affect serials automation decision making. For example, if a library already has an integrated system, does it wish to install that system’s serials module, substitue a stand-alone serials system, or attempt to interface the serials module from a different integrated system?

Also included in needs analysis would be a list of functions one expects the system to perform and standards to which it must conform. Boss outlines 96 functional requirements recommended for a local library serials control system, specifically listing 10 capabilities: serials holdings display, ordering, claiming, receiving, routing, vouchering, binding preparation, funds accounting, union listing, and notes fields. Boss also recommends the ability to search serial records by 18 different fields (e.g., title, variant title, call number, ISSN, uniform title, etc., and conformance with the SISAC standard). More recently, James R. Mouw outlined more than 60 criteria for selecting a serials system.

One would obviously consider the number of serial titles and projected future changes. Although library automation textbooks stress the importance of projecting future growth trends, this will probably not be a major issue in serials automation because most libraries are unlikely to be anticipating a future increase in the number of their subscriptions.

Identification of candidate systems
This step, which logically follows from the needs analysis, might be conceptualized as a two-stage process:

1. identification of the available systems that meet the library’s basic specifications; and
2. from the set of the systems identified in stage one, selection of a small number of leading candidates.

A possible stating point for gathering the information necessary for this process would be AcqWeb’s “Guide to Automated Library Systems, Library Software, Hardware and Consulting Companies,” on the WWW. Other tactics include surveying the literature, informal contacts with colleagues, and visiting the exhibition booths at ALA conferences. Sometimes the investigation may reveal that only a few systems meet the library’s requirements, so further winnowing of candidates as depicted in stage two is unnecessary.


Selecting a system
An approach to selecting an automated system that has received considerable attention is the Request for Proposal (RFP) – a legalistic document that concisely outlines the library’s specifications. Vendor RFP responses can be used to evaluate a candidate system, make a final selection, and to begin negotiations on a contract with the selected vendor. It should be noted, however, that many libraries do not use the RFP approach.

Numerous strategies are available for gathering information to assess candidatet systems. A literature review would be advisable. One can request on-site demonstrations by vendors. Informal contact with other librarians using the system can be quite helpful. Many systems have organized user groups that could be a source of information. User listservcs for several major systems – including NOTIS-L (for NOTIS), VTSLIST (for the Virginia Tech Library System) – and their subscription addresses are included in the Directory of Electronic Journals, Newsletters and Academic Discussion Lists. Not infrequently, postings appear on SERIALST requesting evaluative comments about a particular automated serials system.

Basic criteria for evaluating a system include functionality, cost, vendor reputation, vendor support, support of standards, documentation, degree of computer expertise and staff training required. Depending on a library’s situation, the ability to interface with other systems could also be a criterion.

Most textbooks advocate the development of “decision rules” for system selection. Joseph R. Matthews outlines five specific evaluation methodologies. “Subjective judgement” uses opinion rather than an objective method. The “Cost-only technique” selects the least-expensive system meeting all the library’s requirements. In the “Weighted-scoring technique,” the library assigns point values to desired system features and selects the system scoring the most points, based on its features. The “Cost-effective ratio” approach uses the weighted-scoring technique but divides each system’s total costs by the number of points received to select the most cost-effective vendor. Finally, the “Least total cost method” selects the system meeting all mandatory requirements that is least expensive to install and operate for five to seven years.

Contract or purchase agreement
After selection, the next step would be negotiating and signing a contract or purchase agreement with the vendor. Note that the vendors’ standard contracts are written to their advantage rather than the library’s. A library can sometimes negotiate more favourable terms with a vendor. If a library has used an RFP, its provisions might be incorporated with the contract. Most textbooks advise that the library have an attorney review any documents before they are signed. In implementing the serials module of an integrated system already in the library, this step would already have been applied.

Site preparation
According to David C. Genaway, the two most critical components of implementing an automated system are “people preparation” and “site preparation,” which involve “the physical aspects of installing and running a computer-based library system.” Site preparation addresses such issues as determining wher terminals and printers will be placed; locating power sources (e.g., wiring and electrical outlets); preparing the floor layout; and adding such communications channels as phone lines and port access. Several other major automation issues, including security, file backups, and ergonomics are often considered part of site preparation. Site preparation issues would normally be addressed on a librarywide basis for the entire automation system, but serials automation would entail site preparation for the serials department or work area and possibly for a current periodicals reading room.

Database preparation
Database creation can be one of the most expensive and time-consuming aspects of serials automation, especially for larger libraries. Two interconnected tasks arer involved: retrospective conversion of records and loading the records into the automated system. Retrospective conversion has been defined as “the process whereby records only humans can read are transformed so that computers can read them, too.” Converting records from one format to another is termed conversion, and retrospective refers to the conversion of preexisting records. A recent search in the Library Literature CD-ROM indicates that 35 articles have been published on serials retrospective conversion since 1984, so a lengthy discussion is unnecessary. Many of the articles published in the 1980s commented on the poor quality of the converted records. If a library is implementing an integrated system’s serials module, the retrospective conversion of bibliographic records for serials will probably already be completed.

According to Chen, “the main work” of serials automation is entering the records needed for acquisitions into the system’s database. She lists four types of records as the most critical for this function and discusses the problems associated with file creation for each: bibliographic, order, invoice and payment, and check-in. Sometimes a library’s subscription agents can electronically load order, invoice, and payment records into the system; otherwise, records must be entered manually – an obviously labor-intensive process. Of the four, loading serials check-in records can be the most difficult and was once compared to growing bananas in Greenland. Jean Walter Farrington notes that loading the serials database is often a two-step process: first the bibliograpic records, then order, invoice, and check-in data. She warns, “Be prepared for a more difficult and more time-consuming task than originally anticipated.”

Marlene Clayton and Chris Batt list six major issues in database creation: record content, adherence to standards, the source of records, the input method and staff resources allocated to the project, cost, and timing and sequencing logistics. A particularly crucial issue for serials concerns whether records are entered for inactive as well as active titles.

Finally, after the records are loaded, cleanup of problems and continued maintenance work are required. The importance of entering and maintaining accurate records can not be overemphasized. Inaccurate automated records are still inaccurate, despite the mystique computers enjoy. A database of high quality records assumes a life of its independent of any specific hardware or software, thus facilitating system migration.

Activating the system
As implied, this step entails putting the automated system into operation in place of the previous system. Corbin lists four basic strategies for activating an automated system: total, pilot, phased, and parallel. The total approach completely begins the new system while shutting down the old at a single time. In the pilot method, the serials control module would be tested in one branch or location prior to activation in the entire library system. The phased approach activates one function at a time. For example, serials check-in, ordering, routing, fund accounting, and other functions, would be brought up separately. In the parallel approach, the most conservative and expensive method, the new and old systems are operated simultaneously until one is confident the new system is functioning properly.

Acceptance tests
After activation, the final step involves verification that the automated system is operating correctly. Corbin outlines three types of acceptance tests: reliability (i.e., measuring downtime), response time, and functionality. Arguably, the functionality test is the most critical for serials. One works down a list of functions advertised by the vendor or included in the vendor’s RFP response, ascertaining that each is performing correctly.

System migration
By the late-1990s many libraries were migrating to their second or even third automation systems. Some case studies of serials system migration have been reported in the literature, for example, from MicroLinz to NOTIS at City University of New York’s (CUNY) Queens College, by Belinda Chiang; and from an in-house system to Innopac at the University of Massachusetts at Amherst, by Patricia Banach. Margaret Bell Hentz has described the conversion of serials bibliographic and holdings information from Faxon’s SC-10 system to a Techlib/Plus OPAC at Boehringer Ingelheim Pharmaceuticals, Inc., in Ridgefield, Conneticut. Other examples could be cited. Grace Agnew and Toni Lambert have recently published a guidebook addressing the technical aspects of system migration.

System migration entails unique problems, but the steps depicted above should remain essentially the same whether a library is moving from a manual to an automated system or migrating from one automated system to another. Yet as William W. Wan observes, “system migration is much more complicated than automating one or two manual procedures.”

Major migration problems include staff training for the new system and transfer of data from one system to the other. Carol Pitts Hawks (now Carol Pitts Diedrichs) has noted the problem involved in transferring payment history records as well as frequency and publication pattern data for specific serial titles. Wan, in analyzing the Texas Women’s University library’s migration from the GEAC GLIS 8000 to GEAC ADVANCE, comments that serials encountered the most problems, as enumeration and frequency information necessary for check-in was not transferred correctly.

It is advisable, if feasible, to begin the new system at the beginning of the fiscal year to simplify fund accounting. Chen advises that titles should be converted from the old system to the new in alphabetical order. 122 Often a special loader program may have to be written to transfer data from one system to another, but editing of records may be necessary.

Conclusion
Because almost every library function deals with serials, most library automation affects serials to some extent.

A number of authorities have outlined a three-stage process in library automation:

1. print access to print information sources,
2. automated access to print information sources, and
3. automated access to automated or electronic information sources.

Because these stages are not always linear, a library could simultaneously be in more than one stage. For example, a library using a print serials holding list because serials are not included in its OPAC (not an uncommon situation in the 1980s) would be classified in stage two for monographs and stage one for serials. At the time of this writing, a majority of librarians (but not all) are at stage two, and libraries providing access to electronic journals are also in stage three.