MARBI Members:
Josephine Crawford ALCTS University of Wisconsin Elaine Henjum LITA Florida Ctr for Lib Auto Diane Hillmann LITA Cornell University Carol Penka RUSA University of Illinois Jacqueline Riley, chair RUSA University of Cincinnati Frank Sadowski ALCTS University of Rochester Paul Weiss ALCTS University of New Mexico Robin Wendler LITA Harvard University MARBI INTERNS: Annamarie Erickson RUSA Chicago Library System Anne Flint ALCTS OhioLink REPRESENTATIVES AND LIAISONS: Joe Altimus RLG Research Libraries Group John Attig OAV Pennsylvania State University Sherman Clarke VRA New York Universities Libraries Betsy Cowart WLN Washington Library Network Donna Cranmer ALCTS AV Siouxland Libraries Bonnie Dede SAC University of Michigan Stuart Ede BL The British Library John Espley AVIAC VTLS Catherine Gerhart CCDA University of Washington David Goldberg NAL National Agricultural Library Rich Greene OCLC OCLC, Inc. Rebecca Guenther LC Library of Congress Michael Johnson MicroLIF Follett Software Company Maureen Killeen ISM ISM Library Information Services Rhonda Lawrence AALL UCLA Libraries Karen Little MLA University of Louisville Sally McCallum LC Library of Congress Susan Moore MAGERT University of Northern Iowa Marti Scheel NLM National Library of Medicine Ingrid Parent NLC National Library of Canada Louise Sevold PLA/CIS Cuyahoga County Public Library Patricia Siska ARLIS Frick Art Reference Library Margaret Stewart NLC National Library of Canada Rutherford Witthus SAA University of Connecticut OTHER ATTENDEES: Jim Agenbroad Library of Congress Bill Anderson Library of Congress Karen Anspach EOS International, Inc. Leiane Baden NELNET Julianne Beall Library of Congress Kathy Carter University of Alberta Pat Case FDIC Library Lois Chan University of Kentucky Gretchen Cheung Best-Seller, Inc. Thomas Champagne University of Michigan Karen Coyle University of California Willy Cromwell-Kesler Research Libraries Group Carol Davis Columbia University Bob Dowd Florida ? Wendy Duff Canadian Committee on Archival Description Ann Fiegen University of Arizona Patti Fields Federal Lib & Info Ctr Committee; LC Michael Fox Minnesota Historical Society Aimee Glassel University of Wisconsin Robert C Hall, Jr. Concord Free Public Library Beveryly Harris Cobb County Public Library System Steve Hensen Duke University Jean Hirons Library of Congress Wayne Jones MIT Libraries William W. Jones New York University Kris Kiesling University of Texas at Austin Gertrude Koh Rosary College GSLIS Bill Landis University of Michigan John Levy Library of Congress Clifford Lynch University of California Katha D. Massey University of Georgia Bob Maxwell Brigham Young University Hope Mayo Electronic Access to Medieval Manuscripts David Miller Curry College Joan Mitchell OCLC Forest Press Anne Moore Northeastern University Elizabeth O'Keefe Pierpont Morgan Library Cecilia Preston Preston & Lynch Becky Ringler University of California, San Diego Karen Schneider US EPA / Region 2 Library Jacque-Lynne Schulman National Library of Medicine Jackie Shieh University of Virginia Magela El-Sherbin Ohio State University Libraries Gary Smith OCLC, Inc. Steven J. Squires University of North Carolina Victoria Stettner Northwestern University Barbara Story Library of Congress Mary Strouse Unaffiliated Jennifer Sweda University of Pennsylvania Vitus Tang Stanford University Library Cecilia Tittemore Dartmouth College Mitch Turitz San Francisco State University David C. Van Hoy MIT Libraries Susanne Warren AAT/Getty Vocabulary Program Valerie Weinberg Library of Congress Nancy Williamson University of Toronto Matthew W. Wise New York University Amanda Xu MIT Libraries Abraham J. Yu University of California, Irvine ***************** Saturday, February 15, 1997 ****************** Jacquelene Riley, 96/97 chairperson of MARBI, opened the first of three conference meetings at 9:30am. There was a quick round of introductions of Committee members, liaisons, and visitors, and then the Committee moved on to the first proposal. PROPOSAL 96-8 R : "CAN/MARC Changes for MARC Format Alignment" Sally McCallum introduced Proposal 96-8R by describing a little of its history. In 1996, about half of the items comprising 96-8 were passed, and most of the other items were discussed in some depth. The archival-related items were not completely worked out in 96-8 but have now been added in to 96-8R. For this meeting, 96-8 has been revised. Where there was extensive discussion and general agreement on an option but no final vote, only that option has been left in the revision so that the Midwinter discussion will not recover old ground. Similar to the 1996 practice, it was agreed to discuss and vote for each item separately. 96-8R LDR-17: Add an "abbreviated level" code to the Encoding Level data element. An alternative to LDR-17 is to add an authentication code to field 042. Given that abbrievated level records are less complete than minimal level records, adding value 3 to LDR-17 would allow libraries to predict which records could use upgrading. Unfortunately, adding a new encoding level has a very significant impact on systems since many programs revolve around the Encoding Level data element. Yet, value 3 has been in use by Canadian libraries for some time, and not approving it would mean retrospective conversion costs to change to the 042 field. Paul Weiss expressed concern that Canadian libraries now use authorized heading fields for these records, even though the headings are not checked. Why not use non-authorized fields, he asked. Margaret Stewart, representing the National Library of Canada, responded by saying that the records reflect established forms to the extent that such forms were available at the time each record is created. Another person pointed out that LC follows the same practice in creating minimal level records. It was noted that the format does not have authorized and non- authorized heading fields, although the new 720 is approximately that. Betsy Cowart asked Margaret if the materials are examined physically, because, if not, perhaps value 2 could be used instead. Margaret reported that the materials are examined physically, and therefore value 2 is not appropriate. Why aren't these materials just given minimal level cataloging? Margaret explained that the materials fall outside specific collection areas, and therefore less effort is preferred. Rich Greene stated that OCLC prefers the 042 option because system implementation is so much easier. Yet, OCLC can see that adding value 3 to the LDR has wide appeal in the bibliographic community and may be a better course in the longterm. He questioned the current definition, thinking that it could be broadened for more generic use by libraries. It was suggested to insert "may" in the 2nd sentence, as follows: "Code 3 indicates a brief record that does not meet the National Level Bibliographic minimal level cataloging specifications. Headings in the records may reflect established forms to the extent that such forms were available at the time the records were created." Paul Weiss moved that MARBI approve value 3 in LDR-17, with the insertion of the word "may" in the definition. Elaine Henjum seconded his motion. There were 7 votes in favor, one vote against, and one abstention. 96-8R 008/39 : "Change and add Cataloging Source values" NLC requests the addition of two new values for alignment purposes (a value for NLC records and a value for the Canadian Union Catalogue), and a redefinition of value c to serve more generally for cooperative cataloging programs. Sally McCallum reviewed the four options that were presented in the proposal. Paul Weiss asked whether and how this data element is used in cataloging. Robin Wendler reported that Harvard uses the data element in machine processing for dividing up cataloging (a historical practice). Harvard would be happy with Option 3. Rich Greene reported that OCLC uses the data element a lot, both the 040 field and the 008/39. Any change will require lots of investigation and some programming. In the interest of harmonization, and because the current set-up doesn't work particularly well, OCLC recognizes that something should be done. Options 1 and 2 are viewed as providing short-term value only. Options 3 and 4 are probably about the same amount of work. Margaret reported that NLC does not now process on this byte. NLC prefers Option 1 or 2, but is willing to accept Option 3 or 4. In addition, Diane Hillmann spoke up in favor of Options 3 or 4, because Options 1 and 2 would not be helpful in collaborative cataloging programs like Bibco. Sally reported that LC prefers Option 3, seeing a need to distinguish between cataloging by a national library, cooperative cataloging programs, and other sources. Marti Scheel reported that NLM prefers Option 4, if it is not possible to maintain current codes. Paul moved to accept Option 4, making the 008/39 obsolete. This was seconded by Frank Sadowsky. There were five votes in favor, one vote against, and two abstentions. Later on in the same session, following the vote on the 5xx/7xx authority fields, MARBI members began to rethink the earlier vote for the 008/39 byte. John Espley realized that VTLS currently codes the byte in authority records, and is then able to display a label to show the source of an authority record. John recommended making the code obsolete in the bib format, but not in the authority format. Paul Weiss agreed with him, under the circumstances. Paul could see that some systems would put authority records coming from different agencies into different indexes. However, Diane Hillmann liked keeping the byte parallel between the two formats. David Goldberg also felt that there would be confusion if the two formats were not the same. It was agreed to rescind the earlier vote for Option 4. Diane Hillmann made a motion in favor of Option 3, and this was seconded by Robin Wendler. Option 3 provides four "general" codes (i.e. national bibliographic agency, cooperative cataloging program, other, and unknown) instead of listing specific libraries. There were seven votes in favor, and one abstention. 96-8R 008/23-27 (Visual Materials): "Reorient Accompanying Material Position" Alignment between USMARC and Can/MARC raises an issue of overlapping bytes and differing historical definitions. If several codes were redefined, backfiles of bibliographic records would need to be converted in both countries if these codes are to be useful in the future. It is therefore recommended that bytes 008/23-27 be made obsolete. John Attig reported that OLAC is in agreement with this recommendation. Paul Weiss moved to accept Option 3. Diane Hillmann seconded his motion. There were eight votes in favor (unanimous). 96-8R 009: "Add data from Can/MARC Field 009 for Cartographic Materials" Can/MARC field 009 provided physical description data beyond the 007 field. Canadian and US map librarians considered the field, noted the redundancy of part of 009 to USMARC, and came to the recommendation that three values should be added to USMARC: Map 007/04 (Physical medium) Map 007/06 (Production/reproduction details) Map 008/25 (Type of cartographic material). In addition, data elements relating to remote sensing images (RSI) are needed and are being considered in a new 007 field in a later proposal. There was some discussion about cataloging maps that arrive in different forms, such as two maps on a single sheet of paper, maps bound in a book, and maps that used to be bound in a book but have been removed. Susan Moore explained that it is best to keep maps flat. Paul questioned the need for byte 25, but map catalogers see this as very important. Susan Moore requested that "mylar" be removed from the revised description of code e in Map 007/04. Because Mylar is a trademark, it is better to define as "transparant polyester film." Elaine Henjum moved to accept the additional codes. Diane Hillmann provided a second. There were seven votes in favor, and one abstention. 96-8R 016: "Add field 016 for NLC Control Number" The National Library of Canada control number is similar to LC's number in field 010. The NLC control number is used as the citation number in Canadiana. The proposal recommends broadening the 016 number so that it could be used by any national bibliographic agency, but to let NLC use the # indicator, to cut down on the amount of retrospective conversion work by Canadian libraries. Joe Altimus asked about the relationship of the 003 field to the 010 field. Sally reported that there is no official relationship in USMARC. The 003 field specifies the USMARC code for the agency whose system number is present in field 001. Paul Weiss suggested that there be two additions to the proposal. Add "Other" to the name of the field, since LC will continue using the 010 field. And, add "invalid numbers" to $z. Frank Sadowski, Sherman Clarke, and Margaret Stewart spoke up in support of Paul's suggestions. Marti reported that NLM is seriously considering using this field; right now, the NLM number ends up in the OCLC 069 field. NLM would want a special code. John Espley expressed a concern that every national library would want a special code. Paul Weiss moved that the proposal be accepted with the two additions introduced earlier (add "other" to definition and "invalid" for $z). Robin Wendler seconded his motion. There were eight votes in favor and no votes against. It was also agreed that LC staff will attempt to show more contrast in the definitions. 96-8R 085 : "Add new field for Document Shelving Number" Canada requests a new field to carry the CODOC shelving number that is assigned to Canadian federal and provincial government documents. One option is to define the 085 field for this purpose. Another option is to use field 084 (Other Call Number) for CODOC numbers with the number system indicated in Subfield $2. Diane Hillmann spoke up in favor of field 084. She made a motion to accept the $2 code "cacodoc". Paul Weiss provided a second. There were eight votes in favor, and no votes against. 96-8R 9XX: "Add fields in the 9XX Range" Can/MARC has 14 valid fields in the 9XX range based upon a government mandate to provide cataloging in two official languages. These fields are used for equivalent names and cross-references. American libraries may use the same 9XX fields in other ways, since this range is for local adaptation. NLC would like an appendix added to the USMARC documentation listing the NLC 9XX fields; NLC would be responsible for updating this appendix. An alternate idea is to establish 9XX lists on the USMARC Web pages, showing 9XX use by utilities, vendor systems, local libraries, etc. John Attig asked if NLC considers these fields to be "extensions" to USMARC. He noted that the issue is presented as one of documentation, yet there are system compatibility issues to solve. He wondered if systems are expected to not support, unless necessary for Canadian customers. He also pointed out that authority control internationally would benefit from establishing a better mechanism. NLC is to be commended for doing a good thing with the only available mechanism at the time. Diane Hillmann and Paul Weiss supported the Web site idea, because they felt an appendix just for NLC is hard to justify. Margaret stated that NLC intends to streamline and cut down the appendix to a small size. Sally McCallum thought that the introduction to the appendix could clearly explain that use of the Canadian 9xx fields was domain-specific. Diane believed that inclusion in USMARC brings a certain authoritative weight with it, that vendors would think that they have to support it to be USMARC compliant. Margaret replied that, after harmonization, the format should be international in scope, and this appendix supports that concept. Robin Wendler believed that all 9xx fields should be treated equally. Rich Greene saw the problem larger than the documentation issue. Since NLC is using 9xx fields for bibliographic control purposes, he suggested converting the 9xx fields to 886 fields (Foreign MARC Information Field) when shipping to US systems. To American systems this is "local" Canadian data, but not to Canadian libraries. Sally brought the discussion back to the documentation focus. John Espley supported her, thinking that this should be treated as a minor issue only and that supporting an international aspect to the format is a good idea. Bonnie Dede said that NLC is in essence asking for a separate print job on colored paper. To her mind, it raises a question of fairness and common sense. Margaret responded that the Canadians just don't consider these fields to be local. Marti Scheel suggested that perhaps a couple of other major implementations of 9xx could be listed in the same Appendix (i.e. OCLC, RLIN, etc.). Could her suggestion be a compromise? Speaking from the perspective of a local systems vendor, Karen Anspach stated that the presence of the Canadian 9xx fields would raise questions of system support. Should these fields be loaded? Should cross references and/or linkages be made? Paul said that this kind of proves Diane's point. John Espley stated that the appendix could clearly state who is responsible for supporting these fields and who is going to maintain them. Frank Sadowski asked for a straw poll in support of Option 2 (NLC publishing the local 9XX fields in customer documentation). Others wanted to do a straw vote on the Web site registration idea. Paul Weiss wondered if this was a policy issue requiring a MARBI vote, or if it ought to be up to the LC staff. Diane Hillmann felt that there should be a vote. It was agreed that the NLC staff would think overnight about the strong opinions expressed in the discussion. 96-8R 008/08 (Authority) : "Define Bilingual Usage Position" Margaret Stewart opened the proposal by explaining that NLC provides cataloging information in Canada's two official languages. Can/MARC contains five codes for showing if headings can be used in an English catalog, a French catalog, or both. NLC creates two authority records when a heading is available in its equivalent or translated form. Canadian local systems accept one authority record or the other, depending upon the language of the local catalog. The 008/08 codes are used for doing this. The proposal has two options. Option 1 adopts the Can/MARC codes in the 008/08 byte and would allow Canadian libraries to continue in the same way as now. Option 2 adds the 008/08 codes and also establishes an 038 Language of Catalog code, so that countries with other languages could process headings appropriately. There are two 038 subfields, one to list languages for which a heading is valid, and the other to list languages where the heading is not valid. Switzerland and some other countries might use the 038 field, according to John Espley. John Attig asked if Canada could convert to using the 038, rather than continue using the 008. Margaret explained that this would be a major change, and that these codes are used so frequently, it is better for them to be in a fixed field at the front of the record. John Attig went on to say that it is not clear if either the 008/08 byte or the 038 field will fit the future. Much work needs to be done in the area of multiple language authority control. For instance, should there be two authority records (current Canadian practice) or is it better to create just one authority record? Given these unknowns, he suggested we support present need now. Frank Sydowski agreed with John Attig. Sally McCallum emphasized that both options allow Canadian libraries to grandfather in current records. Robin Wendler agreed, believing that the 008/08 byte can be defined for the English/French need. Paul Weiss spoke up with concern though -- Option 2 breaks the USMARC principle that there is only one location for each defined type of data. However, dealing efficiently with current Canadian databases is an important concern. Karen Anspach encouraged MARBI to pass Option 2 since EOS International has one customer with four national languages. Paul Weiss made a motion in favor of Option 2. Robin Wendler provided a second. There were eight votes in favor, and no votes against. 96-8R 008/11 (Authority) : "Define new Subject heading system codes" It is proposed to add a code "s" for the Sears List of Subject Headings. Sally McCallum reported that she has been in touch with the Wilson Co. and a code for Sears would be useful. John Espley asked if there had ever been a USMARC code for the Sears list in the Bibliographic format. Rich Greene said there is a USMARC code for Sears as a subject source and OCLC users put that code in a $2. Diane Hillmann made a motion to add the code "s" to 008/11. Paul Weiss made a second. There were eight votes in favor and no votes against. 96-8R 008/055 (Authority) : "Define field for NLC series call number" If a record is for a series, the call # for the series is put into the 050, 060, 070, 082, and 086 fields. Can/MARC uses the 055 field. While many of the NLC class schedules are like the LCC schedules, they are different in the area of Canadian literature and history. Hence, NLC recommends adding the 055 field to USMARC. Paul Weiss asked who assigns this call number. Margaret Stewart reported that it is used throughout Canada, not just by NLC. NLC assigns call numbers, either using the LCC schedules or one of the NLC extensions. Marti Scheel reported that NLM has the same situation, maintaining the LC medical schedule as well as an extension. John Espley asked about other national libraries. Will they each need a series call number field dedicated to their call numbers? Rich Greene shared John's concern that it could get out of hand -- although, the current proposal meets Canada's need, and keeps the bib and authority formats in parallel with one another. Rich suggested that a broader scheme be devised if more national libraries request a dedicated field. Paul Weiss moved to accept the proposal. Elaine Henjum provided a second. There were eight votes in favor, and no votes against. 96-8R 008/5XX, 7XX (Authority) : "Define subfield for Record control number" It is proposed to add a record control number subfield to the Authority Format 5XX and 7XX fields, since Can/MARC has one defined and it is potentially useful when a system creates references for a headings display. NLC was using $3, but USMARC consistently uses this subfield for "Materials specified" in the Bib and other formats. USMARC used to use $v for a record control number in the 7XX fields, but then changed to $u. Canada has agreed to change from the $3 to a numeric subfield in both fields, but doesn't want to use $u. The proposal therefore recommends $0 [zero]. Betsy Cowart asked if $0 has ever been used before. No. Because it is difficult to distinguish $0 [zero] from $O [letter O], she requested that [zero] in brackets be used in the documentation. Paul Weiss moved to approve the proposal, with the added ruling that the $u in the 7xx fields be deleted. Both Robin Wendler and Diane Hillmann provided a second. There were seven votes in favor and one vote against. Someone asked whether or not this change would be applied across the format, or would only apply to the 5xx and 7xx authority fields. Sally responded that it was only approved in this single case. However, the USMARC staff would try to use the $0 [zero] in the future where a record control number is to be added. BUSINESS MEETING: The Character Sets Subcommittee will be holding a meeting on Sunday, from 12noon-2pm, in the VTLS Suite. Sally reported that a new language code list went to the printer in December. There are 29 new codes, aligning USMARC with NISO and ISO. Paul Weiss asked why there is only one code for sign language, even though there are many sign languages. Rebecca reported that she met with the Gallaudet representatives. There is agreement to have a single "group" code; Gallaudet worked out guidelines on how to apply this code. The Web concise version of all 5 formats is now available. Examples have been added. It is OK to download and use. A print version will be available later. In March 1997, the USMARC office plans to issue Bib Update #3, Holdings Update #3 [delayed until Sept.], and Authority Update #2; will include approved changes from the D.C. meeting. A question was asked about 2000-year work on the LC Control Number. Apparently, there were only a few cataloging records for the years 1898 and 1899. Therefore LC plans to begin with a 4-digit year in the LC Control Number in the year 2000. What about name authority records? Same approach. More questions were asked. Sally agreed to put up a summary of the work done to date on the USMARC Web pages. Sally went on to talk about the DTD. It is now available by FTP. Sally is looking for funds to support creating a converter. John Attig spoke up about a coordination problem where there is a coding difference between the bib and authority formats, due to a recently passed proposal. Should MARBI consider this problem generically? Sally reminded the group that nothing should be implemented until six months after a proposal is passed. The print version is the official version. The electronic version is not changed until the print version has come out. Robin Wendler reported on some work on a cooperative testbed by the National Digital Library Federation. There has been some discussion about the need for expressing hierarchical relationships, as users navigate among objects within a collection. USMARC doesn't do very well in relation to hierarchical relationships. She asked MARBI members to think about this. There was some discussion on the USMARC list about non-filing indicators again. Should there be another discussion paper? Perhaps new technologies might be useful? Robin believes worldwide usage is an impetus. Sally reported that the ISO standard for a bibliographic control set uses control characters, but some USMARC users and uses have problems with control characters. She thinks it would be useful to flesh out the issues, and also look at implementation issues. Maureen Killeen reported that the ISM system has 8 indicator positions internally, although most are not used. But ISM would use for non-filing indicators even if not in USMARC. There was an agreement to move forward with a discussion paper. There was also a suggestion to create a discussion paper on holdings type information, for example in the 541 field. Perhaps this information would be better placed in the Holdings Format. It was agreed to do a discussion paper. Catherine Gerhart brought a proposal from CC:DA to hold a joint meeting with MARBI in San Francisco. CC:DA would like to discuss Metadata, content/carrier issues, TEI, etc. Monday morning seemed like a good time, because it would follow the Sunday program on the Dublin Core. Rebecca Guenther, Cliff Lynch, and Stu Weibel will be speaking at this Sunday program. ****************** Sunday, February 16, 1997******************* DISCUSSION PAPER # 99 : "Metadata, Dublin Core, and USMARC: a review of current efforts" Rebecca Guenther introduced DP99 which discusses developing standards for a simple description record for Internet resources. There have been three international workshops to date (Dublin, Ohio in March 1995, Coventry, UK in April 1996, and Dublin, Ohio in September 1996) and LC staff prepared DP86 after the first workshop. DP99 has been provided to keep the Committee abreast with recent developments. The list of Dublin Core data elements has been increased from 13 to 15, and there have been some small changes in the description of the elements. DP99 includes a new mapping from the Dublin Core elements to USMARC. Stu Weibel reported that there had been a very animated exchange after the recent workshop on the listserv. It is not expected that the data elements will change. D-Lib, a magazine of digital library research, has an article in its January issue describing the Dublin 1996 Workshop on Image Metadata. An Internet Request for Comments (RFC) has just been completed, to communicate work to date to the Internet community. The RFC describes the 15 data elements comprising the Dublin Core, and shows a convention on how to embed in an HTML file. Stu feels that this is really important, so that people get started now and we can learn from the experience. A fourth Workshop is planned for Canberra, Australia in March 1997 to work on implementation issues like what to do with the Dublin Core and how to add subject headings. A second RFC will be completed afterwards. There was some discussion about the purpose of metadata packages and containers. In the Warwick Framework, a package is an object with a specific type of metadata. The metadata may be embedded with the object described or may exist separately and have a link. There may be a MARC container in the future, as well as many others. Stu went on to discuss the Platform for Internet Content Selection (PICS) which is a content-rating infrastructure where labels can be associated with content. It is believed that Microsoft and Netscape and other companies building Internet browsers will include the mechanisms to support metadata and metadata conceptual containers within PICS. In terms of the mapping, Rebecca looked for one place to put each Dublin Core data element in USMARC. This was hard to do since the content of each Dublin Core element is not well known at this time. For example, number 11 is SOURCE, defined as "The work, either print or electronic, from which this resource is derived, if applicable." Rebecca expects preliminary usage and ongoing discussion to finetune the definition. If there are questions or comments about the discussion paper or the mapping , please send them to Rebecca. PROPOSAL 96-8/520 : "New Indicator Value for Field 520 (Summary, Etc. Note)" Sally McCallum briefly introduced the proposal, which will allow archivists to label a special type of summary that appears in cataloging records. The proposal specifies adding an indicator 2 for "Scope and content" and modifying the name of the field and subfields slightly to account for the practice of archivists. RLG recently asked for an indicator 3 for abstracts to be added to the proposal. Paul Weiss questioned dropping the word note from the field and subfield names since 5xx fields are note fields. He asked why the archivists want to do this, and what the consequences would be. Robin Wendler wondered about the functional difference, and if one should then assume that all 5xx fields should have the "note" label dropped. Wendy Duff (Canadian Committee on Archival Description) explained that the word note has a different meaning to archivists and that the use of it in the field/subfield names causes confusion. John Attig pointed out that AACR2 has a definition for a note, but that USMARC works along the lines that as long as the text is found in a 5xx field it is a note. Steve Hensen, representing the American archival community, picked up on Wendy's point. The information placed in this field by archivists is very critical information, describing scope and content. It is much more important than a note, even though the text is structured like a note. Sally was able to offer some history on the 5xx fields. Originally, the 5xx field names didn't always say note. At one point, there was an effort to standardize by adding note to each field name. To help the archival community utilize USMARC to its fullest, she recommends dropping the word note. Rebecca pointed out that the RAD rules state that this field should only be used for scope/content by archivists, but that others may use the field. Paul was still not convinced, finding that catalogers are confused when there is inconsistency in the format. Robin did not think that a field label limits its use necessarily. Wendy Duff urged MARBI members to support a broad use of the format, encompassing different materials and ways of cataloging. Sally agreed, stating that it is a USMARC convention to accommodate many sets of cataloging rules. Frank Sadowski moved to approve the proposal with the exception of the 2nd bullet (i.e. do not remove note from the field name). Indicator value 3 for Abstracts should also be approved. Sally asked if there was any discussion on the display constant for value 3. Joe Altimus and Diane Hillmann spoke up about the need for indicator value 3. Marti Scheel reported that NLM will use it, if it is approved. It was agreed that "Abstracts" should be used as the display constant. Robin Wendler provided a second. Paul spoke again against the motion. He didn't want the word note to be removed from the subfields either. He didn't want title/subfields to be treated differently. Robin thought that the entire field constitutes a note. Frank thought that if the title of the field has the "note" word, one can assume the subfields are part of a note. Jacquelene called for a vote. There were three votes in favor, four votes against, and one abstention. Paul Weiss moved surprisingly to accept the proposal as written, with the addition of value 3 for Abstracts. Elaine Henjum made the second. There were five votes in favor, no votes against, and two abstentions. PROPOSAL 96-8/542 : "New field 542 for location of related archival materials" This is a field pointing to another collection of archival materials, where there is some relationship to the collection being described in the MARC record. Canadian archivists would like to distinguish between materials with the same provenance residing in a different repository (associated-- new field 542) and materials with a different provenance but shared sphere of activity (related -- field 544). Joe Altimus questioned the need for a new field, since the distinction is a fine one. He suggested indicator values instead, and also pointed out that the 544 field is in use and already has some "associated" entries. Rich Greene agreed, and also recommended indicator values. Rich thought that it would be confusing to have the same subfields in use in both fields, and that the different field names would not be particularly useful in helping people keep the fields separate in their minds. Wendy Duff explained that the principle is to describe all material of the same provenance in the same description. In some cases, papers transfer from one organization to another; archivists use a narrative note to explain. In other cases, the person deposits papers in two depositories, and archivists cannot use the same note. Paul understood this distinction, and said that a MARBI principle is to not criticize cataloging rules and established practices. He suggested using the 544 field and establishing indicators for the two types of notes. Steve Hensen pointed out that the RAD rules make the distinction very clear and elegant. Two separate notes warrant two separate fields to his mind. Diane Hillmann stated that there is no argument on the need for two separate notes, just how to code. It is very important for MARBI to save field tags wherever possible. Wendy added that it is sometimes necessary to record both types of fields at the same time. But since a field can be made repeatable, indicator values became acceptable to the archivists at the table as they thought about it. Paul gave the example of the 024 field, where two different numbers (ISCR or UPC) can be listed, distinguished by indicator value. Agreeing to use the 544 field, it was then necessary to change its name, add indicator values, and change the names of some of the subfield names. There was some discussion about the Related Material Note. It should be $n and it should come before the other subfields. It was agreed to simplify the name of $n to Note. A motion was made as follows: -- Change the name of Field 544 to "Location of Other Archival Materials Note" -- Define the first indicator as Relationship with two values: 1) Associated Materials and 2) Related Materials) -- Add the $n Note subfield -- Change name of $d to "Title" -- Change name of $e to "Provenance" Diane Hillmann provided a second. There were eight votes in favor and no votes against. PROPOSAL 96-8/545 : "New indicator for field 545 (Biographical or Historical Note)" Archivists want to distinguish between biographical sketches of persons or families and administrative histories of corporate bodies placed in the 545 field. The proposal recommends defining three values in the first indicator position, and changing slightly the name of the field and a couple of subfields (get rid of "note" like above). Paul asked if a practical reason for the proposal was so that different displays could be generated. Wendy Duff replied in the affirmative. Steve Hensen said that the primary consideration is to be able to index and manipulate the two types of data differently. John Attig then wondered if the proposal should include display constants, and an indicator 8 for when no display constant is desired or appropriate. Sally was not sure that this was necessary at this point. John Espley asked for verification that display constants are only recommended, and not a required part of the standard. Sally verified that this is correct. Wanting to drop "note" from the description of the field, it was agreed to change this word to "data." It was agreed to do the same with the name of $a. It was agreed to make $b obsolete. The three values of Indicator 1 were acceptable. The proposal was moved and seconded, with no changes. There were seven votes in favor, and no votes against. (One committee member had left the room and did not vote). PROPOSAL 96-8/561 : "Changes to field 561 (Provenance)" The archival community proposes changing the name of the field to "Custodial History", to better represent the use of the field according to both the APPM and RAD cataloging rules, and to make $b (Time of Collation) obsolete, since archivists have found it is better to include the date information as part of the $a text. Wendy Duff explained the importance of provenance vs. custodial care to archivists. Archivists define the difference between the two as: - provenance (the person or organization who created, collected, used, or otherwise defined the collection of materials) - custodial care (the person or organization that is maintaining or has maintained the collection, but doesn't add to or change the collection). Steve Hensen reported that archivists currently use this field for custodial history data, so there are no conversion issues. John Attig asked if $b is currently in use. Steve did not think so. Sherman Clarke reported that the Visual Resources Association is at an early stage in defining its use of the USMARC format, but there may be a request in the future for a provenance field. There was discussion about how the art history and archival communities define and use the term provenance differently. Elizabeth O'Keefe reported that the Morgan Library uses the 561 for all the previous owners of a collection, whether the original creator/owner or a later custodian. Steve stated that there are custodial aspects to the use of the term provenance within the art history community. He thought it might work for both communities to use the field, as long as there wasn't confusion about the terminology. Wendy was concerned. She believes that the art history community defines provenance from the point of view of documenting change in ownership for an art object. The archival community does not want the creator to be put into the 561 field, as it belongs in the 1xx. Paul Weiss moved to approve the proposal. Josephine Crawford provided a second. The chair asked if there was further discussion. Diane Hillmann expressed a concern with moving ahead with the proposal, if there might be some remaining need to put "provenance" in a 5xx field. She proposed expanding the use of the field, rather than changing it. Robin suggested that if the field is just used by archivists to date and VRA is not yet ready to propose something, couldn't the field be expanded later on? Sherman felt that this would be ok. But, given use of the 561 field by the Morgan Library, there is some chance that others are recording provenance/creator data in the field at this time. Elizabeth O'Keefe suggested a "wobbly" field, one that satisfies both needs. Steve pointed out that the archival community is quite large and prefers "custodial history" in the name. Wendy proposed the name "History of Ownership and Custody." Others liked this. The terms overlap but are used differently by different communities. The field description can explain a little about the different interpretations by the different user communities. Paul Weiss withdrew his motion. Diane Hillmann made a motion to change the name of the 561 to "History of Ownership and Custody," to change $a in the same way, and to make $b obsolete. Paul provided a second. There were eight votes in favor and no votes against. PROPOSAL 96-8/040 (Authority) : "Add subfield for rules to field 040" The 008/10 is a single byte for coding the descriptive cataloging rules used in the bibliographic description. In addition to codes for AACR, AACR2, and before AACR, there is a "z" code for other but there is no place to specify what the other code is. Parallel to 008/10 is 008/11 for subject heading system, and 008/11 points to 040 $f when encoded with the "z" value. The proposed change is to add a Description Convention Subfield ($e) to the 040 field, to which 008/10 "z" would point. Paul Weiss moved to accept the proposal with no changes. Robin provided a second. There was no discussion. There were eight votes in favor and no votes against the proposal. PROPOSAL 96-8/$w/0-t (Authority) : "Add Control Subfield code for Immediate Parent" The archival community would like to add another value to the $w codes in the Authority 4xx and 5xx fields. The $w/0 byte provides heading-specific details about special relationships, to assist in the use of a field. The proposed code is "t" for Immediate Parent Body, for names of the parent body of firms entered in the 110. This code would be used for corporate bodies only. It was pointed out that the example is wrong in the proposal. It should read 110 (not 100) and 510 (not 500). Diane Hillmann recommended that the USMARC documentation provide detailed instructions and definitions of terms like "parent" since the terminology and use is complex. Sherman Clarke expressed some concern about the proposed code since standard NACO practice would not create this kind of reference. Diane could see why this reference is particularly useful to the archival community. Paul could see usefulness to the broader bibliographic community, as a mechanism for linking parent/child that would be more flexible than cross references. He felt that the NACO documentation should provide the detailed explanation, rather than the USMARC documentation. John Espley also thought the code is a useful addition to the format, and preferred detailed information in USMARC. He wondered about the display label; is Parent Body ok? He pointed out that vendors work more effectively with guidance built into the USMARC format. It was agreed to add Body to the name of the code. Diane Hillmann moved to pass the proposal with the change of the name of value "t" to "Immediate parent body." Robin Wendler provided a second. There were seven votes in favor, no votes against, and one abstention. PROPOSAL 96-8/678 (Authority) : "New indicator and subfield for field 678 (Epitome)" Candian archivists also want to include biographical sketches of persons and administrative histories of corporate bodies in authority records and to distinguish between the two types of data. It makes sense for the field to parallel 545 (Biographical or Historical Data) in the bib format. Authority Field 678 was defined to contain biographical, historical, and other information about the 1xx heading. It can be expanded to meet the needs of the archival community. Specifically: - Add an indicator 1, with three codes (no info, biographical sketch, and administrative history). - Add a $b called Expansion. - Change the name of the field to "Biographical or Historical Data." - Change the name of subfield $a to "Biographical or Historical Data." Diane Hillmann spoke in favor of the proposal. No one spoke up against the proposal. Diane moved to accept the proposed changes to field 678. Paul provided a second. The chair asked for further discussion. There was none. There were eight votes in favor, and no votes against. PROPOSAL 97-1: "Definition of Second Indicator (Relationship to Source) in Field 856" Rebecca Guenther introduced this proposal. The main part of the proposal is to define a second indicator to show the relationship of the electronic resource listed in 856 to the entity described in the cataloging record. There would be five values in the 2nd indicator, each showing the different types of links that are now made. Rebecca has identified a number of variations, such as electronic location of resource itself, electronic location of online version of resource, electronic location of a subset of resource, etc. Not only can the 2nd indicator be used to supply display constants on OPAC screens, but it could also be used to order multiple 856 fields in the same record. The second part of the proposal suggests adding a value 4 for HTTP access method to the first indicator, since the World Wide Web is so predominant at this time. Rebecca does not recommend creating values for all access methods, but HTTP is so important, its addition will save catalogers from having to create a $2 in many, many 856 fields. Jean Hirons, representing CONSER, spoke up in favor of the proposal. The practice is to add an 856 to the record of the original serial, because there are so many related resources. The 2nd indicator would help organize and differentiate between multiple 856 fields. John Attig spoke up in favor of the RLG recommendation to use the display constant "Resource Availability" rather than what is proposed. Frank Sadowski prefers the display constants in the proposal, thinking they are very clear. However, it was pointed out that display constants are only recommended. Frank asked for an explanation about how $3 fits in. Rebecca said to look at Example 2, where the record describes the original but only the table of contents is digitized at this time. Therefore, the $3 states what the URL represents. Diane questioned using 2nd indicator, value 1 in Example 2, but she wasn't sure what she would use in its place. She pointed out that there can be different tables of contents on the Internet for the same resource. Paul Weiss questioned Example 3. He doesn't believe that a finding aid is a subset of a resource. Rebecca said that when $3 was originally proposed, MARBI thought the finding aid example an appropriate use of it. John Espley reported that VTLS libraries are putting in a lot of 856 fields, for audio links or scanned images of dust jackets. Rebecca asked what type of 856 they would be considered. Jean Hirons reported that these uses were discussed when formulating the CONSER guidelines. In these two examples, the links are usually not integral to the bibliograpic description, so are considered a related resource. Robin Wendler reported that Harvard Music Library considers the thematic description to be part of the bibliographic description, not separate. Catherine said that if you are describing printed music, you then have a related link to the audio. Paul said that there is a distinction, but only some users will care about it. Robin continued on to say that the original purpose of this field was to put in a link that matched the item being described. She questioned the description about DP87 in the background section of the proposal (third paragraph). Diane said that if you insist on only putting in links that were a 100% match to the item being cataloged, catalogers would have to create many more records. Frank and Josephine were able to see the benefits of having records for each entity; they shared Robin's concern that database maintenance could become very difficult under this scenario. Yet, creating records for everything is just not feasible, and people are already creating these other types of links. Rebecca pointed out that the Dublin Core has a RELATION field that currently maps to the 787 field (Nonspecific Relationship Entry/Note). Robin was confused on the difference between an electronic location (2nd indicator 0) and an electronic version (2nd indicator 1). Paul explained that the GMD is different because the online version might have different content. Jean said that this situation was discussed at the CONSER meeting. It is an option to use the same record, but catalogers won't describe all the differences. Users can see by going online. Tom Champagne spoke up in favor of the proposal, seeing it as very useful. Cecilia Tittemore agreed. She believes programmers will make use of the indicators for manipulating displays. Josephine Crawford reported that she had received the same feedback from catalogers and programmers at the University of Wisconsin. Paul asked if two display constants can be listed in the USMARC format for a particular code. Yes, since both are suggestions and it helps the community scope out possibilities. Diane Hillmann made a motion to accept the proposal as written. Carol Penka provided a second. In the discussion about the motion, Paul expressed concern about the use of $3, thinking that there is too much variation. Rebecca countered that although people are using $3 in different ways, the detail is very useful. There were six votes in favor, no votes against, one abstention, and one member out of the room. PROPOSAL 97-3 : "Redefinition of Code "m" (Computer File) in Leader/06" Rebecca Guenther introduced this proposal. There have been two previous discussion papers, each taking the ideas a little further. This proposal brings back several options for redefining codes "m" and "p" in the Leader/06 -- basically covering broader and narrower options. Jean Hirons spoke up immediately in support of the idea of the proposal. Would like electronic serials to be coded as "a" not "m". Then use the 007 to identify type of computer file. Catherine Gerhart reported that there was a CC:DA straw vote in favor of delaying this proposal until sometime after the October conference in Toronto on the future of AACR2. An important issue to be discussed there is content vs. carrier. Sally asked if CC:DA members were familiar with the earlier two discussion papers. Yes, Catherine replied, and concerns were expressed when both were discussed. Rhonda Lawrence wondered if CC:DA isn't too often in the delay mode. Frank pointed out that CC:DA members are in touch with the Joint Steering Committee for AACR2. Diane Hillmann reminded everyone that catalogers are creating records every day with the "m" code -- the mess gets bigger and bigger by waiting to redefine the code. We should try to deliver good results to users with improvements that are feasible now. Paul Weiss thought that we should move ahead with textual computer files, but not graphic maps or other types. Assigning the codes will be hard for catalogers, but the definitions improve with each round. He was particularly concerned with the difference between kits ("o") and mixed materials ("p"). Rebecca believes that Option 1 gets around this problem. Paul thinks that more and more will be published, and it will become a bigger and more confusing problem. Jean Hirons asked the meeting to return to the idea of MARC coding, not how to catalog. She believes that the coding changes will be helpful for indexing and displays. Rich Greene debated further the issue of delaying or proceeding ahead. He could see both sides, and wasn't sure if any of the options would work in the OCLC system. First, catalogers must be clear when choosing a type of record. Many equate an AACR2 chapter to a type of record. Second, consistency between systems is really important to bibliographic control in these times. Third, and most importantly, it is necessary to differentiate between electronic versions and other versions of a work. Can this be accomplished with any of the Proposal's options? Karen Coyle asked about a code for records representing interactive systems. She believes one is needed. Rebecca felt that this could be mentioned in the definition of "m". A member of the audience spoke up in favor of postponing the issue. It was felt that the proposal is not deep enough to move forward at this time. John Espley agreed with Rich Greene's third point especially. It is important to identify other characteristics. Catherine talked about trying to catalog an electronic atlas. She used an 006, but the record came out really strange. Rebecca suggested using an 007. Paul suggested using multiple AACR2 chapters. Diane and Jo came down on the side of postponing the proposal, while the options are explored in more depth, examining as many real-life examples as possible. Karen said that the goal now is to let serials people not have to use "m" when clearly coding for content is better than computer file. But, others said that the format change will affect special materials. Paul asked if the change would open up the floodgates. Jacquelene decided to take a straw vote. How many people think that either Option 1, 2, or 3 is viable today? Perhaps 25. How many people will not accept any of the three options today? About the same. What if the proposal was limited to textual content only? Only eight people would be willing to proceed. Sally pointed out that people are coding for content anyway! She asked what is needed to act on this proposal in the summer. First, deal with OCLC's concerns, especially the consistency between systems issue. Second, redo Attachment A. Third, people should supply as many examples as possible to Rebecca. It was felt that examples are really important. PROPOSAL 97-7 : "Coding Leader/06 and Leader/08 for Archival Material" Steve Hensen, representing the Society of American Archivists and Duke University's Digital Scriptorium Project, introduced the proposal. He explained that there has not been a prior discussion paper, because there is some urgency in solving some unintended problems caused by the implementation of Phase II of Format Integration. Defining archival control is not easy. Both catalogers and utilities have been confused. There has been considerable discussion about this proposal in the archival community. The solutions presented here have not been universally approved, but there is a consensus in the community to move forward. Wendy Duff stated that there is a history of collaboration between the Canadian and American archival communities, even though the two communities use different cataloging rules. The Canadian community supports this proposal. Chair Jacquelene Riley suggested that MARBI discuss each proposed change separately. 1) Redefine Leader/08 "a" (Language Material) code. It is recommended to change the name to Textual Material and, more importantly, to change the definition to emphasize "primarily textual." Paul Weiss asked if the utilities will lump together materials cataloged by RAD (Canadian Rules for Archival Description) and APPM (Archives, Personal Papers, and Manuscript) rules. Sounds like this is the case. Rich Greene stated that OCLC supports this proposed change. OCLC wants to treat archival materials separately from other materials, and sees this code as a good way to do it. Paul and John Attig wondered about Leader/18, Descriptive Cataloging Form. How does Leader/18 fit in? The archivists replied that this is a related code, but Leader/08 is better overall for the purpose in mind. Some materials are held by an archive, but are not under archival control. Examples are Codex manuscripts and modern literary manuscripts. This proves an "a" code is needed in Leader/08 to distinguish those materials under archival control. Diane Hillmann wasn't easily convinced; she felt that there is a longstanding tradition to not handle literary manuscripts archivally. 2) Make Leader/07 "t" (Manuscript Language Material) code obsolete. The rationale is that "manuscript language material" is ambiguous and misleading to both searchers and catalogers. The definition states that the material is usually intended to exist as a single instance, but this characteristic does not fit in with today's technological environment where multiple versions of manuscripts are possible electronically. John Attig reported that he and Rutherford Witthus met with the RBMS Bibliographic Standards Committee. It became clear that there are manuscript materials that must be distinguished from those under archival control (Leader/08 "a"). Some examples are theses/dissertations and individual manuscripts. It is very important to be able to search and/or limit a search to these materials. Therefore, an argument was presented to maintain "t" and improve the definition. Steve Hensen reported that this had been discussed by the people involved with this proposal. There was some question as to whether or not the function could be handled via the 008. The Digital Scriptorium Project is re-inventing how to catalog codex manuscripts. The user community wants manuscripts to be separate from other records, yet institutions want to use USMARC for obvious reasons. Involves a logical separation based upon good coding. Right now the cataloger has to choose between archival control and books. Neither choice works very well. Steve Davis also suggested coding this somewhere else in the record, in a spot not as high as the Leader. Robin Wendler added that users really need the ability to retrieve results merged or separate, depending upon the specific user need. Steve Davis asked for more information about the Digital Scriptorium Project. Will it be treating all manuscripts in the same way? How will "medieval" be shown? Steve Hensen replied that the papyrus archives has about 1500 records at the present time. Whether using the RAD or AAPM rules, this doesn't necessarily mean archival control applies. Therefore, combination of Leader/06 "t" and Leader/08 "a" is very helpful. Leader/06 "t" only is not enough due to the materials published by UMI. Leader/08 "a" is not enough due to the categories of manuscripts that are not under archival control. Perhaps it is best then to code as independent characteristics. Paul Weiss asked for other examples of manuscripts not under archival control. John Attig stated that two clearcut examples have already been given, and this is enough to work on improving the format (e.g. theses/dissertations and individual manuscripts). Steve Davis felt that it will get harder and harder, because conceptually there are many types of manuscripts. Robin Wendler pointed out that we have 500 years of handling manuscripts in the original sense, and yet the rationale for making "t" obsolete is that it is too hard to define. Another pointed to technology for making this problem so difficult. We have moved from the single possibility of handwriting to multiple possibilities: typescripts, xeroxing, scanning images, etc. Paul Weiss suggested making three codes in the Leader/06 obsolete: "t" (manuscript language material) "d" (Manuscript music) "e" (printed map) and then defining a new 006 for manuscripts. Sally McCallum wasn't so sure that this would be the best approach because the 006 is finely tuned to the 008 (wouldn't want to change the 008 in any big way). John Attig also felt that the 006 is not a good field for secondary characteristics. Sally suggested that this issue needs further analysis and a new proposal that includes a place for distinguishing codex vs. non-codex manuscripts. There was much back and forth, and then agreement to hold on making "t" obsolete until all the options can be identified and analyzed. Certainly, making all three codes obsolete should be examined as part of this. 3) Leader/06 "p" (Mixed Materials) code. It is recommended to redefine this code to change the standard as to when to call a collection mixed. The current definition emphasizes physical quantity, whereas the new definition leaves it to the cataloger based on quantity or other factors, such as the focus of a collection or the intellectual importance of the material. Steve Davis asked what is the function of this byte? To define a system file, for retrieval, or what? He suggested the option be there, but didn't think universal consistency was reasonable. Catherine Gerhart wondered if catalogers don't use their judgement all the time. Isn't this the difference between original and copy cataloging? Wendy Duff felt that this was too broad a view..... the archivists are requesting a specific change to the standard so that the standard better accommodates preferred cataloging practice. Robin Wendler believes that the situation is different depending upon if a cataloger is dealing with published or unpublished materials. Steven Davis felt that there is no clear cut way to decide what is predominant. He supported leaving the code more open to cataloger's judgement, since the description occurs within the context of the collection description. Paul Weiss asked about a graphic map. Is it a map or a graphic? OCLC documentation tells catalogers what to do, but USMARC does not. He suggested using a "p" in the 006. Rebecca Guenther felt that this is a premature suggestion. Karen Coyle asked if a system can now distinguish what most users would call a book. She thinks "book" is useful. Paul does not think that this can be done now. Steven Davis said that we now have to think about "digital objects." Robin suggested that, under the Books format, we could have a digital code. But, this is a problem if manuscripts are cataloged under the Books format. Sally McCallum believes that part of the problem is one of Format Integration implementation. The cataloger workforms have to catch up with FI! 4) Redefining name of 008 field from Books to Textual (Nonserial). This part of the proposal becomes necessary if the changes to Leader/06 are approved, because this field would then encompass more than books. 5) Delete field 006 for Mixed Materials. Mixed is now not considered to be a physical characteristic, so this field is logically inconsistent. It is believed that no one is using it. Jacquie Riley made a motion to accept the redefinition of Leader/08 "a" and Leader/06 "p" and to delete the 006 for mixed materials. Both Robin and Paul spoke up against parts of the motion, and there was no second. Jacquie then made a motion to redefine Leader/08 "a" and to rename the value as in the proposal. Paul Weiss provided a second. There were eight votes in favor and no votes against. Jacquie made a third motion to accept the redefinition of Leader/06 "p" as presented in the proposal. Frank Sadowski provided a second. There was some discussion about letting the archival community move ahead in this area, rather than hold them up while the map and music communities are consulted. There were five votes in favor, two votes against, and one abstention. Jacquie made a final motion to approve deleting the 006 for mixed materials from the format. Rebecca felt that this was not possible from the utility point of view. Paul recommended holding back as long as "p" was still under discussion. Frank Sadowski made a second. This motion did not pass. There were two votes in favor, four votes against, and two abstentions. The rest of the proposal was tabled until the next conference. Input from the map and music communities will be sought by LC staff. Jacquie closed the meeting by thanking the archival community representatives for months of activity and work on the various proposals. **************** Monday, February 17, 1997 ********************* The PLA Community Information Section Technologies Committee, represented by Louise Sevold, requested that provisional status be removed from the Community Information Format. The resolution from the Committee follows verbatim. "February 16, 1997 PLA/CIS Technologies Committee. Lee Ireland chair. The following resolution was passed at the PLA/CIS Technologies Committee meeting on February 15, 1997. The USMARC Community Information format was adopted as a provisional format in 1992. The Library of Congress developed this format at the request of the library community to provide a standardized method of classifying and indexing community information. Since its publication, the format has been widely adopted by both the library and vendor community. Libraries of all sizes, from large, urban systems, to small libaries, are now using the format. Practically all of the major library automation vendors-- DRA, Endeavor, Gaylord, GEAC, Innovative, SIRSI, VTLS -- have incorporated this USMARC format into their software. The support of the format in library automation systems has contributed to its widespread adoption by libraries. Since the publication of the format by the Library of Congress, few changes have been proposed by those who use the format. The original design of the format has provided librarians with the flexibility necessary to describe the wide variety of resources in their communities. Therefore, we recommend that the US Community Information Format be removed from provisional status. With this change the format would join the other USMARC formats and be regularly maintained and updated by the Library of Congress." Paul Weiss asked if work was complete on the CI format. Louise Sevold, Diane Hillmann, and John Espley all stated that the format is working well at this time, and there are no outstanding issues. They supported removing the provisional label. Diane Hillmann made a motion, and this was seconded by Carol Penka. There were six votes in favor, one against, and one abstention. PROPOSAL 97-5 : "Changes to the USMARC Classification Format for Multilingual Classification Schemes" Joan Mitchell, representing OCLC Forest Press, introduced this proposal. In 1993, the IFLA sections on classification and information technology appointed a joint working group on the development of a MARC format for classification data, which looked at the topic of multilingual classification schemes. Elaine Woods was commissioned as an outside consultant. There were many reviews in a couple of different stages. In July of 1996, the working group approved a requirements document, which has led to this proposal. This is expected to be the first of several proposals to MARBI. A future one may deal with the issue of scripts. Joan reviewed the importance of this proposal and what the working group would like to accomplish. First, classification schemes can help worldwide bibliographic control because the notation (i.e. the class number) is not specific to any one language. It is a common control language that could be used as a switching language in multilingual databases. Any class number's caption could be displayed in the preferred language of the user. This is the primary goal. It is not possible to do this, however, without adding the Source and Edition information to the classification records. It is therefore proposed to define some new subfields ($d Source Edition Identifier, $f Authorization, and $n Variations) in the 084 (Classification Scheme) field, to make the 084 $e repeatable, and to define a new field 686 for Relationship to Source Note. Robin wondered immediately if it might be better to show authorized/unauthorized translations in a code, rather than free-text in the 084 $f. Paul Weiss suggested an indicator value. Rebecca Guenther reported that this had been considered but rejected. Sherman Clarke asked for clarification; what is being authorized here? The number or the caption? Joan explained that the cataloger is showing that the edition has been authorized or not authorized, so it has to do with the caption. To give an example, there is an abridged, authorized French translation of DDC, as well as an abridged, unauthorized French edition. Paul asked why it was necessary to code authorized/unauthorized in every single classification record. Couldn't there be a look-up table? Joan reported that there can be more than one translation in a record in the same file. She also said that the plan is to use $f only when the translation is unauthorized. She was asked how the information will be used. Joan replied that they are trying to break new ground but the main purpose is to communicate the value of the information in the record. The records will be used by OPACs to display captions to users, the records will be used by other translators, and the records will be used by catalogers. Michael Johnson agreed with Robin Wendler that codes would be better to represent authorized/unauthorized. This would facilitate machine processing. It was suggested to put the code "unauth" or other abbreviated data in the $f. Joan said she appreciated the suggestion, since many implementation details remain to be worked out. A question was asked about the UDC multi-language edition. Will each number be represented by a single record (for all the languages) or a record for each different caption? Unknown at this time. Paul Weiss raised a concern about the 084 $d (Source Edition Identification). He could see why this information is important but felt that more data was needed for the stated purpose. Joan responded that further details about the translation would be added to the $n. Paul noted that there will be a lot of inputting and storage of data, since the same note will be repeated in each number's record. Bonnie Dede explained that it is useful to keep the information in each record. She suggested that "unauthorized" be input into the $n, that the $n be made repeatable, and that the $f be eliminated. Diane Hillmann wasn't so sure that inputting is a problem, since increasingly catalogers can use templates or cut and paste. She agreed with Bonnie that it is useful for a cataloger to see up front what is happening, whereas if a cryptic code is input, one must go look it up. Paul recommended that the Relator code list include a code for each edition. But, when combining records, you need to know which edition is relevant at all times. Paul felt this could be done by the system since it could do a table look-up. Robin felt that there is a strong relationship between $n and $c, and more than one subfield in the same field might confuse the meaning of the data. Joan explained in some detail that each translation is its own unique thing, and that it is very hard to keep them all straight. The USMARC format is being used as a transmission medium, not for storage, so she doesn't share Paul's concern. Diane stated that it is important to the cataloger knowing the exact meaning of each piece of information in a classification record. Josephine Crawford spoke up in favor of codes, as this would be more efficient in the long run as more and more translations come out. Unfortunately, Joan responded, there are many, many translations and there is no one to track them and add codes to the Relator list. Joan emphasized that they want to look at this issue from a multilingual and user point of view, not from a cataloger point of view. It is an exciting thought to think of an OPAC in California where DDC captions could display in either English or Spanish, depending upon the user's preference. They are trying to lay a foundation, and want to get the data moved from word processing files (where it commonly resides now) to the USMARC format! Robin Wendler asked how the 084 $n data would relate to the user. Joan said that this data would be used by the system programs. These implementation details cannot be ironed out until the basic proposal is passed by MARBI. Paul explained that he and some other MARBI members are showing reluctance because it is not good to start using unnormalized data, when it could be normalized up front. The bibliographic community has learned lessons from the past-- for example, normalized data is much better from a data management point of view. Joan Mitchell went on to describe the proposed 686 (Relationship to Source Note) field. She walked the Committee through a couple of examples. The Crevalcore, Bologna example on page 5 illustrates the use of an Italian translation of the 20th edition of DDC. The number 454126 assigned in the 153 field is an expansion in the Italian translation to cover more geographic sites in the province of Bologna. The 20th edition DDC number 4541 is shown in the 686 field with an indicator value to show that an expansion has been done. When in the same source edition, the 686 $2 is not used. The $2 only shows exceptions. Pizza is used as an example of an adaptation. In DDC, pizza is considered to be a "meat and cheese pie" but, in the Italian edition, pizza was moved to another number so that it is classified under "bread." This adaptation represents cultural differences between countries. Someone asked why the Turkish adaptation example has some fields in Turkish (084 and 153) and two 686 fields in English. Joan explained that the caption is input in the language of the edition or translation, but that the rest is input in the language of the cataloger. Betsy Cowart asked if the subfields are in any prescribed order. No, although there is a natural order that is used depending upon the meaning. Sally pointed out that USMARC only occasionally recommends the order of subfields, but that it is not needed in this case. Paul asked about the 686 $o subfield. This is the number where the instructions are found. Paul asked if this refers to the source edition or the translation. Joan replied that it refers to the source edition. Paul moved to pass the 686 field as described in the proposal. Frank Sadowski provided a second. There were eight votes in favor, and no votes against. Diane Hillmann moved to pass the 084 field, and Elaine Henjum made the second. There were four votes in favor, three votes against, and one abstention. PROPOSAL 96-8/9XX : "Add Fields in the 9XX Range" This proposal had been discussed in some depth on Saturday, February 15. Strong opinions had been expressed in favor of the proposal and against the proposal. Margaret Stewart reported that the Canadian representatives had considered Saturday's discussion carefully. Given all the considerations, the recommendation was to create an appendix in the USMARC documentation listing the CanMARC 9XX fields. Cross reference fields are part of these 9XX fields, and they would consider leaving them out. They will make every effort to show that other 9XX fields are local fields, and that these are the Canadian bibliographic fields. Robin Wendler recommended that the appendix talk about 9XX fields generically, and then supply examples from Canada, RLG, OCLC, etc. Betsy Cowart saw this more as a separate document than an appendix. Sherman wasn't clear if the document will show "examples" or show "all uses." The intent is to show examples only. Rich Greene reported that OCLC doesn't want to be included in this appendix for two reasons. The 9XX fields don't change much, and OCLC doesn't want to be tied to an LC publication schedule. Paul moved that LC and NLC staff work together to create this appendix, given the many comments made on Saturday and Monday. Frank Sadowski provided a second. John Attig asked for clarification: MARBI then is leaving the issue up to LC staff? Yes. Robin and Diane emphasized that it is very important that it be made clear that 9XX fields are local only, so that vendors and catalogers are not confused. There were five votes in favor of the motion, and three votes against. PROPOSAL 97-2 : "Definition of Second Indicator (Display constant controller) in 76X-78X Linking Entry Fields" Rebecca Guenther introduced this proposal about the linking entry fields. A problem was introduced when the 774 field was passed (Proposal 96-4). The $i subfield was defined for all the linking entry fields, but no mechanism was established to suppress the default display constant when the $i is used in the field. The second indicator # value is used to trigger the display of a constant specific to the tag. The second indicator 8 value would be used to suppress an automatic display constant so that the $i text can display instead. It is also recommended that the 774 field second indicator 0 value be deleted from the format, because it is the same as value # (Constituent unit). John Attig asked why the $i was added to the 786 and 787 fields, since no display is recommended. Rebecca responded that they wanted to add the $i across the board, and there could be a use for $i in 786 and 787. Paul added that it is efficient from a system perspective to process all the linking fields in the same way -- i.e. display prefix from $i. However, the 246 is not the same, so this is confusing. Diane Hillmann considers the 246 to be an exception. As for value 0, Sherman wondered what MARBI had in mind when 96-4 was passed. Rebecca said that it was simply a mistake because of the original two options in the proposal, and that two different values were defined for the same thing. Value 0 can be easily deleted, because it was published but not yet implemented. Diane made a motion to accept the proposal as written. Paul provided a second. There were eight votes in favor and no votes against. PROPOSAL 97-4 :" Addition of Subfield $5 in field 655 (Index Term--Genre/Form) in the USMARC Bibliographic Format" Rebecca explained that this was a straightforward request. Sometimes the physical form is represented in the 655 field, and sometimes this form applies to a specific copy, not to all copies. The recommendation is to create the $5 where a cataloger can input the USMARC code of the institution that owns the copy with the specific physical characteristic. When the subfield is not listed, the 655 form applies to all copies. Representing Harvard University, Robin Wendler urged the approval of this subfield. There are many cases where the form in the 655 shows a very special characteristic (such as a fore-edge painting on a rare book) and it is important to code this data precisely. Paul Weiss spoke up in favor of the proposal, and also suggested that it would be a good change for the Holdings Format. He moved to accept the proposal as written. Diane Hillmann provided a second. There were eight votes in favor, and no votes against. PROPOSAL 97-6 : "Enhancements to Field 007 (RSI) for Remote-Sensing Images" Sally McCallum introduced this proposal, saying that it was a follow-up on recent MAGERT work and the USMARC/CanMARC harmonization work. Susan Moore, MAGERT representative, reported that the MAGERT Cataloging and Classification Committee worked on this proposal. There is a strong need for approval. Margaret Stewart worked with the Canadian cartographic community who also believe the changes will be useful. Paul Weiss wondered if MARBI was being asked to approve a situation where two different 007 fields would be input in a single record. Susan explained that this is not the intention. Either the cataloger has a map or the cataloger has an RMI -- the two cannot co-exist. It was suggested to add the codes "z" for Other and "u" for Unknown in the 08 Sensor Type byte. Frank questioned the need for Other. Susan explained that sensors are either active or passive now, but the new codes will allow for new development which is likely to occur. The 02 byte is still undefined. Could it be closed up, moving all bytes forward by one. Gary Smith said that this should not be done. Sally asked why he thought this, since this 007 is a new field and is not yet in use. Is there a correspondence between bytes 03-10 in the 007 (Maps) field? No. But, Gary presented a convincing argument that 02 is obsolete in the other 007s and it is best to leave it undefined here, for prgramming ease. Paul Weiss questioned the wording in byte 03, Altitude of Sensor. Sometimes the target is not the earth, but can be Mercury or the moon. It was agreed to change the description to "A one-character alphabetic code indicates the general position of the sensor relative to the target" and to change the code "a" description to "Surface" rather than "Terrestrial." Paul also suggested that byte 06, Platform Construction Type, is defining some codes using feet. Wouldn't the metric system be better, since USMARC is becoming an international code? It was agreed to add the metric equivalencies. Robin asked about byte 05, Cloud Cover. Isn't this really important, and yet the coding is not accurate in all cases? She wondered if the byte should be called Percentage of Constricted View instead. Susan explained that the map cataloging community wants to be consistent with the "Content Standard for Digital Geo-Spatial Metadata" and this standard does not deal with other obstructions, just cloud cover. However, Susan will take this thought back to the MAGERT Cataloging and Classification Committee. Rich Greene asked about bytes 09-10, Data Types. It was not clear when to use the "mm" and "zz" codes. Margaret and Susan will get some additional information from map catalogers so this documentation can be improved. Paul moved to accept the proposal with the changes that had been discussed. Carol Penka provided the second. There were eight votes in favor and no votes against. There was also some discussion about making obsolete the value "r" in byte 01 of the Maps 007. This is a possibility, but Susan would like to first consult her constituency. If the change is desired later on, it will be sent through as a new proposal. DISCUSSION PAPER #98 : " Subentity Codes for Country of Publication and Geographic Area" Sally McCallum introduced this discussion paper by explaining that there have been requests to establish lists of subentity codes for the Country of Publication (008/15-7,044, 535$g, 775$f, 851$g, and 852$n) and the Geographic Area Code (043). Right now USMARC documentation has country codes and some subentity codes (for US, Canada, and the UK) in the 008/15-17. There is also a draft ISO standard where it is up to each country to select and register their own subentity codes. Sally mentioned the following. First, there is a certain amount of consistency between the various lists, but only a certain amount! And, second, there are constraints in the MARC format for codes. For instance, GACS would not accommodate the numeric ISO subentity codes. Third, the ISO 3166 standard is in flux, alot depending upon the participation and stability of the country. This problem has been around for awhile too. Since Australia is now adopting USMARC, Australia would like to add its subentity codes to USMARC. Diane Hillmann stated that she believes that the 008 and 043 have different purposes. Aren't both desired? Yes, Sally responded. David Goldberg felt that it would be hard to reconcile the differences between the USMARC lists and the ISO 3166 list. Sally had hoped that just the subentity list from ISO could be used, but David explained that some countries use a number and it is only meaningful when paired up with the ISO country code. Diane suggested using the full ISO code (country and subentity) in the 044 field. This would be strange to US catalogers but would make sense to the rest of the world since these codes are heavily used elsewhere (e.g. CH for Switzerland, not SZ). Gary Smith reiterated Sally's comment that the ISO 3166 codes are unstable, because they change when the country changes. Karen Anspach supported Diane's idea, because it would mean LC would not have to maintain a different USMARC list. Sally said that each country eventually has to face up to the issue of code stability. She also said that LC would not establish a subentity list until a country asked for it. Susan Moore suggested looking at the LC G schedule to see if the coding there might be helpful. Perhaps the 052 or the 033 could be helpful. John Espley reported that VTLS has overseas customers, and they would like to use the 008 Country code. Rich asked if the other countries interested at this time in using the USMARC format see it as a barrier that USMARC subentity codes for their country are not yet established. Generally no, since the countries just use their own codes. However, Sally recognizes that these records move around at an international level and she wants to look at the issue from the big picture point of view. E.g. Enable systems to validate a code established by another country or not? Sally said that one possible approach is to let the first 26 countries get subentity codes in the Country Code list. Another possibility is to let all countries "expand" into another subfield where a variable length subentity code could be recorded. Would a Swiss library, for instance, be willing to put 008 CT "sz" and then use a subfield in another field to show the Swiss canton using the ISO standard code? If this practice were instituted, then it follows that US records should convert the subentity from the 008 to the subfield. To allow for past practice and have a flexible approach in the future, it was suggested to set up the 043/044 with indicator codes for the type of code (USMARC or ISO), to put the country code in one subfield (could be optional if already coded in 008), and to put the subentity code in another subfield. The main thing is that if a cataloger is using the ISO list, the subentity code requires the ISO country code to be meaningful. Based upon this discussion, Sally will try to put together a proposal for a future meeting. DISCUSSION PAPER #100 : "Script and Romanization Issues in the USMARC Authorities Format" The discussion paper was not yet ready for distribution. Sally explained though that the intention is to develop principles in regards to script and romanization in the authorities format, and to consider system efficiency, inputting efficiency, multi-national needs, and multi-lingual needs. Meeting participants agreed that this is an important issue. There are field and record level issues to work through. Right now the authority record has 7XX fields and a parallel record is created for the heading in another language. Would it be better to have a single merged record for all the variations? Called a "mudball" record. If this is the case, what kind of system changes would be involved? These are the kinds of things that should be addressed. OTHER DISCUSSION TOPICS: Sally and Jacquelene attended a CC:DA meeting to discuss a joint meeting with MARBI at the annual conference in San Francisco. Would like to discuss the CC:DA report by the Metadata/TEI subgroup at this meeting. Want to try to collect the decisions of people putting AACR2 into TEI, and make a cross-walk from the format to the rules. It was suggested that this report by distributed ahead of time to MARBI as a discussion paper. MARBI has received a request from the LITA TESLA Committee to co-sponsor an ALA program in the Summer of 1997 on UNICODE. Corrie Marsh has been in touch with Jacquie. The request is to sponsor in name only -- MARBI does not have to do any work! The title of the program will be: Multiple Languages, Unicode, and You. Paul moved that MARBI co-sponsor this program in name only. Diane provided a second. There were seven votes in favor, and one abstention. Sally and Jacquie reported on the work of the Character Set Subcommittee at the conference. They both sat in on the meeting. The Subcommittee is making progress on the three possible solutions to the ASCII clone problem. Some additional Arabic characters have been identified and will be sent to the UNICODE people. Finally, it has been decided to recommend a subcommittee for the CJK work, so Sally is preparing a charge. Jacquie is looking for volunteers for this new Subcommittee. The charge will include the same guiding principles (e.g. reverse mapping). [Minutes prepared by Josephine Crawford, June 1997]