MARBI Meeting Minutes

ALA Midwinter Conference
San Antonio, Texas -- January 20-22, 1996

MARBI Members:

Priscilla Caplan         LITA           Univ of Chicago
James E. Crooks          RASD           UC Irvine
Shelby E. Harkin         ALCTS          Univ of North Dakota
Sandra Lindberg          RASD           LaFayette Public Library
Flo Wilson               ALCTS          Vanderbilt Univ
Larry Woods              LITA           Univ of Iowa
Jacqueline Riley         RASD           Univ of Cincinnati
Paul J. Weiss            ALCTS          Nat. Lib of Medicine
Robin Wendler            LITA           Harvard University
MARBI Interns:
Josephine Crawford       ALCTS          University of Wisconsin
Carol Penka              RASD           University of Illinois
Elaine Henjum            LITA           Florida Ctr for Lib Auto
Representatives and Liaisons:
Jui-Wen Chang            RLG            Research Libraries Group
Betsy Cowart             WLN            Western Library Network
Bonnie A. Dede           SAC            Univ of Michigan
John Espley              AVIAC          VTLS
Catherine Gerhart        CC:DA          Univ of Washington
David Goldberg           NAL            NAL
Richard Greene           OCLC           OCLC
Rebecca Guenther         LC             LC, Net Dev/MSO
Michael Johnson          MicroLIF       Follett Software Co
Maureen Killeen          ISM            ISM, Inc.
Karen Little             MLA            Univ of Louisville
Sally McCallum           LC             LC, Net Dev/MSO
Susan Moore              MAGERT         Univ of Arizona
Phyllis Post             AALL           Capital Univ Law Lib
Young-Hee Queinnec       NLC            National Library of
Louise Sevold            PLA/CIS        Cuyahoga County Pub Lib
Patricia Siska           ARLIS          Frick Art Ref Lib
Rutherford Witthus       SAA            Univ of Colorado
Other attendees:
Steven R. Affleck        Retro Link, Provo, Utah
Kathy Allen              TALX Corp
Joe Altimus              RLG
Karen Anspach            DataTrek, Inc.
Kathleen Bales           Research Libraries Group
Richard Baumgarten       Johnson County Library
Mike Berger              University of California
Virginia Berringer       University of Akron
Diane Boehr              Costabile Associates
Candy Bogar              DRA
Ross Bourne              British Library
Jo Calk                  Blackwell North America
Sylvia Carson            Penn State University
Ann Case                 H.W. Wilson Co.
Marlene Chamberlain      American Library Association
Winnie Chan              University of Illinois at Urbana
Sherman Clarke           Amon Carter Museum
Karen Coyle              University of California
Robert Cunningham        NELINET
Darleen Gerace Daly      AMIGOS Bibliographic Council
Carroll Davis            Columbia University
Mollie Della Terza       Harvard University
Genevieve Engel          Univ of California
Ann Ercelawn             Vanderbilt University
Ann Fiegen               University of Arizona
Anne Flint               OhioLink
Michael Fox              Minnesota Historical Society
Ruth Haas                Harvard University
Margaret Hecker          Kentucky State University
Diane Hillmann           Cornell Law Library
Christa Hoffmann         National Lib of Medicine
Alice Jacobs             National Lib of Medicine
William W. Jones         New York University
Erik Jul                 OCLC
Arno Kastner             New York University
Joseph Kiegel            University of Washington, Seattle
Kris Kiesling            University of Texas
Lynne Kraus              SUNY/OCLC
Louisa J. Kreider        Cleveland Public Library
Eric Lamontague          DRA
Mary Larsgaard           UC Santa Barbara
Lyllian Le Quellec       DRA
Elizabeth Mangan         LC G&M
Ralph Manning            National Lib of Canada
David Murrell-Wright     National Lib of Canada
Larry N Osborne          Univ of Hawaii
Glenn Patton             OCLC
Judith Ranta             Queens Borough Public Library
Becky Ringler            UC San Diego
Stefan Roger             DataTrek (ILS)
Holly Schmidt            Blackwell North America
Jackie Shieh             University of Virginia
Ann Sitkin               Harvard Law Library
Gary Smith               OCLC
Steven J. Squires        University of North Carolina
Stuart Spore             NYU Medical Library
Gary Strawn              Northwestern University
Louise Swold             Cuyahoga County Public Library
Mitch Turitz             San Francisco State University
Tamara Weintraub         National Lib of Medicine
Susanne Warren           Art and Architecture Thesaurus
Bob Warwick              Rutgers University Libraries
Luciana Wlassics         University of Virginia
MARBI Recorder:
Josephine Crawford       University of Wisconsin
                    January 20, 1996
The meeting was opened by chair Priscilla Caplan.  After
introductions, the meeting moved on to the first item of
PROPOSAL 95-6 : "Linking Code for Reproduction Information"
Sally McCallum introduced the proposal as a substantive revision
of earlier proposals.  She discussed three general models (A, B,
and C).  By "marking" the cataloging data referring to the
microform reproduction, a local system can opt to store separate
(Model A) or merged (Model B) bibliographic records as best
internally, yet communicate separate records for the original and
reproduction as required by the utilities.  Model C is a variant
of Model B (merged bib records) with a dependent holdings record. 
The $8 link will serve as a marker needed to identify fields
pertaining to the reproduction when both the original and
reproduction are described in the same record.
At the previous meeting there was a request for order of numeric
subfields to be indicated, so the proposal proposed a
specific order for numeric subfields.  Rich Greene talked about
the serious problems OCLC has with the proposed order due to
existing records and existing software for CJK assume $6 is
always first.  Sally said that the suggested rule is derived from
current practice as indicated in the Bibliographic format. Rich
believes that the last subfield of the 533 would have to be moved
under the proposed rule.  Priscilla Caplan added that old
software always thought $a should be first, and she asked if no
preferred order is better now.  Do we want to facilitate machine
processing, human input, both, or neither?  Jui-Wen Chang agreed
that a rule-imposed subfield order could cause software problems. 
She emphasized that the most important thing is to have the
tagging.  Kathy Bales reported that the RLIN system places the $6
first when communicating CJK records to OCLC.
Rich recommends a rule for placing $6 first followed by the $7,
otherwise any order is OK.
Mitch Turitz questioned marking or flagging a 776 (Additional
Physical Form Entry) in a merged bib record, because by
definition it links back to the original record.  Diane Hillmann
believes it should not be flagged if there is only one
reproduction involved.  Catherine Gerhart reminded everyone that
it is very common to have both fiche and film and the original;
must be able to link the 533 field to the appropriate set of
reproduction fields.  Priscilla pointed out that the 007 cannot
be flagged. Sally agreed that there could be multiple 776 fields,
so need to require the $8 in these cases.
Robin Wendler and Paul Weiss discussed record exchange between
systems in terms of Model A and Model B.  Robin recommended Model
A in all cases, Paul stated that NLM has a commitment to Model B
at this time.  Sally wants to make sure that local systems don't
have display problems with Model B. Priscilla felt MARBI must
decide on either Model A or Model B for record exchange.  Diane
Hillmann emphasized explicit coding of multiple versions so that
a local system could manipulate records upon receipt.  Rich
Greene agreed with Diane.  Robin asked if OCLC will explode out a
merged record which has three reproductions and one original on
it.  The answer is no. Paul pointed out that OCLC now has records
with multiple 533s.  He sees a problem in that serial holdings
are being treated like monographic holdings; a library probably
doesn't own the whole run yet there is no way to tell this from
OCLC's database.
Priscilla asked for a straw vote from all present.  Do not code
the $8 in the 533 field if there is only one reproduction
involved.  If multiple reproductions are being described, then
the $8 is required in each 533 field.  Eighteen people voted for
this approach and sixteen voted against.
The meeting moved on to discuss the 007 issue.  Sally asked if
007s are used now?  Yes.  Paul likes imbedding the 007 in a
variable subfield (e.g. 841 $7 h).  Others felt that not being
able to include a $8 link in an 007 field is not a fatal flaw
since the "h" code would indicate microform.
Jui-Wen Chang asked what to do in preservation cases where the
original is destroyed after the reproduction is made.  Under
Model A, Sally suggested deleting the original record as well as
the 776 field on the reproduction record.  If there is a
functioning holdings system, Diane pointed out, the original bib
record could be retained with withdrawn noted in the holdings.
The discussion returned to whether or not a particular model
should be required by USMARC for the exchange of records.  Larry
Woods argued in favor of a standard Model A approach.  Diane
Hillmann discussed the complicated variations that catalogers
commonly see; she recommends negotiation between the exchange
parties on this issue.  Priscilla asked for a straw vote on the
following:  The USMARC format should NOT proscribe one model over
another, parties should negotiate.  The responsibility is placed
on the receiving system to say if it is preferred to received
separate or merged bib records.  The majority of the people in
the room voted in favor of this.
Like the 007, it will not be possible to link an 008 field to a
set of reproduction fields.  There is the possibility to use
additional 006's if multiple 533's are used.   

Priscilla suggested that a motion be made to accept Proposal 95-6 
with the requirement that Model A be used for record exchange. 
Under Model A, separate records are communicated, one for the
original and one for each reproduction.  Each reproduction record
has a GMD in the 245, an 007, a 533, and a 776 field.  Robin
Wendler made the motion (stating that some progress is better
than none) and Larry Woods seconded it.  Seven members voted in
favor, and two voted against.
Robin also made a motion dealing with the order of numeric
subfields.  The $6 subfield should come first, after that no
order is proscribed.  Paul seconded this motion.  Eight members
voted in favor and no members voted against.
PROPOSAL 96-4 : "Defining a Constituent Unit Entry Field"
Rebecca Guenther introduced this proposal, which has been
preceded by two earlier discussion papers.  There were two
proposals originally which have been merged into one because the
issues were intertwined.  Rebecca suggested that everyone turn to
page 7 where the proposal gives two alternatives for defining a
Constituent Unit Entry Field:  change the name and broaden the
use of field 770 or define field 774.  The proposal also explores
the relationships between fields 770, 772, and 773.  (It is
useful to keep in mind the difference between fields 772 and 773
as currently defined; the distinction between these fields is
whether the item described is physically independent.)
Priscilla opened the discussion by stating that improving
bibliographic relationships is a recurring issue in MARBI
discussions.  Which field for which relationship?  The discussion
moved on to discuss past uses of the 770 field.  Usage has
changed over time, according to Diane Hillmann, especially with
the implementation of the holdings format; primary use has
been for supplements though.  Young-Hee Q. reported that the 770
is used widely for supplements in Canada.
A member of the audience suggested a completely different
approach -- use the same fields with indicators to show the
up/down relationships.  Jui-Wen Chang from RLG explained why the
774 approach is preferred.  Mary Laarsgard talked about using the
772, 773, 775, and 776 for map materials.  She found that the 770
(with parent in 772) worked well because about 80% of
cartographic material has a relationship with spatial data.  The
relationship is mostly parent/child.  She also found that the 773
field is useful when several maps are on the same sheet.  She
recommends maintaining both the 772 and 773 relationship fields,
since both situations occur and the user display must be
different for access purposes.  Young-Hee reported that the
National Map Collection of Canada uses the 772 field.  It was
agreed that the 772 and 773 fields point back to the parent 
record in the same way, but that the user must be able to see the
parent information for the 773 field.
Priscilla summed up by defining 4 relationships (up, down,
physically separate, and contained within).  USMARC needs a
generic up/down linking entry, not just for serial supplements
and special issues.  Karen Coyle asked for clarification about
the bibliographic record; the 772 goes on a full bibliographic
record, correct?  Yes.  John Espley stated that he is not in
favor of making 772/773 obsolete because there are many records
in databases now with them.  Diane Hillmann asked if the
parent/child relationship is a reciprocal one or one-way? 
Priscilla felt that it is impossible to predict what is needed,
so it is best to leave room for both situations.
Karen Coyle brought up the example of journal articles with
images supplied over the network.  Even if the user does not
require the display of the host for retrieval purposes, the user
may need to know the host for a bibliography.
Priscilla recommended using the 774 field for the down
relationship and the 773 for the up relationship, regardless of
physicality and with no expectation of reciprocity.  She also
recommended leaving the 770 and 772 fields alone.  Mary agreed
with Priscilla.  Betsy, however, pointed out that the 772 display
constant must be changed.
The second indicator will be used to generate different display
constants. Given past practice, it might be good for "#" (which
stands for No information provided) to display as:
     Supplement to:
Other indicator codes could display as:
     Part of:
     Single issue of:
     Special issue of:
There was some discussion about the need for $8 linking.  This
will happen in some cases, and in one case sequencing is required
according to Rebecca. It was agreed that the $8 linking code
should be "c" for constituent entries.
Paul made a motion to accept the following USMARC changes.
     -- define the 774 Constituent Entry Field
     -- remove the physical item requirement from the 773 field
     -- clarify the 772/773 relationship
     -- Define a 2nd indicator for the 772 field:
               #    Supplement to:
               0    Parent relationship
               8    No display constant generated
     -- define $o (Other item identifier) in 76X-78X fields
     -- define $i (Display text) in 76X-78X fields
     -- define "c" code for the $8 type of linkage (Constituent   
Larry Woods seconded the motion.  Eight members voted in favor
and no members voted against.
DISCUSSION PAPER #92 : "Change in Definition of Computer File in
Leader/06 (Type of Record)"
Rebecca introduced this discussion paper by stating that the
information world has changed considerably since the plans were
first made for format integration.  Computer files are used much
more frequently now, and it seems useful to separate content from
carrier.  The idea is to narrow the definition of the Leader 06
"m" code to represent executable software only, and not any
computer file.  Priscilla suggested that the questions on page
5 be discussed in turn.
The discussion began by relating the current uses of Leader/06. 
The RLIN system uses the code for putting the record into
different databases.  The WLN system uses it for sorting and to
display the appropriate cataloger workform (each workform has
different defaults supplied).  ISM uses the code to ensure the
validity of fixed fields; also for sorting, display of the record
level, and boolean searching by format.  NLC uses it for
duplicate detection.  OCLC uses the code for matching
bibliographic records and for selecting subsets of records since
the database is not segmented.  VTLS uses the code for display of
labels and for different displays of individual tags.
Priscilla suggested that the "m" code not be used for anything
textual, such as electronic journals.  Is this a good idea?  Yes,
in the case of cartographic items.  Paul agreed that textual
computer files are a case where it is not good to separate the
rules from the format.  Catherine Gerhart asked if the Type code
should be different than the AACR2 chapter? Unknown.  Karen Coyle
expressed some concern about retaining the ability to show
"computerness" (like seriality).  Paul pointed out that there is
inconsistency now.
Sally asked if it is useful for the Leader/06 to just mean
language material?  But then, if you follow the microform model,
where do you code the executable software?  And data is another
type of computer file. Someone from the audience asked about text
with executable software -- like an electronic kit!  With Java
entering our information world, there is every expectation that
it will be hard to distinguish executable software from the data
and/or text itself.
THere was concern that the definition in the paper for computer
file as executable software was too narrow.  With the new
definition you couldn't use a computer file 006 for additional
characteristics of, for example a digital text, since it isn't

Diane suggested that we broaden the concept so that no dead ends
are created.  Priscilla suggested narrowing the definition of a
computer file so that it allows items not to be coded as computer
files.  Robin suggested we define a couple of codes for the
primary aspect, and then use the 006 for secondary
characteristics.  Paul believes users care about image, sound,
etc., but the 006 won't help managing these characteristics. 
Catherine presented a model where equal value is given to
content, physical carrier, seriality, and archivability; she
proposed a repeatable leader.
It was agreed that it is useful to put the history of a serial in
one record, yet this is contrary to current cataloging rules. 
Karen pointed out that users need and want cataloging
descriptions to be kept together even though the carrier changes. 
She supplied an example of a serial which changes from CD-ROM to
an electronic journal.

It was suggested that each constituency will need to issue

The discussion closed with an agreement to revisit this summer by
a 2nd discussion paper.
DISCUSSION PAPER #91 : "Machine Generation Flag in USMARC
Authority Records"   [not discussed on 1/20/96; see end of
session on 1/21/96]
                    January 21, 1996
PROPOSAL 96-1 : "Changes to Field 856 (Electronic Location and
Access) in the USMARC Formats"
Rebecca Guenther introduced the proposal which recommends two
changes to the 856 field as follows:
     -- Define the value 8 (Other) in the First indicator, as a
way to deal with the current redundancy in the use of subfield $2
when the access method is also recorded as part of the URL in
subfield $u.
     -- Redefine subfield $q from "File transfer mode" to "File
format type," in order to keep up with the changing FTP landscape
since so many file types now exist.
Priscilla suggested that the Committee begin by addressing the
recommendation for the first indicator. It was generally
acknowledged that redundant inputting is a problem, yet there are
intense pressures from other directions, such as the "frequent
sea changes" of the Internet. Diane Hillmann asked if catalogers
could use macros on their workstations, in order to lessen the
impact of redundant keying.  She is concerned that the 856 field
will change too frequently, unless changes are made for only
the most critical issues.
Bill asked if there is a one-to-one correspondence between the
access method in $2 and the first part of the URL in the $u. 
Rebecca thought that there is a one-to-one correspondence.
Robin asked what the future holds in store for us given the work
on URN's. Would this change be "very interim" or last for some
years?  Does the URN include access method?  Priscilla replied
that she does not think that the URN will include access method. 
Because a URN might be resolved into several different URL
addresses, there will be much to consider when this Internet
standard is approved.
Erik Jul spoke on behalf of OCLC's Intercat.  He discussed
several concerns in turn:
     1) He is concerned about the limit on the number of values
in the first indicator position.  Can we use values 1 and 2 as a
combination?  This would allow for 100 combinations.
     2) As described in the proposal, Intercat uses $2 and $u for
display purposes.  Erik likes the detailed coding in the current
856 field, where each data element has its own subfield code. 
Works more easily in a USMARC-based system.  A change would mean
some programming and also might take up more computer cycles in
processing a display.
     3) OCLC would have to deal with some kind of change to
retrospective records, or else have more convoluted display
programs.  This is not desirable at all.
     4) In regards to the one-to-one relationship between a $2
and the first part of the URL, this will not be true once OCLC's
PURL protocol is in use.  A PURL is like a cross reference to the
real URL, which will be stored at OCLC.  Example:  Using a PURL, the access method to the
object might be FTP, but a PURL will always use http.
Given this discussion, there was no support for this proposed
change.  The Committee moved on to discuss the $q proposal. 
Priscilla asked if there is a need for a more precise definition
of file format; if so, should it be in $q?  Rebecca replied that
now that the MIME standard is in common use, she saw a need when
mapping the Dublin Core elements to USMARC.  She asked if the
default for the subfield should be binary.  Although the LC
system is programmed to translate a file extension to mime type
(and can therefore distinguish between text files and various
types of binary files), would it benefit other systems to have
binary be the default?
Erik reported that the $q is not used much now in Intercat.  It
seemed reasonable to define it at the point in time it was
defined, but hasn't proved to be of much use.  Paul reminded the
group that the 856 field is used for all computer resources, not
just those on the Internet (i.e. dial-up, CD-ROMs, etc.)
Priscilla discussed the real purpose of this subfield:  to give a
user the information needed to easily transfer and use various
types of files.  She worried about file types which won't be
represented by a MIME type. Although it is possible to register
MIME types, new ones will appear on the Internet before
registration is completed, Rebecca added.  Young-Hee Queinnec
asked about the cost/benefit relationship of this proposed
change. Is it really necessary?  Might software take care of file
format type for users automatically?  Rebecca reported that an
FTP using a WWW browser does not require a user to know if a file
is ASCII or binary.  Others in the room discussed whether or not
this change would prove to be unnecessary in the long run, with
the general feeling that this was a possibility.
Paul Weiss moved that both parts of Proposal 96-1 be turned down. 
Larry Woods seconded.  Eight members voted in favor of the
PROPOSAL 96-2 : "Defining a Generic Author Field in the
Bibliographic, Authority, Classification, and Community
Information Formats"
Sally McCallum introduced the proposal.  It is a direct result of
the OCLC MetaData Workshop where the generic author field could
not be mapped into USMARC due to the USMARC emphasis on the
cataloging concepts of distinctions among names: person,
corporation, meeting.  The proposal has also been spurred on by
the interest of the National Library of Medicine.  
Paul Weiss suggested the discussion begin by asking for people's
thoughts on the RLG comments sent out on the list on 1/18/96. 
Should the proposal remove the Authority format from the list of
formats?  Yes, citation of Authority format was an error.  What
is the preferred field number, 713 or 720?  There was agreement
that the field number should be 720.  Can the definition of the
field maintain the reference to cataloging rules and authority
files?  It was agreed that the description of the field should
read "This field contains names associated with a work that are
not necessarily formulated according to cataloging rules or that
are not necessarily contained in an authority file or list."
Priscilla wondered about name form of personal names.  Should
USMARC require last name first?  Paul thought not, if the intent
is to parallel the field with current practice of the 653
(Uncontrolled Subject Terms). There was some agreement that it
would be helpful to show if an inverted name or not by the use of
a 2nd indicator.  Robin Wendler noted that distinguishing between
personal and corporate names allows a library to send records off
for authority control processing.  However, NLM has Medline
records that don't now show if a name is a personal name or other
type of name. Perhaps best for the indicator value to not be
required.  It was agreed to use the "minimalist approach" where
blank will be legal.
Rich Greene reported OCLC staff looked in depth at this proposal. 
A great idea, but late by 25 years!  Unfortunately, it will
require major development so it is likely OCLC will not be ready
when the change is released.  He gave some examples of the OCLC
programs which assume computer knowledge of type of name: 
authority programs, PRISM display programs, and indexing
programs.  In particular, OCLC staff feel it is important for
users to get to all personal names in a single index, whether
that name is present in a 100, 700, or 720 field.  Priscilla
asked if OCLC could remove the field until ready.  Yes, Rich
replied, although even removing is an expense given the large
numbers of records involved.  Rich went on to discuss another
issue -- deciding whether MetaData records should be part of the
OLUC or stored in a separate file.
Young-Hee Queinnec expressed concern that these incoming names
will not be formulated according to cataloger rules.  Although
others share the same concern, it is not realistic to expect
authors to input authoritative forms.  Paul reported that Medline
indexing uses the form exactly as it appears on the article
itself, so it may or may not be different from the authoritative
form.  RLG staff reported that they have a model in place already
where a separate index is used for this type of field.  John
Espley spoke up about local systems; there is usually a keyword
index and clients decide which fields to include in different
index types.  Someone reported that LC indexes the 653 field by
keyword in a general note index.
There seemed to be general agreement that the value of the
proposal is that it keeps the USMARC format relevant to the user
community and it allows for experimentation to deal with
authority control and other types of problems. Paul moved that
the Committee accept the proposal in the following way: 720
field, revised field definition as stated above, and Option 1
where the first indicator is not defined.  There were several
seconds but no vote, while Option 1 was compared to Option 2. 
Karen Coyle spoke up for Option 2; more information should always
be encouraged even if it cannot be required.  Paul questioned
whether the definition of value # in the first indicator should
read "Not specified" and that another value be established for
"Unknown" in addition to the values for "Personal" and "Other."  

Robin made a motion to amend the previous motion to accept Option
2 with the value # defined as Not specified.  The amendment was
seconded and the vote was 8 in favor and 0 against.
PROPOSAL 96-3 : "Changes to Personal Name First Indicator Values
in the Bibliographic, Authorities, Classification, and Community
Information Formats"
Sally McCallum introduced the proposal by discussing the MARC
reconciliation work in progress with The British Library and The
National Library of Canada.  It was discovered that UKMARC and
USMARC have the same indicator with the same values, but the
definitions are slightly different. Single surname and multiple
surname encompass slightly different groups of headings.  Rather
than undertake an expensive reconciliation between the two
countries, it seems best to make the one of the two surname
values obsolete. It does not appear that systems have programs
relying on the distinction between multiple and single surname.
Paul expressed a concern for the proposed LC policy regarding
retrospective records; LC probably would not carry out
retrospective conversion of its bibliographic or authority
records, but would maintain consistency between the indicator for
headings in authority records and bibliographic records. Paul saw
this approach as a break with how "obsolete" has been handled in
the past.  What should "obsolete" mean and should there be
consistency? Rich Greene agreed with Paul.  He stated that OCLC
has the practice of scanning the database to get rid of any
obsolete coding or data elements. Yet, OCLC must be in synch with
LC.  Priscilla stated that it is explicitly against USMARC rules
to input obsolete codes.  David Goldberg suggested that there are
some reasonable alternatives.  Alice Jacobs reported that NLM
prefers for past records to be changed, both authority and
bibliographic so that the information is kept in sync.  Since LC
does not have a linked authority file, this seems less important. 
Yet, LC distributes its authority file to systems where
synchronization is essential for smooth functioning.  And the
records pass through a utility like OCLC, so Rich Greene and
Stefan Roger (DRA) urged retrospective conversion.
Sally said the major cost for LC is converting the bibliographic
records retrospectively, not the authority records since there
are many fewer. Would just converting authority records be
acceptable?  Rich felt that OCLC could change bibliographic
records upon receipt, as long as LC took responsibility for
changing authority records all at once.  Others agreed. Robin
suggested that, if any large systems converted bibliographic
records retrospectively, that perhaps these records could be
shared with LC. Others pointed out that there would be record
matching problems to solve and that the volume might be more than
LC could handle.
Priscilla asked for more discussion on the impact of this
proposal on systems.  John Espley reported no concerns from AVIAC
members.  Maureen Killeen from ISM reported that the impact is
minimal, as long as LC redistributes changed authority records. 
Betsy Cowart from WLN reported that the WLN system does use the
value for indexing multiple surnames, and might have to reprogram
the display.  Therefore, WLN is against the proposal.  Priscilla
suggested that this becomes a smaller issue for WLN as long as LC
redistributes the authority file with the proposed changes. Betsy
agreed.  Since WLN will still have some impact on its operation,
Paul asked how in general MARBI should handle such situations. 
Priscilla explained that MARBI should always try to look at the
expense of system changes, but must weigh the severity against
the advantages.  She asked Betsy if WLN needed more time to
prepare, if the proposal passes; Sally added that implementation
should normally follow within six months after publication.   LC
will need to work out the timing with OCLC and RLG.  Betsy said
not in this case, since WLN staff expected the proposal would
pass.  Others pointed out that not passing the proposal would
cause much more work overall than passing the proposal.
Paul moved to pass the proposal.  In the first indicator of the
X00 fields, value 2 (multiple surname) will be made obsolete and
value 1 (surname) will be redefined and renamed.  Robin seconded
the motion.  Six voted in favor and no one voted against.
PROPOSAL 95-4 : "Merger of the 27X fields in the Community
Information Format"
Rebecca Guenther introduced Louise Sevold, who has come to the
MARBI meeting to represent PLA Community Information Section. 
Rebecca went on to describe Proposal 95-4 and its history.  The
original objective was to align the Bibliographic Format with the
Community Information (CI) format; as part of this process,
discussion revealed a need to tighten up coding for various types
of addresses in the CI format.  There seems to be a consensus now
to have a single address field; the field would be repeatable and
would have values in the first indicator position to show type of
Louise reported that she has spoken with various system vendors
who support the CI format.  The proposal is generally acceptable,
although a value "3" for mailing address is requested in the
first indicator in addition to the values in the proposal.  It
would be common for the same address to be used both as a primary
address and also as a mailing address, in which case the field
would be repeated with only the indicator difference.
It was asked if there has been heavy use of the two fields which
will become obsolete under this proposal, 271 and 275.  Yes,
indeed.  But, Louise added that the vendors agree to change
existing records, moving the information into the 270 field with
appropriate coding. 
It was suggested it might be better to define a 2nd indicator for
mailing address, so that it would not be necessary to input/store
the same information twice.  Louise likes this idea.  John Espley
added that some mechanism should be established for local
definition of address types.  He proposed a "7" value in the 2nd
indicator which refers to the $i for the type of address.
Stewart asked if "location" rather than "address type" might be a
better way to describe the 2nd indicator.  Some thought this was
a little too subtle.  Louise reported that users don't see the
mailing address.  It is used for mailing out requests for updates
to the information in the record.
Priscilla asked if there were any comments about $v (Hours) and
$z (Public note).  Although not mnemonic, both codes are aligned
with the bibliographic format.  Errors were noted in the $a
example on page 7. Rebecca will explore what happened and correct
as needed.
Paul moved that the proposal be approved with the following
     -- 271 and 275 fields should be deleted from the format
(rather than made obsolete).
     -- First indicator called "Level"
          #  No level specified
          0  Primary
          1  Additional (Secondary)
     -- Second indicator called "Type of Address"
          #  Not specified
          0  Mailing Address
          7  Other  (refer to $i)
A second was provided.  Eight members voted in favor, and no
members voted against the motion.
PROPOSAL 96-5 : "Enhancements to Field 007 in the Community
Information Format"
Rebecca introduced Proposal 96-5.  The main issue is defining
character position 10 in field 007 for various values relating to
handicap parking. The proposal also discusses some other issues
which came up in the various discussions, such as coding more
interpretation-related services (such as oral/voice/tactile
interpretation for the vision impaired).
Louise Sevold representing PLA Community Information Section
recommended that the 007/10 change be approved.  It would be very
helpful to service providers.  Priscilla asked if the other 007
values should be improved at this time.  Louise does not feel
that it is necessary at this time.  Paul recommended that sign
language be looked at in the near future, in consultation with
the ASCLA Deaf Section.  Rebecca reported that she has been in
contact with the deaf community to discuss the current list of
sign languages in terms of MARC language codes.  Bonnie Dede
stated that she would be happy to share information about
sophisticated telephone packages, for users who need artificial
voices or emergency back-up.  Sally thanked the Committee for
these comments, and suggested that those creating CI records
should be urged to bring forward their needs.
Discussion returned to the proposed values for parking.  The
codes mainly specify if handicap parking is available or not,
and, if handicap parking is available, whether there is high
clearance for special vehicles.  Paul wondered if the disabled
legislation specifies the clearance in feet?  If so, he suggests
that this be stated in the definition of the values.  This
seemed reasonable.
Paul moved that the proposal be approved with heights proscribed
if appropriate.  Jacqueline Riley seconded the motion.  Seven
members voted in favor and no members voted against.
PROPOSAL 96-6 : "Definition of Existing Bibliographic Data
Elements in the Community Information Format"
This proposal defines two fields in the CI format, exactly as
they were recently defined in the Bib format.  The fields are 658
(Index Term-Curriculum Objective) and 856 (Electronic Location
and Access).  Given the current emphasis on format alignment, it
is expected that the adoption of new data elements from one
format to another will become commonplace.  This proposal also
suggests a new procedure by which new data elements would be
defined by adoption, thereby avoiding the delays of the MARBI
discussion paper and proposal process.  Priscilla suggested each
part of the proposal be discussed in turn.
Louise reported that PLA was in favor of adding both fields to
the CI format.  Paul moved immediately to accept the 658 addition
to the CI format.  Jacqueline Riley provided a second.  Seven
members voted in favor and no members voted against this part of
the proposal.
There was some discussion about the 856 field.  Do the electronic
links refer to an agency or program?  How does this stack up
against the description in the CI record?  Will it make sense to
the user?  Louise felt that all will work well in actual
practice.  She felt users would be thrilled by the ability to
jump from a CI record to more detailed information on the
Internet.  Paul moved that the 856 field be added to the CI
format.  There was a second.  Eight members voted in favor and no
members voted against the motion.
There was much discussion regarding the proposed "adoption"
procedure.  It was pointed out that the procedure would only take
affect where a data element could be adopted in another format
without changes to the tag, indicators, subfield codes, or other
encoding-related aspects. Implementation would occur after a
90-day period following a technical notice to USMARC subscribers. 
Larry Woods expressed surprise that a fast-track procedure was
folded into the proposal, since it could involve other formats
than the CI format-- or will the procedure just apply to CI? 
Sally said that it was folded in because these two changes are
excellent examples of where the procedure would have been
Jui-Wen Chang, the RLG representative, spoke about whether or not
such a procedure would allow for adequate discussion and analysis
on system impact.  Rich Greene seconded this concern, although he
said that OCLC staff agreed with the need for a fast track
process in some cases.  Rich suggested another level to the
procedure:  before the technical notice on paper, send out a note
on USMARC asking for discussion on impact.  This idea was refined
even more so that more time is allowed for notice and
     a) Post a notice on the USMARC list of intent to propagate a
change across formats, with a six week period to raise a red flag
on any negative impact.
     b) Distribute an official, printed technical notice about
the propagation to USMARC subscribers with a 90-day period to
     c) Include the change in the next edition of the format.
     d) System implementation.
The discussion revolved around the use of the USMARC list.  Are
Community Information catalogers and vendors signed up?  Or, is
there a separate CI-Marc list?  Louise Sevold said that she will
take on the responsibility for getting more CI users signed up to
USMARC.  Larry wondered about the noise level of USMARC.  People
reported the activity level is not constant, it is certainly not
like Auto-Cat.  Sally said that LC is always open to suggestions
on how to better moderate the list.  Sally also emphasized that
the intent is to use the fast-track procedure in the case
of straight adoptions only (little or no system impact expected).
Paul Weiss made a motion to approve a fast-track procedure as
developed during the discussion.  Flo Wilson seconded his motion. 
Eight members voted in favor of the motion and no members voted
against it.
DISCUSSION PAPER #91 : "Machine Generation Flag in USMARC
Authority Records"
Given that there was time to spare at the end of the day's
agenda, Priscilla suggested that the Committee stay on to discuss
DP #91, a hold over from the day before.  This was agreeable.
Sally McCallum introduced the paper.  The Cooperative Cataloging
Council Series Authority Record (SAR) Task Group requests a data
element of some type to represent authority records initially
generated by machine.  The Task Group believes that this
information is important in the context of authority files where
there is a mix of human- and machine-generated records.  This
coding would help catalog managers understand the overall
nature of a particular authority file (providing in essence some
file management statistics) and help pinpoint where cross
references could be added by catalogers.  The SAR Task Group
suggested that a new code be added to the 008/33 (Level of
Establishment), although the discussion paper fleshes out several
different options.
Stefan Roger (DataTrek) spoke in support of the SAR request.  He
characterized the new data element as overdue and discussed the
need for both programs and people to be able to distinguish
easily the two types of authority records.  He detailed one
specific instance in a cataloger's workflow (overlaying) where
the code would be used actively.  Priscilla asked if the real
issue was identifying machine-generated records or identifying
where there has been no human review.  Another in the audience
felt that both would be true at times, depending upon the system
and database under use.  Stefan also discussed using this flag
for screening out machine-generated authority records which are
no longer needed.
John Espley reported that VTLS already has a local flag to show
when an authority record has been created from a bib record (it
means machine generated, not yet reviewed by a human).  The flag
changes when a person adds a cross reference.  He speculated that
most systems have something similar.
Young-Hee Queinnec believes that a USMARC data element is a nice
idea because it would stimulate more machine generation of
authority records. Might also promote uniformity between systems
which would be helpful for authority record exchange.  Priscilla
asked what now exists in the authority record format.  It appears
that current flags are internal to different systems.  Is more
necessary?  Young-Hee thinks so.  Larry Woods sees the
desirability of a USMARC code, in order to facilitate authority
record sharing as well.  He cited the possibility that the CIC
libraries might want to share cataloging work.
Paul Weiss supported adding new values to existing data elements
and emphasized the need to know when human review has occurred. 
Diane Hillmann spoke up with a clarification: keep in mind two
kinds of machine generation of authority records, heading only
and heading plus cross references. Priscilla wondered if all
incoming vendor authority records would have the same flag -- she
can think of different types of vendor records and it might be
helpful to track them with different codes.  Young-Hee suggested
thinking about more than one code too.  Gary Strawn discussed how
things are done at Northwestern University.  Priscilla suggested
the codes as helping to track a hierarchy of steps in content
evaluation of authority records.  Gary Strawn reported that the
Program for Cooperative Cataloging (PCC) is looking at three
levels of review, but does not plan to tie it to the encoding
level.  Alice Jacobs (NLM) mentioned that it is hard to track
review of authority records, due to amount of editing.  Someone
else suggested that this be built into systems, based upon
calling up a record under a specific function or editing the
record in some way.
Paul discussed his concern about using the 008/33 (Level of
Establishment). He believes the flag must relate to the whole
record, and yet the 008/33 is currently defined as relating to
the heading only.  This problem was discussed in the discussion
paper.  Paul suggested expanding the values in the 008/33.  Sally
said she saw a need for management statistics of authority files. 
Priscilla asked Gary to expand upon the PCC plan.  He spoke about
these three levels:
     Minimum Level = heading record plus a 670 field
     Middle Level = some attempt to generate references
     Top Level = most perfect form of an authority record
The PCC plan emphasizes machine behavior at all levels.
Stefan talked about generating an authority record from a bib
record; there is no 035 in the authority record.  A cataloger,
with local control, should then be able to overlay the
machine-generated local record with the LC Authority Record.
The discussion moved on to the question of retrospective
conversion of current authority files.  This will be hard to do,
except in those cases where a system has an internal flag. 
Priscilla showed concern for rational movement of records between
systems, given how definitions of machine-generation may differ
from system to system.  Sally asked if the idea for this flag is
mature within CCC.  It was agreed that it would be useful to ask
CCC for more clarification:
     -- to define machine generation to see if there are
     -- to describe how codes would be used in more detail.
Another discussion paper will probably be done once more
information can be gathered.
                    January 22, 1996
DISCUSSION PAPER #93 : "CAN/MARC Changes for Marc Format
Copies of this paper were posted and distributed in January, too
late, because of the snow in Washington, to be received by all. 
Additional copies had been passed out at an earlier meeting, so
that members had a chance only to read it in advance and not to
dicuss the paper within their institutions.  The discussion paper
details changes that the CAN/MARC users have suggested be made to
USMARC in order to facilitate alignment between USMARC, CAN/MARC,
and UKMARC. 
Sally McCallum presented some background about alignment between
versions of the format.  She reported on the December meeting in
which impact and timetables had been discussed (see January 18,
1996 USMARC-L message on MARC Harmonization Meeting).  She
emphasized that, although the format may change, in general the
content of the machine-readable records will not.  The Library of
Congress will provide overall coordination, and no one is yet
sure which MARC version will need to absorb the most conversion
work.  This is still under negotiation.
Ross Bourne, representing the British Library (BL), spoke about
the benefits of harmonization to the overall bibliographic
community.  He saw it as a natural extension of use of AACR2 in
Britain, the re-adoption of LCSH by BL, the effort to merge the
BL and NACO authority files, and the fact that UKMARC does not
include provision for special formats.  A three-year timetable
has been established so need to move along the decision-making
process relatively quickly in order to have enough implementation
time.  The British consensus is being developed via a position
paper with discussion by UKMARC users.  He expects that BL will
be willing to adopt USMARC practices unless there is a conflict
in current databases.  UKMARC activity has had a low profile in
the past, but the BL plans to change this by establishing an
email helpline, a listserv for discussion, a Web site with
information, and a UKMARC Advisory Group.
Young-Hee Queinnec, representing the National Library of Canada
(NLC), regularly attends MARBI meetings.  This is an example of
the history of cooperation with Canada on format development. 
The Canadian Committee on MARC has just completed a close
analysis of the differences between CAN/MARC and USMARC in
regards to the Bibliographic and Authority formats; results are
outlined in this discussion paper.  Young-Hee talked about the
important work of the Canadian archival community, which has only
recently been added to CAN/MARC.  Canada would have preferred to
having a little more time but is making every effort to
cooperate.  Young-Hee stated that Canada is open to negotiation
with this caution: there is a commitment to supporting the
Canadian Rules for Archival Description (RAD) in CAN/MARC.
Rutherford Witthus, representing the Society of American
Archivists (SAA), stated that the SAA has a committee on archival
exchange which has been watching the development of RAD in
Canada.  Harmonization of rules between Canadian and American
archivists is under discussion.  More time is needed.
The SAA committee has seen the RAD rules but has not yet seen
this discussion paper.  Paul Weiss wondered if there is formal
communication between SAA and the Canadian archival community. 
Rudy replied in the affirmative; there is a formal SAA
representative, Steve Hensen, who attends some Canadian meetings.
Sally suggested that MARBI discussion on USMARC and CAN/MARC
alignment first address all non-archival issues, then address
archival issues later, thereby giving the archival community more
time.  She plans to work with Young-Hee on timing.  Priscilla
asked if supporting RAD could be put off until after format
alignment is completed.  Young-Hee explained that this is not
possible due to the fact that RAD support is now part of
CAN/MARC. It was agreed to work in stages as suggested by Sally,
but some discussion of the archival issues now will be helpful.
There was quite a bit of discussion of the Canadian practice of
using fill characters in the field tag (e.g. 6__ or 65_).  Shelby
Harkin asked if this practice can occur with any field tag or
just 1xx, 6xx, and 7xx.  Not clear.  Priscilla and Sally asked if
this would remain a practice internal to Canadian libraries, or
if such records would be exchanged with American libraries. 
David Murrell-Wright reported that these records are communicated
by local Canadian libraries to NLC.  Robin reported that Harvard
now receives Canadian records from LC, processed by LC programs,
where the fill character is present.  A Harvard filtering program
converts to some arbitrary tag.  Young-Hee reported that these
records are not supposed to be distributed by NLC without
upgrading to full MARC; the fill character practice is only
supposed to support the Canadian National Union Catalog. 
There was a review of some of the data elements described in the
paper.  In many cases, it was pointed out that much needs to be
discovered about current usage.
     LDR/7 (Bibliographic Level). "Fonds" is similar to the
American concept of "collection."  Can probably reconcile
     LDR/17 (Encoding Level).  Code 3 is needed for the National
Bibliography of Canada according to Young-Hee.  An important
     LDR/18 (Descriptive Cataloging Form). Rudy reported that
both American and Canadian rules will follow the international
ISAD standard.
     007/2 (Original vs. Reproduction Aspect).  Very
controversial.  Hard to code now.  May be best to make this
obsolete, but have to see if in use in databases now.  OCLC would
like something consistent in this position; a "u" perhaps but not
a blank (#).
     009 (Cartographic Material).  Was valid in USMARC in the
past, with a totally different definition and then made obsolete. 
Young-Hee didn't know why it has been defined as a local field in
CAN/MARC, but she will find out.  She will see if it would be
possible to make it obsolete in CAN/MARC, rather than
resurrecting it in USMARC.
     028 (Publisher Number for Music).  Young-Hee asked if it was
common practice to index this field.  Most people said no, some
said yes.
     048 (Number of Musical Instruments or Voices).  Celesta is
considered a percussion, not a keyboard.  Sally suggested
changing the name, not the code.
     087 (Document Shelving Number (CODOC)).  Young-Hee reported
that this is a shelving number.  There was some discussion about
placing this number in the 086, rather than create a new field in
     260 (Imprint).  The concept of "creation" is in 245 in
USMARC.  Steve Hensen was against use of 260.  It is more than
just an editorial change.
     377+378 (Archival Description).  There is a close affinity
to the 561 (Provenance Note) field; must reconcile.  Canadian
archivists wanted a sequence of tags.  Sally thinks that systems
could display as needed by users, since it may not be possible to
have tags in order.
     542 (Location of Related Archival Materials Note).  Must
reconcile with 544 in USMARC.
     9XX (Local Fields listed in Appendix D).  Not supposed to
communicate these fields unless a limited exchange where details
are worked out between consenting exchange partners.
     $w (Special Relationship).  Young-Hee discussed how these $w
codes are used to reduce redundant bibliographic searching by
library staff.
     008/8 (Bilingual Usage).  Young-Hee suggested that other
multi-lingual countries may find these codes to be of use as a
model.  She asked if the "g" code would be used by American
Priscilla wrapped up the lengthy discussion by asking for a
review of the next steps.  Sally will redo the discussion paper,
perhaps separating out the two groupings of changes.  She will
then ask the American bibliographic community to respond about
impact issues, at least an initial review by April 15.  Then
there will be a MARBI proposal giving the American community a
second chance to comment.
DISCUSSION PAPER #94 : "Proposed changes to FTP File Label
Specifications for Electronic Files of USMARC Records"
The European library community has decided to use the USMARC FTP
file label specs, rather than inventing a separate specification. 
Some changes/improvements are under discussion.  Larry Dixon from
LC is working with the European group as well as OCLC and RLG. 
RLG responded in some depth to the discussion paper on the
USMARC-L list on January 18, 1996. Ross Bourne encouraged
discussion at this time, so that American concerns can be
discussed by his colleagues who are working on these
Proposal 2 suggests changing "end-of-field" to "new line" to work
more easily between different operating systems.  Karen Coyle
prefers the "end-of-field" character.  Perhaps carriage return is
good for Unix systems, but perhaps not for MVS systems.  Is there
something else that is not in use in another context?  In the
past, people wanted something they could see, but different
systems displayed differently (back slash, hash mark, etc.).
People seem split on this proposal, according to Sally.  She
asked for the community to take a look at the issue in more
Proposal 3 proposes adding a country identifier at the start of
the ORS (Originating System ID) field. Paul Weiss wondered how a
receiving system would know if a country code is present or not,
if it is optional.
Proposal 5 suggests adding a FQF (Format Qualifier) field to
supplement the FOR (Format) field since it is seen to be
inadequate by the Europeans.
Proposals 6-7 would enable the processing of variations in the
character set.  It was pointed out that ISO 646 is in use by the
European library community, but that there are different national
versions due to language differences.  Therefore, need to be able
to show character set variations and extensions in order to
process the FTP file.  Right now the character set is imbedded in
the USMARC record, but the possible implementation of UNICODE
makes it desirable to carry character set information in the FTP
Robin Wendler asked about the label sequence in Section 3.  Would
it be helpful to move the order around?  Sally reported that the
Europeans prefer this specific order.
Sally wrapped up by asking for final comments by the end of
Larry Woods reported on behalf of the Character Set Subcommittee. 
Much mapping work has been completed and there is a glimmer of
hope of being finished by this summer.  Larry expanded on some of
the mapping issues and promised to post a report on USMARC-L by
March.  Larry is planning on two MARBI proposals, one this summer
to discuss mapping and another next winter to discuss the
"presence" of Unicode in MARC records.
Catherine Gerhart reported that the American bibliographic
community must be prepared for a large international meeting on
cataloging rules to be held the summer of 1997.  CC:DA is
collecting issues at this time and plans to hold a forum at the
Annual Meeting.  Some possibilities for the forum are:  content
versus carrier, and merging AACR2 and USMARC.  Catherine urged
MARBI members to participate.
Sally McCallum gave an update on USMARC publications.  Everything
passed through July 1995 for Classification and Authority formats
have been published.  This spring there will be a Bibliographic
Update and a Community Information Update.  Sally and others will
be working on the Concise publication, bringing it up to date,
adding examples, and marking it up so is can be made available
over the Web.  Sally announced the Web site address
([email protected]/marc), stating that it is the easiest way to access
information about USMARC including the list archives.  Sally also
announced that March 1 is the LC system date for Phase 2 of
Format Integration.  LC catalogers will begin using on March 15,
so the community should expect FI records in the third week of
 5-29-96 jc

Go to:

Library of Congress
Library of Congress Help Desk (09/03/98)