8-26-97 DRAFT #6 (Final Subcommittee draft) Automation Requirements for Music Materials The Music Library Association's Subcommittee on Automation is charged "to identify requirements for automated library systems that are of unique concern to music materials, and those that, while not unique, are of special importance for music materials in all facets of library automation." We have attempted here to define these needs so that music librarians will be able to discuss them with their colleagues, administrators, automation consultants, and system vendors. We have avoided expressing the specifications in the style of any particular system. The Subcommittee believes that unique system specifications can be better addressed through the system user groups. Also, in past reports of this subcommittee, it was necessary to reiterate common (or "overlapped") requirements when describing each subsystem. Today, most system modules are well integrated. The Subcommittee chose to focus on the requirements for specific system components with the understanding that searching, screen displays, etc., are considerations common to all modules. It is fundamental that the system will accept input and allow output in all USMARC formats. Storage of the records in the MARC format is not necessary as long as the database accommodates all the data elements present in the most recent update to the applicable "USMARC Format" documents. When we refer to numeric tags in describing the contents of data fields, we also mean the equivalent fields in non-MARC data records in systems that store data in formats other than MARC. The Subcommittee considers certain features necessary for patrons using music materials. In the specifications that follow, "will" is used to indicate system requirements that are mandatory for the searching and handling of music materials in libraries. The term "should" describes features that considerably enhance the effectiveness of the system for handling music information. I. INDEXING/SEARCHING REQUIREMENTS A. General 1. All search options applicable to public use will be available from all in-house terminals; other modes of searching should be available from all staff terminals. 2. It should be possible to search using either menus or commands, both separately and in combination. 3. The system will to the greatest extent possible ignore or forgive errors in spacing, punctuation, and diacritics. 4. A search history will be available to the user; this history will display the number of hits for each search step and will be viewable without losing the current search. 5. Online, context-sensitive help will be available at any time without losing the search in progress. B. Searching 1. The end result of any search will be the same regardless of the order of steps (e.g., whether one searches author-then-title, or title-then-author, the end result will be the same). 2. Search options will remain substantially the same (as far as this is consistent with logic) regardless of the order of steps. 3. It will be possible to obtain appropriate bibliographic records through any type of initial search, without rekeying (e.g., to search on a name-title cross-reference would cause the necessary chain rection leading to records using the proper uniform title). 4. Searches in which multiple indexes can be combined on the same search line (or the equivalent in GUI systems) will be allowed. 5. Full Boolean searching will be available; this includes searching by any combination of access points, or by more than one term from a single access point. 6. In searches drawing upon more than one index, it will be possible to specify the index to be searched for a particular data element. 7. It will be possible to interrupt a long search (a search in which the results are taking a long time to be retrieved and displayed), with patron options to revise, see partial results, continue, abandon the search, etc. 8. It should be possible to specify adjacency as well as single words. 9. It will be possible to limit a search, either at the beginning or at any time during the search, by any currently valid format or other data coded in the MARC record in the fixed fields, 006, 007, or 008, or given in the 245 $h. It should be possible to limit by other criteria specified by the local library, such as location, date, or publisher. 10. Coded data that can be incorporated into a search will be available to patrons in an expanded, readily intelligible form. This form may be built into the system or may be specified by the individual library. 11. It will be possible to include in search strings any symbol currently included in the American Standard Code for Information Interchange (ASCII) character set or a system-defined synonym for any such symbol. For example, the musical symbols for sharp and flat will be fully searchable. C. Access Points The access points specified in this section are not the only desirable access points but those particularly relevant to music materials. 1. Combined author/title searching will be possible for 1xx/240, 1xx/240 $p, 1xx/245, 1xx/245 $p, 7xx $a/$t, 7xx $a/$p, 8xx $a/$t, and 8xx $a/$p fields. (It should be understood throughout this document that by $t and $p, we mean $t and $p and all following subfields that contain title information). 2. Headings and cross-references from name/title authority records, transcribed titles, and uniform titles (including their associated names, if any) will be searchable together by the public (i.e., it will be possible to search a title without knowing what sort of title it is). It should be possible, however, to restrict a search to one type of title only. 3. Name of title part ($p) will be retrievable as title data, both separately and in combination with other access points. 4. It should be possible to search single-character strings in 240, 245, 505, 7xx or 8xx. In particular, number (usually $n) and key (usually $r) should be fully searchable in these fields. D. Stop lists and synonym lists 1. The system should allow any stop list to be locally defined. It will be possible to override this list during a search. 2. The system should allow the creation of a locally defined synonym list, so that a search entered in one way (e.g., with a common misspelling) will be performed as if it had been entered as defined in the list (e.g., correctly spelled). If such a synonym list exists, it will be possible to override it during a search. E. Index Attributes 1. Indexes will include, at a minimum, a. Names (1xx, 600, 610, 7xx, 8xx [in all cases, all subfields except $t and following subfields]). b. Titles (all applicable fields and subfields, including but not limited to 130, 240, 440, 630, 730, 740, and 830; 245 $a, $n, $p, $b; 246 $a, 1xx $t, 4xx $t, 6xx $t, 7xx $t, 8xx $t) In all cases, $t means $t and all following subfields that contain title information). c. Name/title (all applicable fields and subfields, including but not limited to 1xx/240, 1xx/245, 7xx $a/7xx $t, 8xx $a/8xx $t). Title parts ($p) will be retrievable as title data. d. Subjects (6xx). e. Keyword (in both bibliographic and authority records; as applicable, author, title, contents notes [505 in bibliographic records], subject). It should be possible at the library's discretion to include other fields in this index; keywording of other notes, series statements (including series numbering), and of the publisher (260 $b) are particularly desirable. f. Music numbers (028 and 024 fields) and all other 02x fields. 2. It will be possible to include a field or subfield in more than one index. 3. All subfields that contain spelled-out information, rather than codes, will be part of the indexed entry, with the exception of $h (medium qualifier). Unindexed subfields, however, will be available for display at the library's option. 4. Uniform titles attached to name headings will be indexed in such a way that the dependent title is always retrieved with the appropriate name heading. II. BIBLIOGRAPHIC DISPLAY A. General 1. The display of search results will include the search string entered by the user. 2. The display will include fields 1xx, 240, and 245 when present in the bibliographic data. Truncation of the 245 display may occur when necessary. B. Individual Record Displays. 1. Institutions will be able to select and configure the display of information on brief and full records; further, institutions will be able to customize the display of full records, including the use of labels to identify the various parts of the bibliographic record. 2. Brief Individual Record Displays. a. The individual record display of a brief record will include (in addition to appropriate data from fields 1xx, 24x, etc.) the following data: (1). For printed music, sufficient bibliographic information to distinguish scores clearly from parts, and miniature scores from full scores. Such information may be displayed from the 300 field $a and $c. (2). For sound recordings and media, the Specific Material Designation (300 or 305 $a, or as derived from MARC 006, 007, and 008 fields). (3). For sound recordings and videorecordings, $a of 028 field. b. In non-MARC displays, adequate visual discrimination between the uniform title and the transcribed title, such as placement of the uniform title in square brackets or in a separately labeled area, should be provided. 3. Full Individual Record Displays. a. The system will be capable of displaying any fields in the MARC record that contain bibliographic data (as opposed to codes). b. The system will be capable of displaying fields in AACR2 order, rather than only ascending MARC tag order. c. The system will be capable of displaying records in MARC format as well as in a labeled or other non-MARC format. C. Multiple Matches 1. When all citations on a screen have certain bibliographic characteristics and data in common, such information may be displayed once, if this treatment can be readily understood by the user. 2. Uniform titles from $t or from field 240 will be displayed with the associated name from the parent field ($a or 1xx); and names appearing in name/title combinations will not be displayed without their dependent $t uniform titles. 3. The General Material Designation (GMD) or bibliographic record type will be displayed in intelligible form along with each citation so that various formats of material can readily be distinguished. 4. Entries retrieved from name searches should display in intelligible form any $4 information associated with the name in each record. 5. Users should have the option of requesting that the results of any type of search be limited to and/or sorted by the format of the material. D. Sorting of Displays of Bibliographic Citations. 1. Display of multiple citations under any single name heading will sort alphabetically by uniform title (240, 7xx $t, 8xx $t) if present, in one alphabetical sequence. 2. Titles and other fields containing opus numbers, thematic index numbers, or other sequential numeric designators should file in correct numeric sequence as integers (not according to ASCII filing conventions, which create a decimal arrangement). Numeric designators should sort first by number, then by alphabetic prefix or suffix, whether or not the letters and numbers are separated by a space. 3. The system will provide clear guide screens to facilitate moving around within the alphabetical sequence. 4. The system will not limit the number of items retrieved by any search. III. CATALOGING AND AUTHORITY CONTROL A. The system will feature different levels of authorization for modifying bibliographic and authority data in order to protect the integrity of the catalog. B. The system will allow consultation of online versions of cataloging rules, code lists, lists of locations, and other reference tools in a windows or windows-like environment, so that exiting from the current editing process is not necessary. C. The system will be capable of associating name/uniform title authority records with appropriate bibliographic records, whether the name/uniform title is represented in the bibliographic record as a combination of 1xx and 240 fields (or 1xx/245 $a when there is no 240), or as a single 6xx with $t, 7xx with $t, or 8xx with $t. Bibliographic records to be associated with a name/title authority record should include both those with fields matching the name and title exactly and those that designate other manifestations, parts, versions, arrangements, etc., of the work specified by the authority record. D. The system will support automatic replacement of incoming headings in bibliographic records which are cross references in authority records with their corresponding valid heading. The system will fully support global change capabilities. Library staff should have the option of receiving notification, either online or via printed report, of potential changes, so that staff may verify changes before they are made. However, in no instance will the system change 245 $a to match an authority record; rather the system will add, or prompt library staff to add, field 240 or 130, as appropriate. E. The system will likewise support replacement of an authority record with an updated version of itself, in which the previously valid heading has become a "See" cross reference (field 4xx) and a new valid heading has been added. The appropriate fields or subfields of all associated bibliographic records will be automatically revised, or tagged for possible revision, to reflect the new heading. Library staff should have the option of receiving notification, either online or via printed report, of potential changes, so that staff may verify changes before they are made. It should also be possible to specify that no such notification is desired, in which the fields and subfields in question will be revised automatically. F. For bibliographic records which lack a 240 field (in cases where it was not supplied because it would be identical to the 245 $a), the system should match 1xx/245 $a combinations with existing name/title authority records and associate the matching bibliographic record(s) with the authority record. IV. ACQUISITIONS A. The system should be able to handle complex enumeration and chronology schemes for check in of sets as well as series, and to display the data in appropriate hierarchical order in the holdings statement. B. In addition to other basic bibliographic elements (1xx, 245, 260), the system will allow entry and printing of the following fields on orders: 02x; 240 (uniform title); 300 (physical description). V. CIRCULATION A. Upon scanning the barcode, the system should display the item's author, title, and call number, and number of pieces comprising the item. B. The system should prompt a check for number of pieces attached to the title before accepting the charge-out, and before discharging and eliminating patron information, allowing for backout if the number of pieces does not match. VI. RESERVE A. The system will allow for a separate database or separate indexes for reserve materials, to prevent conflicts with authorized headings. B. The system will allow for flexibility in assigning due dates, local notes fields, searchable local fields (for example, by professor, course, or department), etc. C. The system will allow for importing scanned documents. It should be possible to limit access to these documents according to user type. D. If separate from the online catalog, the Reserve system will index 1xx, 240, 245, and 7xx fields. E. If separate from the online catalog, the Reserve system should support the ASCII character set. VII. INTER-SYSTEM COMMUNICATION AND INTERNET CAPABILITY 1. The system will provide for accessing data from OPACs and other vendor databases through support of the NISO Z39.50-1995 information retrieval standard, the TCP/IP protocols, and the HTML standard to facilitate access to the system from clients with Web browsers. 2. To facilitate access to data, the system will permit input of all indicators and subfields of MARC field 856. 3. The system will allow display of all or portions of MARC field 856 according to the needs of the library. 4. The system will allow automated access to an electronic item using the Internet protocol specified in the 856 first indicator and 856 $u. 5. The system will allow for access to sound and graphics files through helper applications used with Web browsers. 6. The system will allow the library to design displays for data retrieved via Z39.50 as desired, to include any retrieved field or subfield in the display, to control the order of the fields in the display, and the wording of labels for fields.