ILL I NI S UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN PRODUCTION NOTE University of Illinois at Urbana-Champaign Library Large-scale Digitization Project, 2007. DECISION-MAKING FOR AUTOMATION: HEBREW AND ARABIC SCRIPT MATERIALS IN THE AUTOMATED LIBRARY By Elizabeth Vernon CONTENTS Abstract 1 Hebrew and Arabic Scripts 1 Automation Options 2 Romanized Cataloging 2 Assessment of Romanization 2 Implementation of Romanization 8 ALA/LC and ISO Romanization 8 ANSI Reversible Romanization for Hebrew 14 Academy of the Hebrew Language Romanization 17 Nonroman Script Cataloging 18 Assessment of Nonroman Script Cataloging 18 Nonroman Script Implementations 21 CDS/ISIS and MINISIS 22 DOBIS-LIBIS 26 ALEPH 29 VTLS 32 Ameritech Horizon 34 Other Nonroman Script Implementations 34 Combination (Romanized/Nonroman Script) Cataloging 38 Assessment of Combination Cataloging 38 Implementation of Combination Romanized/Nonroman Script Cataloging 44 ALEPH 55 VTLS 58 DRA 58 MINISIS and CDS/ISIS 59 Authority Control of Hebrew and Arabic Materials 60 Name Authority Control in the Romanized Cataloging Environment 61 Name Authority Control in the Nonroman Script Cataloging Environment 61 Name Authority Control in the Combination Romanized/Nonroman Script Cataloging Environment 62 Subject Authority Control 67 The Unicode Standard and the Future of Multiscript Library Automation 68 Conclusion 70 Acknowledgments 75 Appendixes 78 References 84 Acronyms 90 Vita 91 DECISION-MAKING FOR AUTOMATION: HEBREW AND ARABIC SCRIPT MATERIALS IN THE AUTOMATED LIBRARY ABSTRACT It is generally accepted in the library world that an automated catalog means more accessible data for patrons, greater productivity for librar- ians, and (via the services of bibliographic utilities) an improvement in the sharing of bibliographic data among libraries. While the desirabil- ity of automation is not a controversial issue, how to implement automa- tion remains a problem: what hardware and software to use, what stan- dards to follow, and so forth. Each institution must assess its priorities, determine the needs of its user population(s), and decide which are the most important needs to meet. The institution must also determine if sharing cataloging data with other institutions is a priority and, if so, with which ones? The institution must simultaneously assess its available resources: how much of an investment can it afford to put into hard- ware, software, ongoing maintenance and licensing costs, and staff time (both for system setup and maintenance and for actual cataloging and processing of library materials)? The final decision will reflect the inter- play between the desired results and costs. This article surveys the auto- mation options available to libraries with Hebrew and Arabic script col- lections and examines the automation decisions that different libraries worldwide have made, with consideration of how these choices relate to the priorities of these institutions. The focus will be on academic and research libraries, with reference to other libraries when appropriate. HEBREW AND ARABIC SCRIPTS Hebrew and Arabic scripts bear important similarities. They are both written from right to left. Their short vowels are not represented by separate letters-i.e., these vowels are either omitted altogether or are represented by diacritics above or below the consonantal characters. Some long vowels, particularly in the case of the Hebrew language, may also be represented by diacritics. In addition, the Arabic script is 2 Elizabeth Vernon contextual (letters change form depending on their position within a word; a letter may have up to four forms-initial, medial, final, and in- dependent-not to mention ligatures), and all letters may connect on at least one side with another letter. Hebrew letters, on the other hand, stand individually, except for the special aleph-lamed character used in Judeo-Arabic, and only five Hebrew letters change form-i.e., having regular and final forms. These characteristics have significant bearing on the automation options available to libraries for materials in the He- brew and Arabic scripts. The main Hebrew script languages are: Hebrew and Yiddish, along with Ladino,Judeo-Arabic,Judeo-Persian, and Aramaic. The main Arabic script languages are: Arabic, Persian, Urdu, Pushtu, Sindhi, and other Arabic script Indian languages, along with Ottoman Turkish and several Central Asian Turkic languages, Kurdish, pre-romanized Swahili, Hausa, Malayo-Indone- sian, and other Arabic script African and South-Asian languages. In this paper, the terms Hebrew and Arabic will refer respectively to Hebrew- and Arabic-script languages in general; Hebrew language and Arabic language will be the terms used to refer specifically to those languages. AUTOMATION OPTIONS While a variety of hardware and software configurations can be used to automate Hebrew and Arabic script materials, the cataloging options available to the library can be grouped into three categories: (1) roman- ization (romanized cataloging), (2) nonroman script (nonroman script cataloging), and (3) a combination of romanization with nonroman script (combination cataloging). (In the context of the literature about library automation of nonroman script languages, provision of data in nonroman scripts is often referred to as "vernacular" cataloging.) Both technical and policy considerations may affect the choice of one or another of these options. ROMANIZED CATALOGING Romanization refers to the rendering of text in nonroman scripts into roman (Latin) characters. Although romanization is sometimes referred to as transliteration, this term is not completely accurate for the Hebrew and Arabic script languages because the rendering usually involves the supplying of vowels rather than the simple letter-by-letter substitution that the term transliterationimplies. Assessment of Romanization Regarding the technical aspects of automation, romanization is clearly the simplest automation solution for the Hebrew and Arabic script lan- DECISION-MAKING FOR AUTOMATION guages. The only special requirement of the local system is that it sup- port the necessary character set-specifically the diacritics-at the very least for screen display and preferably for printing as well. In the case of ALA/LC romanization, it is necessary that the automation environment support the ALA extended character set (developed by the Library of Congress in the course of the development of the USMARC format and approved by the American Library Association [ALA]), or any other char- acter set with the necessary diacritics. The ALA extended character set is composed of ASCII (ANSI X3.4) and ANSEL (ANSI Z39.47-a set of diacritics and special characters) (Barry, 1991). Similarly, ISO-based romanization requires support of the ISO extended Latin character set (ISO 5426) in addition to the basic Latin character set (ISO 646). This requirement may limit terminal choices if the library is using terminals instead of microcomputers as input/output devices, as well as printer choices, although this is becoming less of an issue with fixed character- set printers gradually disappearing from the scene. Romanization should not, however, represent an obstacle regarding the choice of library auto- mation software itself, particularly if the software package is one geared toward the academic/research library market. As Wien (1994) points out, even diacritic support is not an absolute requirement for the input of romanized data since diacritics may be represented by escape codes, although this is less convenient for the cataloger. In the early days of library automation, romanization was the only pos- sible automation option for the cataloging of Hebrew and Arabic script materials. Initially, computers could only support the roman script, and even when Hebrew and Arabic characters began to be available in soft- ware applications, it took some time for library applications to be writ- ten to accommodate them. Charles Berlin, head of the Judaica Division of the Harvard College Library-the first major Hebraica research li- brary collection in the world to be fully automated-points out that, in undertaking the automation of Harvard's Hebraica collection in 1982, "the decision was not romanization per se [rather] the goal was automa- tion and romanization was the only means then available to achieve that goal" (C. Berlin, personal communication, 1995). Until nonroman script capability was developed in library automation software, the only alternative to automation with romanization was to postpone automation-i.e., to retain the card catalog. For large research libraries in the West undergoing automation, retention of the card cata- logs for Hebrew and Arabic collections meant isolating those materials from the larger library collections and therefore from users. This can be demonstrated by the experience of the Ohio State University Librar- ies (OSUL). During the initial stages of OSUL automation in the early Elizabeth Vernon 1980s, librarian and faculty objections to romanization persuaded the li- brary administration to retain card catalogs for its Arabic, Chinese, and Hebrew materials. Librarians soon found this to be an untenable situation, leading to the decision in 1984 to do romanized cataloging for Hebrew and Yiddish via OCLC, at least until an alternative presented itself. There were several reasons for our dissatisfaction. First, library patrons started using LCS [the online catalog] with increasing frequency....Whereas in the card catalog they found both Hebrew and