The minutes do not necessarily record the discussion
in the order in which it occurred. Material has been rearranged to increase
comprehension and to collocate
items related to specific topics for clarity. In MARBI minutes, a "vote
of the Committee" indicates a poll of those MARBI Committee members appointed
by one of the three sponsoring divisions, rather than persons of a particular
constituency who are members of the MARC Advisory Committee or other participants.
These votes are a formal representation of Committee views. The Chair rarely
votes unless to break a tie. The term "straw vote" indicates a
poll of anyone in attendance. Such votes are advisory and are not binding
upon the
Committee. Where no vote totals are recorded and a MARBI position is stated,
the position has been determined by consensus.

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.

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.

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.

Business meeting

General Information

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/.