Thomas Saudargas, Chair RUSA Miami-Dade College Karen Coyle RUSA Independent Consultant Donna Cranmer LITA, Intern Siouxland Libraries Helen Gbala LITA Addison Public Library Wei Jeng-Chu RUSA, Intern Worcester Public Library Bruce Rennie RUSA Kansas City Public Library Adam Schiff ALCTS University of Washington Marc Truitt LITA University of Houston Mitch L. Turitz ALCTS San Francisco State University Martha Yee ALCTS UCLA Film and Television Archive
Sally McCallum LC Library of Congress Margaret Stewart LAC Library and Archives Canada
MARC Advisory Committee Representatives and Liaisons:
Everett Allgood CC:DA New York University Joe Altimus RLG Research Libraries Group John Attig OLAC Pennsylvania State University Paul Cauthen MLA University of Cincinnati Sherman Clarke VRA New York University Bonnie Dede SAC University of Michigan Gene Dickerson NLM National Library of Medicine John Espley AVIAC VTLS, Inc. Michael Fox SAA Minnesota Historical Society David Goldberg NAL National Agricultural Library Susan Goldner AALL University of Arkansas at Little Rock/Pulaski County Law Library Rich Greene OCLC OCLC, Inc. Robert Hall PLA Concord Free Public Library Alice Jacobs NLM National Library of Medicine Maureen Killeen AG AG-Canada Gail Lewis MicroLIF Sagebrush Corporation Susan Moore MAGERT University of Northern Iowa Elizabeth O'Keefe ARLIS/NA Pierpont Morgan Library
Jacqueline Radebaugh LC Library of Congress
Joan Aliprand RLG Karen Anspach Karen Anspach Consulting Diane Baden NELINET Tadeja Brešr IZUM, Slovenia Colleen Cahill Library of Congress Jack Cain Trylus Computing Betsy Eggleston Harvard University Lynnette Fields Lewis and Clark Library System Deborah Fritz The MARC of Quality Kathy Glennan University of Southern California Charles Husbands Harvard University George Johnston University of Cincinnati William Jones New York University Mary Larsgaard University of California, Santa Barbara Elizabeth Mangan Library of Congress, Retired Margi Mann OCLC Western Mary Ann O'Daniel Florida Center for Library Automation Ann Sitkin Harvard University Law Gary Smith OCLC Barbara Story Library of Congress Gary Strawn Northwestern University Paul Weiss University of California, San Diego Jay Weitz OCLC Robin Wendler Harvard University
Saturday, June 26, 2004
Thom Saudargas, MARBI Chair, opened the meeting by asking committee members, representatives, and liaisons to identify themselves. The proposed agenda was adopted and the minutes of the previous meeting (www.loc.gov/marc/marbi/minutes/mw-04.html) were accepted by a voice vote.
Proposal 2004-07: Applying Field 752 (Added Entry - Hierarchical Place Name) for Different Purposes in the MARC 21 Format for Bibliographic Data
Susan Moore (MAGERT) introduced the paper which discusses the variety of current uses of MARC 21 field 752 (Added Entry - Hierarchical Place Name) for place of publication, production, or geographic subject areas. The paper proposes two alternatives to facilitate indexing of different types of information currently coded in field 752. One alternative adds indicator values to field 752 to show whether the place name designates place of publication or subject. Another alternative defines a new field for subject use. The paper also proposes defining a subfield to identify a thesaurus and a technique for extending place hierarchies.
Mitch Turitz (RUSA) preferred adding indicator values to field 752 to identify geographic subject areas because they may provide the mechanism for displaying hierarchy better than a new 6XX field would. Karen Coyle (RUSA) however, stated that one may also display hierarchy for geographic subject areas using a 6XX field.
Betsy Mangan (LC, retired) explained that when the Geography and Maps Division at the Library of Congress began to mount parts of its collection on the World Wide Web, it coded field 752 with both place of publication and subject information. At the time, staff considered using a new field for subject information, however, this was not done because of time constraints. According to Barbara Story (LC), the staff members in the Prints and Photographs Division at the Library of Congress prefer the 6XX solution over using indicator values in field 752. Likewise, Adam Schiff (ALCTS) stated that because systems may have difficulty implementing the new indicator values in field 752, he also preferred the 6XX alternative over adding indicator values. Susan Moore (MAGERT) reported that MAGERT had no strong preference for either alternative presented in the proposal.
Rich Greene (OCLC) reminded the group that field 652 has been coded in the past and thus, should not be reused if the 6XX option is accepted. He suggested coding field 662 for this data. The group agreed with Mr. Greene’s (OCLC) suggestion.
Adam Schiff (ALCTS) motioned to create a 662 field for subject data and retain field 752 for place of publication information. Mitch Turitz (ALCTS) seconded the motion. Thom Saudargas (RUSA) however, suggested that the definition of subfields in fields 662 and 752 be discussed before a final vote is taken. The group agreed.
John Attig (OLAC) maintained that identical subfields should be defined in both 662 and 752 fields to help with authority control functions. Alice Jacobs (NLM) however, stated that making the subfields identical in both fields may not be necessary for authority control.
Adam Schiff (ALCTS) suggested that limiting the subfields to below the planet level may not be advantageous. He also stated that although subfield $c in field 752 is for county, island area and region, it could also span across these geographic areas. Adam Schiff (ALCTS) then suggested that subfield $a be defined as the highest level in a hierarchy and subfield $b be defined as the next highest level, etc.
Adam Schiff (ALCTS) suggested that the proposed subfields $c (County, region, administrative district or islands area) and $e (City subsection) in field 662 be made repeatable. Sherman Clarke (VRA) stated that making subfield $c (County, region, administrative district or islands area) repeatable may cause problems when using descriptors from the Getty Thesaurus for Geographic Names.
John Attig (OLAC) stated that the use of repeatability is important when the hierarchy is complex. Colleen Cahill (LC) maintained, however, that making the subfields repeatable may make indexing difficult. Thom Saudargas (RUSA) suggested that the subfields in fields 662 and 752 be further analyzed to ascertain how they may be used in indexing.
Colleen Cahill (LC) stated that both 662 and 752 fields need to support different thesauri. Rich Greene (OCLC) maintained that using many thesauri may require that the subfields be made repeatable.
Thom Saudargas (RUSA) motioned to define field 662 in the MARC 21 bibliographic format, however, a new MARBI proposal should be written for the midwinter 2005 meeting that makes recommendations on the definition of subfield $2 (Source) and the expansion of the definition and change to the repeatability of subfields in fields 662 and 752. Adam Schiff (ALCTS) seconded the motion. The vote was 8-0 in favor of the proposal as amended.
Proposal 2004-06: Defining the First Indicator and New Subfields in Field 017 to Suppress Display Labels in the MARC 21 Bibliographic Format
Jackie Radebaugh (LC) introduced the paper which proposes the definition of an indicator value in field 017 (Copyright or legal deposit number) to suppress display labels when different types of copyright or legal deposit numbers are recorded in MARC 21 records. The definition of the indicator value will provide flexibility in expressing a variety of types of copyright or legal deposit numbers. The paper also proposes defining subfield $d (Date) to record the date of registration in field 017. Subfield $i should also be defined to contain the “Display text” that should be used when the new indicator position is coded with value 8 (No display constant generated).
Marg Stewart (LAC) reported that the first indicator position in field 017 has been previously defined as “Government jurisdiction.” She proposed defining the second indicator position as “Display constant controller,” instead of the first. The group agreed with Ms. Stewart’s (LAC) suggestion.
Joe Altimus (RLG) then suggested that the name of the proposed second indicator position value blank (#), “Registration or deposit number,” should include the word, “copyright.” Sally McCallum (LC) agreed. Karen Coyle (RUSA) however, reminded the group that data recorded in subfield $a (Copyright registration number) may not be necessarily related to copyright. Everett Allgood (CC:DA) agreed stating that there are probably non-U.S. users of field 017. Thus, it is important that the field continue to include legal deposit numbers.
Adam Schiff (ALCTS) reported that a period is missing from the abbreviation for “reg” in the first two examples found in the proposal. Likewise, the display text given in the third example does not match the text for value blank “#” given in section 2.2.1 of the proposal. The display text in question should read, “Copyright or deposit number.” Mr. Schiff (ALCTS) also proposed that subfield $a be defined as “Copyright or legal deposit number” to match the name of field 017. The group agreed.
Marg Stewart (LAC) remarked that subfield $i (Display text) may be difficult to index when more than one language is recorded in the field. Karen Coyle (RUSA) however, stated that subfield $i (Display text) will be coded for display purposes only. It should not be indexed.
Karen Coyle (RUSA) moved to pass the proposal with the changes proposed by Joe Altimus (RLG), Marg Stewart (LAC) and Adam Schiff (ALCTS). Thus, instead of the first indicator, the second indicator position will be defined as "Display constant controller." In the new indicator position, value blank (#) should be named "Copyright or deposit number." Subfield $a should be renamed "Copyright or legal deposit number" to match the name of field 017.
Marc Truitt (LITA) seconded the proposal. The vote was 8-0 in favor of the proposal as amended.
Proposal 2004-05: Changes Needed to Accommodate RISM Data–Music Incipits
Paul Cauthen (MLA) introduced the paper which proposes defining field 031 (Musical incipits information) in the authority and bibliographic formats to contain information needed for encoding RISM incipits.
Paul Cauthen (MLA) suggested adding subfield $3 (Materials specified) to display text about the link in subfield $u (Uniform Resource Identifier). Alternatively, Adam Schiff (ALCTS) suggested coding subfield $z (Public note) for this information. Adam Schiff (ALCTS) then asked the group whether it should also define subfield $x (Non-public note) in field 031 if subfield $z (Public note) is defined. Paul Cauthen (MLA) agreed.
Karen Coyle (RUSA) stated that subfields $x (Non-public note) and $z (Public note) are used to represent the entire 031 field, not just one subfield, such as subfield $u (URI). She suggested defining subfield $3 (Materials specified) to display text about the link in subfield $u (URI). Sally McCallum (LC) felt that subfield $y (Link text) would be more appropriate to code for this data. Karen Coyle (RUSA) however, noted that subfield $y (Link text) does not display the URI, but includes text, such as, “Click here.”
John Attig (OLAC) asked whether subfield $z (Public note) is needed since subfield $q (General note) is already defined. Karen Coyle (RUSA) however, suggested that subfield $z (Public note) could be used to display the URI and subfield $q (General note) could contain general information about incipits. Paul Cauthen (MLA) agreed stating that subfield $q (General note) is defined to contain incipit errors and other general information.
Kathy Glennan (University of Southern California) reminded the group that the link in subfield $u (URI) points to the incipit, not to the text of the score. Coding field 856 provides a link to the entire musical work. She also maintained that linking to the URI of an incipit is rare.
Gail Lewis (MicroLIF) then asked about the repeatability of subfield $u (URI). If it remains repeatable, it may be difficult to link the correct subfield $y (Link text) or $z (Public note) to subfield $u (URI). Adam Schiff (ALCTS) suggested that when needing to repeat subfield $u (URI), the entire field 031 should be repeated.
Several members of the group maintained that because subfields $g (Clef), $n (Key signature), $o (Time signature) and $m (Voice/instrument) may be coded using any code scheme, source information may be needed for each subfield. The group also suggested that source codes be defined for musical notation schemes other than the Plaine & Easie and the DARMS codes (coded in subfield $p). Paul Cauthen (MLA), however, pointed out that most of the possible subfields have already been defined in field 031 and thus adding subfields for sources may not be structurally feasible.
Sally McCallum (LC) asked about where the source of subfield $m (Voice/instrument) is coded in field 031. Paul Cauthen (MLA) responded that RISM maintains a list of codes used in subfield $m (Voice/instrument). Other agencies coding subfield $m should implement their own codes. Bill Jones (New York University) suggested coding field 040 (Cataloging source) for the source of codes in subfield $m (Voice/instrument). Mr. Jones (New York University) also asked why data in field 031 is in coded form. Paul Cauthen (MLA) responded that RISM uses coded forms of data, however, other bodies coding field 031 may choose to use textual forms.
Everett Allgood (CC:DA) also asked if subfield $2 (System code) specified the source of data found in subfields $m (Voice/instrument) and $g (Clef). Adam Schiff (ALCTS) responded no. Subfield $2 (System code) contains information about the source of the data in subfield $p (Musical notation) only.
Kathy Glennan (University of Southern California) reminded the group that field 031 has been specifically developed for the RISM community. It is not likely to be used by other bodies because field 031 contains highly specialized data. Everett Allgood (CC:DA) asked Ms. Glennan (University of Southern California) if libraries would probably maintain field 031 in records that they received on import. Kathy Glennan (University of Southern California) answered yes.
Karen Coyle moved to accept the proposal as written with the following additions: subfield $y (Link text) and subfield $z (Public note) to enhance the display of the URI coded in subfield $u (URI). Adam Schiff (ALCTS) seconded the motion. The vote was 7-1 in favor of the proposal as amended.
The following people are stepping down from MARBI following the annual 2004 meeting: Thom Saudargas (RUSA/MARBI Chair) and Mitch Turitz (ALCTS). Adam Schiff (ALCTS) will become the next chair of MARBI.
Library of Congress Report
The MADS (Metadata Authority Description Schema) draft schema is available for broad review. Based on input from prospective users, the schema will be revised and made available for experimentation. After the review period (which ends on July 16, 2004), changes will be made to MODS (Metadata Object Description Schema) to align the MADS and MODS schemas.
The second edition of Understanding MARC Authority Records is now available from the Library of Congress. Understanding MARC Authority Records introduces the MARC 21 authority format to librarians and students who are not familiar with MARC 21 authority records. Although it shares the same structural organization with its companion, Understanding MARC Bibliographic, Understanding MARC Authority Records includes comprehensive information and descriptions of MARC 21 authority records, along with many useful examples and a bibliography for further reading. It will be made available online later in 2004.
The ISBN is being expanded from 10 to 13 digits. The date for fully adopting ISBN 13 is January 1, 2007. For the interim period between 2005 and 2007, publishers are encouraged to supply both an ISBN 10 and ISBN 13 for the same manifestation based on guidelines issued by the International ISBN Agency (IIA). In response, the Library of Congress Cataloging in Publication (CIP) program will begin to accommodate ISBN 13 on October 1, 2004. To accommodate the 13-digit ISBN in MARC 21 records, one of the following two alternatives could be used. In one alternative, the 13-digit ISBN will be located in a first occurrence of field 020 subfield $a (ISBN). A repeated occurrence of subfield $a (ISBN) in the same 020 field will include the 10-digit ISBN. In the second alternative, field 020 will be repeated for each occurrence of the 10-digit and 13-digit ISBN. In this alternative, the ISBN 13 will be coded in the first occurrence of field 020.
Representatives from OCLC reported that it plans to move the 13-digit ISBN to field 024 (Other standard identifier). Representatives from RLG stated that it will be able to import repeated fields 020 subfield $a, if needed. Gail Lewis (MicroLIF) reported that MicroLIF met on this issue and prefers not to repeat subfield $a (ISBN) in field 020. Subsequently, on Sunday, June 27, Sally McCallum announced that because several venders also indicated problems with repeating subfield $a in field 020, LC will not use the technique in which subfield $a is repeated. It will repeat field 020 for each ISBN recorded.
Sunday, June 27, 2004
Discussion Paper 2004-DP04: Use of ISBNs and LCCNs in MARC 21 Bibliographic Records
Deborah Fritz (MARC of Quality) introduced the paper which discusses problems created when ISBNs or LCCNs are recorded in bibliographic records for manifestations other than the ones being cataloged. It suggests the possibility of defining a new subfield $y for “inappropriate” ISBN/LCCNs in fields 010 and 020 or expanding the definition of subfield $z (Canceled/invalid LCCN or ISBN) to allow for the recording of these numbers.
Karen Coyle (RUSA) stated that subfield $z should be coded for all invalid numbers. Rich Greene (OCLC) agreed. Bill Jones (New York University) stated that “invalid” and “inappropriate” are two different entities. He thus advocated for the use of subfield $y with inappropriate numbers. Bruce Rennie (RUSA) maintained that defining a new subfield for inappropriate numbers may cause more confusion in coding fields 010 (LCCN) and 020 (ISBN), however.
Rich Greene (OCLC) reminded the group that catalogers will continue to record ISBNs and LCCNs in different places, regardless if subfield $y is defined. Adam Schiff (ALCTS) maintained that if there were more rules available for coding subfield $z, subfield $y would not be needed in fields 010 (LCCN) and 020 (ISBN). Karen Anspach (Anspach Consulting) countered that a new subfield is needed because not all library systems index subfield $z. However, how does the group know whether systems will index the new subfield $y, if it is defined?
Gene Dickerson (NLM) reported that NLM wants more discussion to take place about how to code control numbers in fields 010 (LCCN), 016 (National bibliographic agency control number), 020 (ISBN) and 022 (ISSN) of the bibliographic format. Mr. Dickerson (NLM) maintained that there is a need for consistency in coding different control numbers in the MARC 21 formats.
A straw poll was taken of the group. 19 participants voted for option 1 (Addition of a new MARC 21 subfield to identify ISBNs and LCCNs that do not relate to the manifestation being described) and 8 people voted for option 2 (Expansion of MARC 21 field 020 subfield $z for inappropriately assigned ISBNs).
A proposal will be presented at the midwinter 2005 meeting for adding a new MARC subfield to identify ISBNs and LCCNs that do not relate to the manifestation being described.
Proposal 2004-08: Changing the MARC-8 to UCS Mapping for the Halves of Double-wide Diacritics from the Unicode/UCS Half Diacritic Characters to the Unicode/UCS Double-wide Diacritic Characters
Joan Aliprand (RLG) introduced the paper. She explained that the double-wide tilde used in Tagalog and the ligature used in Cyrillic romanization are encoded as half diacritic characters in ANSEL. In Unicode/UCS, there are two ways to represent each of these double-wide diacritics: use the appropriate double diacritic characters that span two base letters (recommended by the Unicode standard) or use the combining half mark characters (analogous to current MARC 21 practice). The paper recommends using single diacritics as is preferred by the Unicode standard.
Gary Smith (OCLC) explained that OCLC technical staff members do not favor the proposal for they believe that it is an attempt to solve a character display problem by modifying the communication character set. If this proposal passes, Gary Smith (OCLC) maintained that software used to convert between Unicode and MARC-8 must become more complex since two new characters with complex behavior will be added to the character set. According to Mr. Smith (OCLC), because the existing mappings will be retained to deal with defective or less-than-ideal combinations, six Unicode characters instead of four must be added. The current MARC-8 encoding and its Unicode equivalent solves the encoding issue. Font designers and system implementers must figure out how to display the characters. No change to the communication format is thus needed. Charles Husbands (Harvard University) agreed with Gary Smith (OCLC). He also stated that the appendix in the proposal shows how complicated the proposed changes are for implementation.
Sally McCallum (LC) reported that the Cataloging Policy and Support Office (CPSO) at the Library of Congress plans to study possible changes that could be made to the transliteration of Cyrillic to eliminate the need for the ligature altogether. Such a change will require consultation with the appropriate communities before implementation.
Charles Husbands (Harvard University) reported that there is a typo in section 2.3 of the paper. Instead of reading, “With the double diacritic the mail issue may be assuring that it is entered after the correct character in the pair,” it should read “With the double diacritic the main issue may be assuring that it is entered after the correct character in the pair.”
Adam Schiff (ALCTS) motioned to accept the proposal as amended with Charles Husbands’ editorial suggestion. Karen Coyle (RUSA) seconded the motion. The vote was 7-1 in favor of the proposal as amended.
Report Assessment of Options for Handling Full Unicode Character Encodings in MARC 21 -- Part 1: New Scripts
Sally McCallum (LC) introduced the report that presents issues related to the expansion of the MARC 21 character set repertoire to accommodate the Unicode standard.
Karen Coyle (RUSA) recommended that the move to Unicode should be a slow process. Gary Smith (OCLC) agreed. He maintained that there is currently little demand for UTF-8 encoded records. MARC-8 will continue to exist for some time in the Unicode environment.
Karen Coyle (RUSA) also commented that the report does not address indexing issues. Sally McCallum (LC) reported that Part 2 of the report covers indexing.
Joan Aliprand (RLG) asked about how the sending system will know what version of the Unicode standard the receiving system is using. She maintained that even if there was a way for the receiving system to communicate its capabilities, a sending system must maintain multiple mapping tables to tailor record export to match the particular Unicode version used by a receiving system. Joan Aliprand (RLG) introduced a simpler solution that calls for the sending system to export all of the characters that it supports and for the receiving system to accept all characters (and, ideally, preserve them), and apply its own display methodology for characters that it does not support. According to Joan Aliprand (RLG), in the MARC-8 environment, script data must be visible if it is to be modified. While it may be possible to modify a Unicode record that contains one or more legal Unicode characters that the system cannot interpret, any alteration should be done with care and in accordance with cataloging conventions. Karen Coyle (RUSA) stated that moving records to Unicode-based systems and back again to MARC-8 systems (discussed in section 2 of the report, “New Scripts and New Characters in Existing Scripts”) may cause indexing problems.
Sally McCallum (LC) reported that many systems currently deal with only Roman scripts. Joan Aliprand (RLG) maintained that Roman-only systems are incapable of handling non-Roman scripts and thus they usually either drop fields 880 (Alternate graphic representation) or store them for future use.
Sally McCallum (LC) noted that non-Roman scripts may be used in fields other than field 880 (Alternate graphic representation). John Espley (VTLS) agreed and reported that some of VTLS’s clients are inserting non-Roman scripts directly into MARC 21 fields (such as field 260 (Publication, Distribution, Etc. (Imprint))). He also reported that VTLS, Innovative Interfaces and Aleph are three systems that currently are Unicode compliant. There are others not mentioned here, however.
Sally McCallum (LC) reported that the next step after reviewing Part 1 of the report is to review and discuss Part 2. The group should then make a list of issues that MARBI may want to study and possibly form into rules. Ms. McCallum (LC) also suggested that MARBI sponsor some sort of special discussion on implementing Unicode in MARC 21 records. Joan Aliprand (RLG) reported that the slides from her presentation, “True Scripts in Library Catalogs – The Way Forward” are available for review. They are located online at: http://www.ala.org/.
Network Development and MARC Standards Office, Library of Congress