As usual, MARBI meetings were held at the American Library Association's 1997 midwinter and annual meetings, totaling three, three-hour sessions per conference. Comprised of nine voting members and three interns representing RUSA, LITA. and ALCTS (all divisions within ALA), as well as national library representatives from LC, NLM, NAL, and the National Libraries of Canada and Australia, the US MARC Advisory Group membership also includes liaisons to CC:DA and SAC and representatives from OCLC, RLG, ISM and WLN bibliographic utilities. Finally, there are the rest of us--liaisons from associations, including the ALCTS Audiovisual Committee, the Art Libraries Society of North America, Music Libraries Association, AVIAC, Map & Geography Round Table, MicroLIF, PLA/lCIS for US MARC Community Formats, and Visual Resources Association, and, of course, the American Association of Law Libraries.

Generally the meetings follow a fixed agenda, including a brief business meeting with announcements, and presentations of prepared discussion papers on exploratory topics, which often develop into specific proposals designed to expand, change, or modify the MARC formats. These discussion papers and proposals are prepared either by MARBI members or by outside groups seeking changes in the formats. If a discussion paper identifies a clear issue for which there seems to be a viable solution within the USMARC formats, the presenter is encouraged to return to the Committee with a specific proposal. If the proposal (which may be changed or amended several times by the Committee in a process that can take years to complete), is approved by the voting majority, then LC independently reviews the proposal. While LC generally approves of the proposal, in many cases the proposal is not implemented until the next USMARC update is released. Often implementation is delayed even further, either by LC or the bibliographic utilities, due to the complexity and the cost of implementation.

» Joint CC:DA/MARBI Discussion: On Monday June 30th, 1997, CC:DA reserved an hour in its agenda to meet with the MARBI group to discuss two major topics: 1) how the Dublin Core relates to the traditional AACR2 formulated catalog record; and 2) what are the public display and service issues of using the Dublin Core. For background on the Dublin Core, see "Dublin Core/MARC/GILS Crosswalk," prepared by the Network Development and MARC Standards Office at http://lcweb.loc.gov/marc/dccross.html.

Basically the crosswalk may be used to convert metadata from some other syntax into MARC. One of the issues raised at this joint meeting focused on how (or whether) to integrate Dublin core data mapped to MARC format into existing catalogs or databases. For instance, what MARC fields should be assigned to headings that are not under our traditional authority control? At the end of the hour volunteers were sought for a joint CC:DA/MARBI task force to explore these questions in more depth.

» Discussion Papers: Discussion Paper No. 100 posed one of the more interesting topics -- how to code other national libraries' authority records into a unified authority file. Coding decisions are needed to indicate the language, script, transliteration, country of origin of the heading as well as the cataloging rules that were applied. The MARBI Committee discussed this at some length, mainly identifying more questions that would have to be addressed in such a complex file. No decisions were made, and discussion will continue at the 1998 midwinter meeting.

Discussion Paper No. 101, prepared by Harvard University, summarized the notes fields in the USMARC Holdings Format and suggested including copy specific information note fields that are currently available only in the Bibliographic Format. The ensuing discussion revolved around the fact that because so few libraries are now using the USMARC Holdings Format, they would be unable to make use of copy specific fields if only available in the Holdings Format. Therefore, the consensus seemed to be that those fields are still needed in the Bibliographic Format. The discussion will be continued at the next meeting in 1998.

Discussion Paper No. 102 generated more discussion than one might have anticipated, given that the subject was non-filing characters associated with variable fields in the USMARC records. The problem is that while some fields already have indicator positions at the beginning of cataloging data in access fields, not all of the variable fields do, nor do they have any filing indicators available. Therefore, the solution for handling these indicators could include omitting initial articles, use of graphic characters as delimiters, use of special control characters, system recognition of articles, or creating a subfield for articles. Naturally each of these ideas has fatal flaws and possible large costs. Discussion will continue at 1998 Midwinter.

Discussion Paper No.103 was the only one that moved along to where a proposal will be developed to present at the next meeting. This was a relatively minor discussion initiated by the Music Library Association and the Online Audiovisual Catalogers re the use of fields 028 and 037 for publisher number and source of acquisitions, and a request for attaining consistent placement and indexing of those fields.

» Proposals: Proposal No. 97-10 (referenced to related proposals 96-10 and discussion paper 73) contained a first option that was approved. This option recommended that USMARC ASCII clones in the Arabic, Cyrillic, and Hebrew sets be mapped to the unified repertoire in the universal coded character set (ISO 10646). This will make it easier for vendors' "off-the-shelf" products used by USMARC users and systems outside the USMARC community to interpret USMARC data. The approved proposal Option I will undergo a technical review by an ad hoc committee comprised of MARBI and AVIAC members.

Proposal No. 97-14, quickly approved at the annual meeting without discussion, proposed adding new characters in Arabic script.

Proposals No. 97-12 and 97-13 were made on behalf of CENDI (Commerce, Energy, NASA, Defense, and Interior Departments Cataloging Committee). 97-12 proposed differentiated agency and project numbers in the 536 field by defining new subfields for each segment of their agency divisions. Proposal 97-13 sought to add subfields $g and $h to field 355 that would distinguish between types of classification and dates enacted, e.g., "Downgrading date" or "declassification date." Both proposals were approved.

Proposal No. 97-3R had the longest history of any considered at the 1997 ALA Meeting. As approved at the June meeting, it more narrowly redefines leader/06 code m (Computer file) to specific kinds of electronic resources, such as computer software (including games, programs, fonts) etc. The implications of this change are significant. Now catalogers do not have to code everything electronic (e.g., electronic serials, CD-ROM titles) as a computer file. Electronic serials can now be coded as serials. In association with that change in leader 06, leader 07 will now be mandatory for electronic resources. This change was sought by CONSER and many others in the cataloging community.

Proposal No. 97-8 also dealt with electronic resources, proposing a redefinition of subfield $q (file transfer mode) to Electronic Format Type in field 856. Originally created in 1993, field 856 provided a "hot link" to allow for the transfer of a file, a connection to another host, or the initiation of an e-mail message through information recorded in the field. Now the issue of where to record the file format information has become increasingly important with the explosion of the Web. Catalogers have been confused about where to record that information, because other fields, such as 516 and 538, could also be used. The proposal passed with the correction that subfield $q not be repeatable.

Proposal No. 97-9 also dealt with the 856 field, proposing a variety of approaches when recording a URN. The original proposal suggested using subfield $u (Uniform Resource Locator), and changing the name to Uniform Resource Identifier (an umbrella term used to describe various UR standards), which would accommodate both URLs and URNs. That proposal failed on the grounds that the subfield $u had already been used strictly for URLs, which act somewhat differently from the proxy URNs, and other "bare handles." Instead, LC will look at the tables to determine if another subfield code is available for URNs. The second part of the proposal, which called for defining the first indicator in the 856 field as a #, meaning no information provided, was approved.