MARBI Meeting Minutes

ALA Midwinter Conference
Washington, D.C. -- February 15-17, 1997

MARBI Members:

Josephine Crawford            ALCTS        University of Wisconsin
Elaine Henjum                 LITA         Florida Ctr for Lib Auto
Diane Hillmann                LITA         Cornell University
Carol Penka                   RUSA         University of Illinois
Jacqueline Riley, chair       RUSA         University of Cincinnati
Frank Sadowski                ALCTS        University of Rochester
Paul Weiss                    ALCTS        University of New Mexico
Robin Wendler                 LITA         Harvard University

Annamarie Erickson            RUSA         Chicago Library System
Anne Flint                    ALCTS        OhioLink

Joe Altimus                   RLG          Research Libraries Group
John Attig                    OAV          Pennsylvania State University
Sherman Clarke                VRA          New York Universities
Betsy Cowart                  WLN          Washington Library Network
Donna Cranmer                 ALCTS AV     Siouxland Libraries
Bonnie Dede                   SAC          University of Michigan
Stuart Ede                    BL           The British Library
John Espley                   AVIAC        VTLS
Catherine Gerhart             CCDA         University of Washington
David Goldberg                NAL          National Agricultural Library
Rich Greene                   OCLC         OCLC, Inc.
Rebecca Guenther              LC           Library of Congress
Michael Johnson                            MicroLIF Follett Software
Maureen Killeen               ISM          ISM Library Information
Rhonda Lawrence               AALL         UCLA Libraries
Karen Little                  MLA          University of Louisville
Sally McCallum                LC           Library of Congress
Susan Moore                   MAGERT       University of Northern Iowa
Marti Scheel                  NLM          National Library of Medicine
Ingrid Parent                 NLC          National Library of Canada
Louise Sevold                 PLA/CIS      Cuyahoga County Public Library
Patricia Siska                ARLIS        Frick Art Reference Library
Margaret Stewart              NLC          National Library of Canada
Rutherford Witthus            SAA          University of Connecticut

Jim Agenbroad                 Library of Congress
Bill Anderson                 Library of Congress
Karen Anspach                 EOS International, Inc.
Leiane Baden                  NELNET
Julianne Beall                Library of Congress
Kathy Carter                  University of Alberta
Pat Case                      FDIC Library
Lois Chan                     University of Kentucky
Gretchen Cheung               Best-Seller, Inc.
Thomas Champagne              University of Michigan
Karen Coyle                   University of California
Willy Cromwell-Kesler         Research Libraries Group
Carol Davis                   Columbia University
Bob Dowd                      Florida ?
Wendy Duff                    Canadian Committee on Archival
Ann Fiegen                    University of Arizona
Patti Fields                  Federal Lib & Info Ctr Committee; LC
Michael Fox                   Minnesota Historical Society
Aimee Glassel                 University of Wisconsin
Robert C Hall, Jr.            Concord Free Public Library
Beveryly Harris               Cobb County Public Library System
Steve Hensen                  Duke University
Jean Hirons                   Library of Congress
Wayne Jones                   MIT Libraries
William W. Jones              New York University
Kris Kiesling                 University of Texas at Austin
Gertrude Koh                  Rosary College GSLIS
Bill Landis                   University of Michigan
John Levy                     Library of Congress
Clifford Lynch                University of California
Katha D. Massey               University of Georgia
Bob Maxwell                   Brigham Young University
Hope Mayo                     Electronic Access to Medieval
David Miller                  Curry College
Joan Mitchell                 OCLC Forest Press
Anne Moore                    Northeastern University
Elizabeth O'Keefe             Pierpont Morgan Library
Cecilia Preston               Preston & Lynch
Becky Ringler                 University of California, San Diego
Karen Schneider               US EPA / Region 2 Library
Jacque-Lynne Schulman         National Library of Medicine
Jackie Shieh                  University of Virginia
Magela El-Sherbin             Ohio State University Libraries
Gary Smith                    OCLC, Inc.
Steven J. Squires             University of North Carolina                     
Victoria Stettner             Northwestern University
Barbara Story                 Library of Congress
Mary Strouse                  Unaffiliated
Jennifer Sweda                University of Pennsylvania
Vitus Tang                    Stanford University Library
Cecilia Tittemore             Dartmouth College
Mitch Turitz                  San Francisco State University
David C. Van Hoy              MIT Libraries
Susanne Warren                AAT/Getty Vocabulary Program
Valerie Weinberg              Library of Congress
Nancy Williamson              University of Toronto
Matthew W. Wise               New York University
Amanda Xu                     MIT Libraries
Abraham J. Yu                 University of California, Irvine

***************** Saturday, February 15, 1997 ******************

Jacquelene Riley, 96/97 chairperson of MARBI, opened the first of
three conference meetings at 9:30am.  There was a quick round of
introductions of Committee members, liaisons, and visitors, and
then the Committee moved on to the first proposal.

PROPOSAL 96-8 R : "CAN/MARC Changes for MARC Format Alignment"

Sally McCallum introduced Proposal 96-8R by describing a little
of its history.  In 1996, about half of the items comprising 96-8
were passed, and most of the other items were discussed in some
depth.  The archival-related items were not completely worked out
in 96-8 but have now been added in to 96-8R.  For this meeting,
96-8 has been revised.  Where there was extensive discussion and
general agreement on an option but no final vote, only that
option has been left in the revision so that the Midwinter
discussion will not recover old ground.  Similar to the 1996
practice, it was agreed to discuss and vote for each item

96-8R LDR-17: Add an "abbreviated level" code to the Encoding
Level data element.  An alternative to LDR-17 is to add an
authentication code to field 042.  Given that abbrievated level
records are less complete than minimal level records, adding
value 3 to LDR-17 would allow libraries to predict which records
could use upgrading.  Unfortunately, adding a new encoding level
has a very significant impact on systems since many programs
revolve around the Encoding Level data element.  Yet, value 3
has been in use by Canadian libraries for some time, and not
approving it would mean retrospective conversion costs to change
to the 042 field.

Paul Weiss expressed concern that Canadian libraries now use
authorized heading fields for these records, even though the
headings are not checked.  Why not use non-authorized fields, he
asked.  Margaret Stewart, representing the National Library of
Canada, responded by saying that the records reflect established
forms to the extent that such forms were available at the time
each record is created.  Another person pointed out that LC
follows the same practice in creating minimal level records.  It
was noted that the format does not have authorized and non-
authorized heading fields, although the new 720 is approximately

Betsy Cowart asked Margaret if the materials are examined
physically, because, if not, perhaps value 2 could be used
instead.  Margaret reported that the materials are examined
physically, and therefore value 2 is not appropriate. Why aren't
these materials just given minimal level cataloging?  Margaret
explained that the materials fall outside specific
collection areas, and therefore less effort is preferred.  

Rich Greene stated that OCLC prefers the 042 option because
system implementation is so much easier.  Yet, OCLC can see that
adding value 3 to the LDR has wide appeal in the bibliographic
community and may be a better course in the longterm.  He
questioned the current definition, thinking that it could be
broadened for more generic use by libraries.  It was suggested to
insert "may" in the 2nd sentence, as follows:  "Code 3 indicates
a brief record that does not meet the National Level
Bibliographic minimal level cataloging specifications.  Headings
in the records may reflect established forms to the extent that
such forms were available at the time the records were created."

Paul Weiss moved that MARBI approve value 3 in LDR-17, with the
insertion of the word "may" in the definition.  Elaine Henjum
seconded his motion. There were 7 votes in favor, one vote
against, and one abstention.

96-8R 008/39 : "Change and add Cataloging Source values"

NLC requests the addition of two new values for alignment
purposes (a value for NLC records and a value for the Canadian
Union Catalogue), and a redefinition of value c to serve more
generally for cooperative cataloging programs.  Sally McCallum
reviewed the four options that were presented in the proposal.

Paul Weiss asked whether and how this data element is used in
cataloging. Robin Wendler reported that Harvard uses the data
element in machine processing for dividing up cataloging (a
historical practice). Harvard would be happy with Option 3.

Rich Greene reported that OCLC uses the data element a lot, both
the 040 field and the 008/39.  Any change will require lots of
investigation and some programming.  In the interest of
harmonization, and because the current set-up doesn't work
particularly well, OCLC recognizes that something should be done. 
Options 1 and 2 are viewed as providing short-term value only.
Options 3 and 4 are probably about the same amount of work.

Margaret reported that NLC does not now process on this byte. 
NLC prefers Option 1 or 2, but is willing to accept Option 3 or
4.  In addition, Diane Hillmann spoke up in favor of Options 3 or
4, because Options 1 and 2 would not be helpful in collaborative
cataloging programs like Bibco. 

Sally reported that LC prefers Option 3, seeing a need to
distinguish between cataloging by a national library, cooperative
cataloging programs, and other sources.  Marti Scheel reported
that NLM prefers Option 4, if it is not possible to maintain
current codes.

Paul moved to accept Option 4, making the 008/39 obsolete.  This
was seconded by Frank Sadowsky.  There were five votes in favor,
one vote against, and two abstentions.

Later on in the same session, following the vote on the 5xx/7xx
authority fields, MARBI members began to rethink the earlier vote
for the 008/39 byte. John Espley realized that VTLS currently
codes the byte in authority records, and is then able to display
a label to show the source of an authority record.  John
recommended making the code obsolete in the bib format, but not
in the authority format.  Paul Weiss agreed with him, under the
circumstances.  Paul could see that some systems would put
authority records coming from different agencies into different
indexes.  However, Diane Hillmann liked keeping the byte parallel
between the two formats.  David Goldberg also felt that there
would be confusion if the two formats were not the same.

It was agreed to rescind the earlier vote for Option 4.  Diane
Hillmann made a motion in favor of Option 3, and this was
seconded by Robin Wendler.  Option 3 provides four "general"
codes (i.e. national bibliographic agency, cooperative cataloging
program, other, and unknown) instead of listing specific
libraries.  There were seven votes in favor, and one abstention.

96-8R 008/23-27 (Visual Materials): "Reorient Accompanying
Material Position"

Alignment between USMARC and Can/MARC raises an issue of
overlapping bytes and differing historical definitions.  If
several codes were redefined, backfiles of bibliographic records
would need to be converted in both countries if these codes are
to be useful in the future.  It is therefore recommended that
bytes 008/23-27 be made obsolete.  John Attig reported
that OLAC is in agreement with this recommendation.  Paul Weiss
moved to accept Option 3.  Diane Hillmann seconded his motion. 
There were eight votes in favor (unanimous).

96-8R 009: "Add data from Can/MARC Field 009 for Cartographic

Can/MARC field 009 provided physical description data beyond the
007 field.  Canadian and US map librarians considered the field,
noted the redundancy of part of 009 to USMARC, and came to the
recommendation that three values should be added to USMARC:
      Map 007/04 (Physical medium)
      Map 007/06 (Production/reproduction details)
      Map 008/25 (Type of cartographic material).  
In addition, data elements relating to remote sensing images
(RSI) are needed and are being considered in a new 007 field in a
later proposal.

There was some discussion about cataloging maps that arrive in
different forms, such as two maps on a single sheet of paper,
maps bound in a book, and maps that used to be bound in a book
but have been removed. Susan Moore explained that it is best to
keep maps flat.  Paul questioned the need for byte 25, but map
catalogers see this as very important.

Susan Moore requested that "mylar" be removed from the revised
description of code e in Map 007/04.  Because Mylar is a
trademark, it is better to define as "transparant polyester

Elaine Henjum moved to accept the additional codes.  Diane
Hillmann provided a second.  There were seven votes in favor, and
one abstention.

96-8R 016: "Add field 016 for NLC Control Number"

The National Library of Canada control number is similar to LC's
number in field 010.  The NLC control number is used as the
citation number in Canadiana.  The proposal recommends broadening
the 016 number so that it could be used by any national
bibliographic agency, but to let NLC use the # indicator, to cut
down on the amount of retrospective conversion work by Canadian

Joe Altimus asked about the relationship of the 003 field to the
010 field.  Sally reported that there is no official relationship
in USMARC.  The 003 field specifies the USMARC code for the
agency whose system number is present in field 001.

Paul Weiss suggested that there be two additions to the proposal. 
Add "Other" to the name of the field, since LC will continue
using the 010 field.  And, add "invalid numbers" to $z.  Frank
Sadowski, Sherman Clarke, and Margaret Stewart spoke up in
support of Paul's suggestions.

Marti reported that NLM is seriously considering using this
field; right now, the NLM number ends up in the OCLC 069 field.
NLM would want a special code.  John Espley expressed a concern
that every national library would want a special code.

Paul Weiss moved that the proposal be accepted with the two
additions introduced earlier (add "other" to definition and
"invalid" for $z). Robin Wendler seconded his motion.  There were
eight votes in favor and no votes against.  It was also agreed
that LC staff will attempt to show more contrast in the

96-8R 085 : "Add new field for Document Shelving Number"

Canada requests a new field to carry the CODOC shelving number
that is assigned to Canadian federal and provincial government
documents.  One option is to define the 085 field for this
purpose.  Another option is to use field 084 (Other Call Number)
for CODOC numbers with the number system indicated in Subfield
$2.  Diane Hillmann spoke up in favor of field 084. She made a
motion to accept the $2 code "cacodoc".  Paul Weiss provided a
second.  There were eight votes in favor, and no votes against.

96-8R 9XX: "Add fields in the 9XX Range"

Can/MARC has 14 valid fields in the 9XX range based upon a
government mandate to provide cataloging in two official
languages.  These fields are used for equivalent names and
cross-references.  American libraries may use the same 9XX fields
in other ways, since this range is for local adaptation. NLC
would like an appendix added to the USMARC documentation listing
the NLC 9XX fields; NLC would be responsible for updating this
appendix.  An alternate idea is to establish 9XX lists on the
USMARC Web pages, showing 9XX use by utilities, vendor systems,
local libraries, etc.

John Attig asked if NLC considers these fields to be "extensions"
to USMARC.  He noted that the issue is presented as one of
documentation, yet there are system compatibility issues to
solve.  He wondered if systems are expected to not support,
unless necessary for Canadian customers.  He also pointed out
that authority control internationally would benefit from
establishing a better mechanism.  NLC is to be commended for
doing a good thing with the only available mechanism at the time.

Diane Hillmann and Paul Weiss supported the Web site idea,
because they felt an appendix just for NLC is hard to justify. 
Margaret stated that NLC intends to streamline and cut down the
appendix to a small size. Sally McCallum thought that the
introduction to the appendix could clearly explain that use of
the Canadian 9xx fields was domain-specific.  Diane believed that
inclusion in USMARC brings a certain authoritative weight with
it, that vendors would think that they have to support it to be
USMARC compliant.  Margaret replied that, after harmonization,
the format should be international in scope, and this appendix
supports that concept.  Robin Wendler believed that all 9xx
fields should be treated equally.

Rich Greene saw the problem larger than the documentation issue. 
Since NLC is using 9xx fields for bibliographic control purposes,
he suggested converting the 9xx fields to 886 fields (Foreign
MARC Information Field) when shipping to US systems. To American
systems this is "local" Canadian data, but not to Canadian

Sally brought the discussion back to the documentation focus. 
John Espley supported her, thinking that this should be treated
as a minor issue only and that supporting an international aspect
to the format is a good idea. Bonnie Dede said that NLC is in
essence asking for a separate print job on colored paper.  To her
mind, it raises a question of fairness and common sense. Margaret
responded that the Canadians just don't consider these fields to
be local.  Marti Scheel suggested that perhaps a couple of other
major implementations of 9xx could be listed in the same 
Appendix (i.e. OCLC, RLIN, etc.). Could her suggestion be a

Speaking from the perspective of a local systems vendor, Karen
Anspach stated that the presence of the Canadian 9xx fields would
raise questions of system support.  Should these fields be
loaded?  Should cross references and/or linkages be made?  Paul
said that this kind of proves Diane's point.  John Espley stated
that the appendix could clearly state who is responsible for
supporting these fields and who is going to maintain them.

Frank Sadowski asked for a straw poll in support of Option 2 (NLC
publishing the local 9XX fields in customer documentation). 
Others wanted to do a straw vote on the Web site registration
idea.  Paul Weiss wondered if this was a policy issue requiring a
MARBI vote, or if it ought to be up to the LC staff.  Diane
Hillmann felt that there should be a vote.

It was agreed that the NLC staff would think overnight about the
strong opinions expressed in the discussion.

96-8R 008/08 (Authority) : "Define Bilingual Usage Position"

Margaret Stewart opened the proposal by explaining that NLC
provides cataloging information in Canada's two official
languages.  Can/MARC contains five codes for showing if headings
can be used in an English catalog, a French catalog, or both. 
NLC creates two authority records when a heading is available in
its equivalent or translated form. Canadian local systems accept
one authority record or the other, depending upon the language of
the local catalog.  The 008/08 codes are used for doing this.

The proposal has two options.  Option 1 adopts the Can/MARC codes
in the 008/08 byte and would allow Canadian libraries to continue
in the same way as now.  Option 2 adds the 008/08 codes and also
establishes an 038 Language of Catalog code, so that countries
with other languages could process headings appropriately. There
are two 038 subfields, one to list languages for which a heading
is valid, and the other to list languages where the heading is
not valid.  Switzerland and some other countries might use the
038 field, according to John Espley.
John Attig asked if Canada could convert to using the 038, rather
than continue using the 008.  Margaret explained that this would
be a major change, and that these codes are used so frequently,
it is better for them to be in a fixed field at the front of the

 John Attig went on to say that it is not clear if either the
008/08 byte or the 038 field will fit the future.  Much work
needs to be done in the area of multiple language authority
control.  For instance, should there be two authority records
(current Canadian practice) or is it better to create just one
authority record?   Given these unknowns, he suggested we support
present need now.  Frank Sydowski agreed with John Attig.  Sally
McCallum emphasized that both options allow Canadian libraries to
grandfather in current records.  Robin Wendler agreed, believing
that the 008/08 byte can be defined for the English/French need. 
Paul Weiss spoke up with concern though -- Option 2 breaks the
USMARC principle that there is only one location for each defined
type of data.  However, dealing efficiently with current Canadian
databases is an important concern. Karen Anspach encouraged MARBI
to pass Option 2 since EOS International has one customer with
four national languages.

 Paul Weiss made a motion in favor of Option 2.  Robin Wendler
provided a second.  There were eight votes in favor, and no votes

96-8R 008/11 (Authority) : "Define new Subject heading system

It is proposed to add a code "s" for the Sears List of Subject
Headings. Sally McCallum reported that she has been in touch with
the Wilson Co. and a code for Sears would be useful.  John Espley
asked if there had ever been a USMARC code for the Sears list in
the Bibliographic format.  Rich Greene said there is a USMARC
code for Sears as a subject source and OCLC users put that code
in a $2.

Diane Hillmann made a motion to add the code "s" to 008/11. Paul
Weiss made a second.  There were eight votes in favor and no
votes against.

96-8R 008/055 (Authority) : "Define field for NLC series call

If a record is for a series, the call # for the series is put
into the 050, 060, 070, 082, and 086 fields. Can/MARC uses the
055 field.  While many of the NLC class schedules are like the
LCC schedules, they are different in the area of Canadian
literature and history.  Hence, NLC recommends adding the 055
field to USMARC.

Paul Weiss asked who assigns this call number.  Margaret Stewart
reported that it is used throughout Canada, not just by NLC.  NLC
assigns call numbers, either using the LCC schedules or one of
the NLC extensions. Marti Scheel reported that NLM has the same
situation, maintaining the LC medical schedule as well as an

John Espley asked about other national libraries.  Will they each
need a series call number field dedicated to their call numbers?
Rich Greene shared John's concern that it could get out of hand
-- although, the current proposal meets Canada's need, and keeps
the bib and authority formats in parallel with one another.  Rich
suggested that a broader scheme be devised if more national
libraries request a dedicated field.

Paul Weiss moved to accept the proposal.  Elaine Henjum provided
a second. There were eight votes in favor, and no votes against. 

96-8R 008/5XX, 7XX (Authority) : "Define subfield for Record
control number"

It is proposed to add a record control number subfield to the
Authority Format 5XX and 7XX fields, since Can/MARC has one
defined and it is potentially useful when a system creates
references for a headings display.  NLC was using $3, but USMARC
consistently uses this subfield for "Materials specified" in the
Bib and other formats.  USMARC used to use $v for a record
control number in the 7XX fields, but then changed to $u. Canada
has agreed to change from the $3 to a numeric subfield in both
fields, but doesn't want to use $u.  The proposal therefore
recommends $0 [zero].

Betsy Cowart asked if $0 has ever been used before.  No.  Because
it is difficult to distinguish $0 [zero] from $O [letter O], she
requested that [zero] in brackets be used in the documentation.

Paul Weiss moved to approve the proposal, with the added ruling
that the $u in the 7xx fields be deleted.  Both Robin Wendler and
Diane Hillmann provided a second. There were seven votes in favor
and one vote against.

Someone asked whether or not this change would be applied across
the format, or would only apply to the 5xx and 7xx authority
fields.  Sally responded that it was only approved in this single
case.  However, the USMARC staff would try to use the $0 [zero]
in the future where a record control number is to be added.


The Character Sets Subcommittee will be holding a meeting on
Sunday, from 12noon-2pm, in the VTLS Suite.

Sally reported that a new language code list went to the printer
in December.  There are 29 new codes, aligning USMARC with NISO
and ISO.  Paul Weiss asked why there is only one code for sign
language, even though there are many sign languages.  Rebecca
reported that she met with the Gallaudet representatives.  There
is agreement to have a single "group" code;  Gallaudet worked out
guidelines on how to apply this code.

The Web concise version of all 5 formats is now available. 
Examples have been added.  It is OK to download and use.  A print
version will be available later.  In March 1997, the USMARC
office plans to issue Bib Update #3, Holdings Update #3 [delayed
until Sept.], and Authority Update #2; will include approved
changes from the D.C. meeting.

A question was asked about 2000-year work on the LC Control
Number. Apparently, there were only a few cataloging records for
the years 1898 and 1899.  Therefore LC plans to begin with a
4-digit year in the LC Control Number in the year 2000.  What
about name authority records?  Same approach.  More questions
were asked.  Sally agreed to put up a summary of the work done to
date on the USMARC Web pages.

Sally went on to talk about the DTD.  It is now available by FTP. 
Sally is looking for funds to support creating a converter.  

John Attig spoke up about a coordination problem where there is a
coding difference between the bib and authority formats, due to a
recently passed proposal.   Should MARBI consider this problem
generically?  Sally reminded the group that nothing should be
implemented until six months after a proposal is passed.  The
print version is the official version. The electronic version is
not changed until the print version has come out.

Robin Wendler reported on some work on a cooperative testbed by
the National Digital Library Federation.  There has been some
discussion about the need for expressing hierarchical
relationships, as users navigate among objects within a
collection.  USMARC doesn't do very well in relation to
hierarchical relationships.  She asked MARBI members to think
about this. 

There was some discussion on the USMARC list about non-filing
indicators again.  Should there be another discussion paper? 
Perhaps new technologies might be useful?  Robin believes
worldwide usage is an impetus.  Sally reported that the ISO
standard for a bibliographic control set uses control characters,
but some USMARC users and uses have problems with control
characters.  She thinks it would be useful to flesh out the
issues, and also look at implementation issues.  Maureen Killeen
reported that the ISM system has 8 indicator positions
internally, although most are not used.  But ISM would use for
non-filing indicators even if not in USMARC.  There was an
agreement to move forward with a discussion paper.

There was also a suggestion to create a discussion paper on
holdings type information, for example in the 541 field.  Perhaps
this information would be better placed in the Holdings Format. 
It was agreed to do a discussion paper.

Catherine Gerhart brought a proposal from CC:DA to hold a joint
meeting with MARBI in San Francisco.  CC:DA would like to discuss
Metadata, content/carrier issues, TEI, etc.  Monday morning
seemed like a good time, because it would follow the Sunday
program on the Dublin Core.  Rebecca Guenther, Cliff Lynch, and
Stu Weibel will be speaking at this Sunday program.  

****************** Sunday, February 16, 1997*******************

DISCUSSION PAPER # 99 : "Metadata, Dublin Core, and USMARC: a
review of current efforts"

Rebecca Guenther introduced DP99 which discusses developing
standards for a simple description record for Internet resources. 
There have been three international workshops to date (Dublin,
Ohio in March 1995, Coventry, UK in April 1996, and Dublin, Ohio
in September 1996) and LC staff prepared DP86 after the first
workshop.  DP99 has been provided to keep the Committee abreast
with recent developments.  The list of Dublin Core data elements
has been increased from 13 to 15, and there have been some small
changes in the description of the elements.  DP99 includes a new
mapping from the Dublin Core elements to USMARC.

Stu Weibel reported that there had been a very animated exchange
after the recent workshop on the listserv.  It is not expected
that the data elements will change.  D-Lib, a magazine of digital
library research, has an article in its January issue describing
the Dublin 1996 Workshop on Image Metadata.  An Internet Request
for Comments (RFC) has just been completed, to communicate work
to date to the Internet community.  The RFC describes the 15 data
elements comprising the Dublin Core, and shows a convention on
how to embed in an HTML file.  Stu feels that this is really
important, so that people get started now and we can learn from
the experience.  A fourth Workshop is planned for Canberra,
Australia in March 1997 to work on implementation issues like
what to do with the Dublin Core and how to add subject headings.
A second RFC will be completed afterwards.

There was some discussion about the purpose of metadata packages
and containers. In the Warwick Framework, a package is an object
with a specific type of metadata.  The metadata may be embedded
with the object described or may exist separately and have a
link.  There may be a MARC container in the future, as well as
many others.  Stu went on to discuss the Platform for Internet
Content Selection (PICS) which is a content-rating infrastructure
where labels can be associated with content.  It is believed that
Microsoft and Netscape and other companies building Internet
browsers will include the mechanisms to support metadata and
metadata conceptual containers within PICS.

In terms of the mapping, Rebecca looked for one place to put each
Dublin Core data element in USMARC. This was hard to do since the
content of each Dublin Core element is not well known at this
time.  For example, number 11 is SOURCE, defined as "The work,
either print or electronic, from which this resource is derived,
if applicable."  Rebecca expects preliminary usage and ongoing
discussion to finetune the definition.  If there are questions or
comments about the discussion paper or the mapping , please send
them to Rebecca.

PROPOSAL 96-8/520 : "New Indicator Value for Field 520 (Summary,
Etc. Note)"

Sally McCallum briefly introduced the proposal, which will allow
archivists to label a special type of summary that appears in
cataloging records.  The proposal specifies adding an indicator 2
for "Scope and content" and modifying the name of the field and
subfields slightly to account for the practice of archivists. 
RLG recently asked for an indicator 3 for abstracts to be added
to the proposal.

Paul Weiss questioned dropping the word note from the field and
subfield names since 5xx fields are note fields. He asked why the
archivists want to do this, and what the consequences would be. 
Robin Wendler wondered about the functional difference, and if
one should then assume that all 5xx fields should have the "note"
label dropped.  Wendy Duff (Canadian Committee on Archival
Description) explained that the word note has a different meaning
to archivists and that the use of it in the field/subfield names
causes confusion. John Attig pointed out that AACR2 has a
definition for a note, but that USMARC works along the lines that
as long as the text is found in a 5xx field it is a note.  Steve
Hensen, representing the American archival community, picked up
on Wendy's point. The information placed in this field by
archivists is very critical information, describing scope and
content.  It is much more important than a note, even though the
text is structured like a note.

Sally was able to offer some history on the 5xx fields.
Originally, the 5xx field names didn't always say note.  At one
point, there was an effort to standardize by adding note to each
field name.  To help the archival community utilize USMARC to its
fullest, she recommends dropping the word note.  Rebecca pointed
out that the RAD rules state that this field should only be used
for scope/content by archivists, but that others may use the

Paul was still not convinced, finding that catalogers are
confused when there is inconsistency in the format.  Robin did
not think that a field label limits its use necessarily.  Wendy
Duff urged MARBI members to support a broad use of the format,
encompassing different materials and ways of cataloging.  Sally
agreed, stating that it is a USMARC convention to accommodate
many sets of cataloging rules.

Frank Sadowski moved to approve the proposal with the exception
of the 2nd bullet (i.e. do not remove note from the field name).
Indicator value 3 for Abstracts should also be approved. Sally
asked if there was any discussion on the display constant for
value 3. Joe Altimus and Diane Hillmann spoke up about the need
for indicator value 3.  Marti Scheel reported that NLM will use
it, if it is approved.  It was agreed that "Abstracts" should be
used as the display constant.  Robin Wendler provided a second. 
Paul spoke again against the motion.  He didn't want the word
note to be removed from the subfields either.  He didn't want
title/subfields to be treated differently.  Robin thought that
the entire field constitutes a note. Frank thought that if the
title of the field has the "note" word, one can assume the
subfields are part of a note. Jacquelene called for a vote. There
were three votes in favor, four votes against, and one

Paul Weiss moved surprisingly to accept the proposal as written,
with the addition of value 3 for Abstracts.  Elaine Henjum made
the second.  There were five votes in favor, no votes against,
and two abstentions.

PROPOSAL 96-8/542 : "New field 542 for location of related
archival materials"

This is a field pointing to another collection of archival
materials, where there is some relationship to the collection
being described in the MARC record.  Canadian archivists would
like to distinguish between materials with the same provenance
residing in a different repository (associated-- new field 542)
and materials with a different provenance but shared sphere of
activity (related -- field 544).  Joe Altimus questioned the need
for a new field, since the distinction is a fine one.  He  
suggested indicator values instead, and also pointed out that the
544 field is in use and already has some "associated" entries. 
Rich Greene agreed, and also recommended indicator values.  Rich
thought that it would be confusing to have the same subfields in
use in both fields, and that the different field names would not
be particularly useful in helping people keep the fields separate
in their minds.

Wendy Duff explained that the principle is to describe all
material of the same provenance in the same description.  In some
cases, papers transfer from one organization to another;
archivists use a narrative note to explain. In other cases, the
person deposits papers in two depositories, and archivists cannot
use the same note.  Paul understood this distinction, and said
that a MARBI principle is to not criticize cataloging rules and
established practices. He suggested using the 544 field and
establishing indicators for the two types of notes.  Steve Hensen
pointed out that the RAD rules make the distinction very clear
and elegant.  Two separate notes warrant two separate fields to
his mind. Diane Hillmann stated that there is no argument on the
need for two separate notes, just how to code.  It is very
important for MARBI to save field tags wherever possible.  Wendy
added that it is sometimes necessary to record both types of
fields at the same time.  But since a field can be made
repeatable, indicator values became acceptable to the archivists
at the table as they thought about it.  Paul gave the example of
the 024 field, where two different numbers (ISCR or UPC) can be
listed, distinguished by indicator value.

Agreeing to use the 544 field, it was then necessary to change
its name, add indicator values, and change the names of some of
the subfield names.  There was some discussion about the Related
Material Note. It should be $n and it should come before the
other subfields.  It was agreed to simplify the name of $n to

A motion was made as follows:
-- Change the name of Field 544 to "Location of Other Archival
Materials Note"
-- Define the first indicator as Relationship with two values: 
1) Associated Materials and 2) Related Materials)
-- Add the $n Note subfield
-- Change name of $d to "Title"
-- Change name of $e to "Provenance"

Diane Hillmann provided a second.  There were eight votes in
favor and no votes against.

PROPOSAL 96-8/545 : "New indicator for field 545 (Biographical or
Historical Note)"

Archivists want to distinguish between biographical sketches of
persons or families and administrative histories of corporate
bodies placed in the 545 field.  The proposal recommends defining
three values in the first indicator position, and changing
slightly the name of the field and a couple of subfields (get rid
of "note" like above).

Paul asked if a practical reason for the proposal was so that
different displays could be generated.  Wendy Duff replied in the
affirmative. Steve Hensen said that the primary consideration is
to be able to index and manipulate the two types of data

John Attig then wondered if the proposal should include display
constants, and an indicator 8 for when no display constant is
desired or appropriate. Sally was not sure that this was
necessary at this point.  John Espley asked for verification that
display constants are only recommended, and not a required part
of the standard.  Sally verified that this is correct.

Wanting to drop "note" from the description of the field, it was
agreed to change this word to "data."  It was agreed to do the
same with the name of $a.  It was agreed to make $b obsolete. 
The three values of Indicator 1 were acceptable.

The proposal was moved and seconded, with no changes.  There were
seven votes in favor, and no votes against.  (One committee
member had left the room and did not vote).

PROPOSAL 96-8/561 : "Changes to field 561 (Provenance)"
 The archival community proposes changing the name of the field
to "Custodial History", to better represent the use of the field
according to both the APPM and RAD cataloging rules, and to make
$b (Time of Collation) obsolete, since archivists have found it
is better to include the date information as part of the $a text. 

Wendy Duff explained the importance of provenance vs. custodial
care to archivists.  Archivists define the difference between the
two as: 
- provenance (the person or organization who created, collected,
used, or  otherwise defined the collection of materials) 
- custodial care (the person or organization that is maintaining
or has  maintained the collection, but doesn't add to or change
the collection).  

Steve Hensen reported that archivists currently use this field
for custodial history data, so there are no conversion issues. 
John Attig asked if $b is currently in use.  Steve did not think

Sherman Clarke reported that the Visual Resources Association is
at an early stage in defining its use of the USMARC format, but
there may be a request in the future for a provenance field. 
There was discussion about how the art history and archival
communities define and use the term provenance differently. 
Elizabeth O'Keefe reported that the Morgan Library uses the 561
for all the previous owners of a collection, whether the original
creator/owner or a later custodian.  Steve stated  that there are
custodial aspects to the use of the term provenance within the
art history community.  He thought it might work for both
communities to use the field, as long as there wasn't confusion
about the terminology. Wendy was concerned.  She believes that
the art history community defines provenance from the point of
view of documenting change in ownership for an art object.  The
archival community does not want the creator to be put into the
561 field, as it belongs in the 1xx.  

Paul Weiss moved to approve the proposal.  Josephine Crawford
provided a second.  The chair asked if there was further
discussion.  Diane Hillmann expressed a concern with moving ahead
with the proposal, if there might be some remaining need to put
"provenance" in a 5xx field.  She proposed expanding the use of
the field, rather than changing it.  Robin suggested that if the
field is just used by archivists to date and VRA is not yet ready
to propose something, couldn't the field be expanded later on?
Sherman felt that this would be ok.  

But, given use of the 561 field by the Morgan Library, there is
some chance that others are recording provenance/creator data in
the field at this time.  Elizabeth O'Keefe suggested a "wobbly"
field, one that satisfies both needs.  Steve pointed out that the
archival community is quite large and prefers "custodial history"
in the name.  Wendy proposed the name "History of Ownership and
Custody."  Others liked this.  The terms overlap but are used
differently by different communities.  The field description can
explain a little about the different interpretations by the
different user communities.  

Paul Weiss withdrew his motion.  Diane Hillmann made a motion to
change the name of the 561 to "History of Ownership and Custody,"
to change $a in the same way, and to make $b obsolete.  Paul
provided a second.  There were eight votes in favor and no votes

PROPOSAL 96-8/040 (Authority) : "Add subfield for rules to field

The 008/10 is a single byte for coding the descriptive cataloging
rules used in the bibliographic description.  In addition to
codes for AACR, AACR2, and before AACR, there is a "z" code for
other but there is no place to specify what the other code is. 
Parallel to 008/10 is 008/11 for subject heading system, and
008/11 points to 040 $f when encoded with the "z" value.  The
proposed change is to add a Description Convention Subfield ($e)
to the 040 field, to which 008/10 "z" would point.  

Paul Weiss moved to accept the proposal with no changes.  Robin
provided a second.  There was no discussion.  There were eight
votes in favor and no votes against the proposal.   

PROPOSAL 96-8/$w/0-t (Authority) : "Add Control Subfield code for
Immediate Parent"   

The archival community would like to add another value to the $w
codes in the Authority 4xx and 5xx fields.  The $w/0 byte
provides  heading-specific details about special relationships,
to assist in the use of a field. The proposed code is "t" for
Immediate Parent Body, for names  of the parent body of firms
entered in the 110.  This code would be used for corporate bodies

It was pointed out that the example is wrong in the proposal.  It
should read 110 (not 100) and 510 (not 500).  

Diane Hillmann recommended that the USMARC documentation provide
detailed instructions and definitions of terms like "parent"
since the terminology and use is complex.  

Sherman Clarke expressed some concern about the proposed code
since standard NACO practice would not create this kind of
reference.  Diane could see why this reference is particularly
useful to the archival community.  Paul could see usefulness to
the broader bibliographic community, as a mechanism for linking
parent/child that would be more flexible than cross references. 
He felt that the NACO documentation should provide the detailed
explanation, rather than the USMARC documentation.  John Espley
also thought the code is a useful addition to the format, and
preferred detailed information in USMARC.  He wondered about the
display label; is Parent Body ok?  He pointed out that vendors
work more effectively with guidance built into the USMARC format. 
It was agreed to add Body to the name of the code.  

Diane Hillmann moved to pass the proposal with the change of the
name of value "t" to "Immediate parent body."  Robin Wendler
provided a second. There were seven votes in favor, no votes
against, and one abstention.   

PROPOSAL 96-8/678 (Authority) : "New indicator and subfield for
field 678 (Epitome)"  

Candian archivists also want to include biographical sketches of
persons and administrative histories of corporate bodies in
authority records and to distinguish between the two types of
data.  It makes sense for the field to parallel 545 (Biographical
or Historical Data) in the bib format. Authority Field 678 was
defined to contain biographical, historical, and other
information about the 1xx heading.  It can be expanded to meet
the needs of the archival community.  Specifically: 
- Add an indicator 1, with three codes (no info, biographical
sketch, and administrative history). 
- Add a $b called Expansion. 
- Change the name of the field to "Biographical or Historical
- Change the name of subfield $a to "Biographical or Historical

Diane Hillmann spoke in favor of the proposal.  No one spoke up
against the proposal.  Diane moved to accept the proposed changes
to field 678. Paul provided a second. The chair asked for further
discussion.  There was none.  There were eight votes in favor,
and no votes against.   

PROPOSAL 97-1: "Definition of Second Indicator (Relationship to
Source) in Field 856"  

Rebecca Guenther introduced this proposal.  The main part of the
proposal is to define a second indicator to show the relationship
of the electronic resource listed in 856 to the entity described
in the cataloging record. There would be five values in the 2nd
indicator, each showing the different types of links that are now
made.  Rebecca has identified a number of variations, such as
electronic location of resource itself, electronic location of
online version of resource, electronic location of a subset of
resource, etc.  Not only can the 2nd indicator be used to supply
display constants on OPAC screens, but it could also be used to
order multiple 856 fields in the same record.  

The second part of the  proposal suggests adding a value 4 for
HTTP access method to the first indicator, since the World Wide
Web is so predominant at this time.  Rebecca does not recommend
creating values for all access methods, but HTTP is so important,
its addition will save catalogers from having to create a $2 in
many, many 856 fields.  

Jean Hirons, representing CONSER, spoke up in favor of the
proposal.  The practice is to add an 856 to the record of the
original serial, because there are so many related resources. 
The 2nd indicator would help organize and differentiate between
multiple 856 fields.  

John Attig spoke up in favor of the RLG recommendation to use the
display constant "Resource Availability" rather than what is
proposed.  Frank Sadowski prefers the display constants in the
proposal, thinking they are very clear.  However, it was pointed
out that display constants are only recommended.  

Frank asked for an explanation about how $3 fits in.  Rebecca
said to look at Example 2, where the record describes the
original but only the table of contents is digitized at this
time.  Therefore, the $3 states what the URL represents.  Diane
questioned using 2nd indicator, value 1 in Example 2, but she
wasn't sure what she would use in its place.  She pointed out
that there can be different tables of contents on the Internet
for the same resource.  

Paul Weiss questioned Example 3.  He doesn't believe that a
finding aid is a subset of a resource.  Rebecca said that when $3
was originally proposed, MARBI thought the finding aid example an
appropriate use of it.    

John Espley reported that VTLS libraries are putting in a lot of
856 fields, for audio links or scanned images of dust jackets. 
Rebecca asked what type of 856 they would be considered.  Jean
Hirons reported that these uses were discussed when formulating
the CONSER guidelines. In these two examples, the links are
usually not integral to the bibliograpic description, so are
considered a related resource.  

Robin Wendler reported that Harvard Music Library considers the
thematic description to be part of the bibliographic description,
not separate. Catherine said that if you are describing printed
music, you then have a related link to the audio.  Paul said that
there is a distinction, but only some users will care about it.  

Robin continued on to say that the original purpose of this field
was to put in a link that matched the item being described.  She
questioned the description about DP87 in the background section
of the proposal (third paragraph).  Diane said that if you insist
on only putting in links that were a 100% match to the item being
cataloged, catalogers would have to create many more records. 
Frank and Josephine were able to see the benefits of having
records for each entity; they shared Robin's concern that
database maintenance could become very difficult under this
scenario. Yet, creating records for everything is just not
feasible, and people are already creating these other types of

Rebecca pointed out that the Dublin Core has a RELATION field
that currently maps to the 787 field (Nonspecific Relationship
Entry/Note). Robin was confused on the difference between an
electronic location (2nd indicator 0) and an electronic version
(2nd indicator 1).  Paul explained that the GMD is different
because the online version might have different content.  Jean
said that this situation was discussed at the CONSER meeting.  It
is an option to use the same record, but catalogers won't
describe all the differences. Users can see by going online.  

Tom Champagne spoke up in favor of the proposal, seeing it as
very useful. Cecilia Tittemore agreed.  She believes programmers
will make use of the indicators for manipulating displays. 
Josephine Crawford reported that she had received the same
feedback from catalogers and programmers at the University of
Wisconsin.  Paul asked if two display constants can be listed in
the USMARC format for a particular code.  Yes, since both are
suggestions and it helps the community scope out possibilities.  

Diane Hillmann made a motion to accept the proposal as written. 
Carol Penka provided a second.  In the discussion about the
motion, Paul expressed concern about the use of $3, thinking that
there is too much variation.  Rebecca countered that although
people are using $3 in different ways, the detail is very useful. 

There were six votes in favor, no votes against, one abstention,
and one member out of the room.   

PROPOSAL 97-3 : "Redefinition of Code "m" (Computer File) in

Rebecca Guenther introduced this proposal.  There have been two
previous discussion papers, each taking the ideas a little
further.  This proposal brings back several options for
redefining codes "m" and "p" in the Leader/06 -- basically
covering broader and narrower options.  

Jean Hirons spoke up immediately in support of the idea of the
proposal. Would like electronic serials to be coded as "a" not
"m".  Then use the 007 to identify type of computer file. 
Catherine Gerhart reported that there was a CC:DA straw vote in
favor of delaying this proposal until sometime after the October
conference in Toronto on the future of AACR2. An important issue
to be discussed there is content vs. carrier.  Sally asked if
CC:DA members were familiar with the earlier two discussion
papers.  Yes, Catherine replied, and concerns were expressed when
both were discussed.  Rhonda Lawrence wondered if CC:DA isn't too
often in the delay mode. Frank pointed out that CC:DA members are
in touch with the Joint Steering Committee for AACR2.  Diane
Hillmann reminded everyone that catalogers are creating records
every day with the "m" code -- the mess gets bigger and bigger by
waiting to redefine the code. We should try to deliver good
results to users with improvements that are feasible now. Paul
Weiss thought that we should move ahead with textual computer
files, but not graphic maps or other types. Assigning the codes
will be hard for catalogers, but the definitions improve with
each round.  He was particularly concerned with the difference
between kits ("o") and mixed materials ("p").  Rebecca believes
that Option 1 gets around this problem. Paul thinks that more and
more will be published, and it will become a bigger and more
confusing problem.  

Jean Hirons asked the meeting to return to the idea of MARC
coding, not how to catalog.  She believes that the coding changes
will be helpful for indexing and displays.  

Rich Greene debated further the issue of delaying or proceeding
ahead.  He could see both sides, and wasn't sure if any of the
options would work in the OCLC system.  First, catalogers must be
clear when choosing a type of record.  Many equate an AACR2
chapter to a type of record.  Second, consistency between systems
is really important to bibliographic control in these times. 
Third, and most importantly, it is necessary to differentiate
between electronic versions and other versions of a work. Can
this be accomplished with any of the Proposal's options?    

Karen Coyle asked about a code for records representing
interactive systems.  She believes one is needed.  Rebecca felt
that this could be mentioned in the definition of "m".  

A member of the audience spoke up in favor of postponing the
issue.  It  was felt that the proposal is not deep enough to move
forward at this time.  

John Espley agreed with Rich Greene's third point especially.  It
is important to identify other characteristics. Catherine talked
about trying to catalog an electronic atlas.  She used an 006,
but the record came out really strange.  Rebecca suggested using
an 007. Paul suggested using multiple AACR2 chapters.  

Diane and Jo came down on the side of postponing the proposal,
while the options are explored in more depth, examining as many
real-life examples as possible.  Karen said that the goal now is
to let serials people  not have to use "m" when clearly coding
for content is better than computer file.  But, others said that
the format change will affect special materials.  Paul asked if
the change would open up the floodgates.  

Jacquelene decided to take a straw vote.  How many people think
that either Option 1, 2, or 3 is viable today?  Perhaps 25.  How
many people will not accept any of the three options today? 
About the same.  What if the proposal was limited to textual
content only?  Only eight people would be willing to proceed. 
Sally pointed out that people are coding for content anyway!  She
asked what is needed to act on this proposal in the summer. 
First, deal with OCLC's concerns, especially the consistency
between systems issue. Second, redo Attachment A.  Third, people
should supply as many examples as possible to Rebecca.  It was
felt that examples are really important.   

PROPOSAL 97-7 : "Coding Leader/06 and Leader/08 for Archival

Steve Hensen, representing the Society of American Archivists and
Duke University's Digital Scriptorium Project, introduced the
proposal.  He explained that there has not been a prior
discussion paper, because there is some urgency in solving some
unintended problems caused by the implementation of Phase II of
Format Integration.  Defining archival control is not easy.  Both
catalogers and utilities have been confused.  There has been
considerable discussion about this proposal in the archival
community.  The solutions presented here have not been
universally approved, but there is a consensus in the community
to move forward.  

Wendy Duff stated that there is a history of collaboration
between the Canadian and American archival communities, even
though the two communities use different cataloging rules.  The
Canadian community supports this proposal.  

Chair Jacquelene Riley suggested that MARBI discuss each proposed
change separately.  

1)  Redefine Leader/08 "a" (Language Material) code.  It is
recommended to change the name to Textual Material and, more
importantly, to change the definition to emphasize "primarily

Paul Weiss asked if the utilities will lump together materials
cataloged by RAD (Canadian Rules for Archival Description) and
APPM (Archives, Personal Papers, and Manuscript) rules.  Sounds
like this is the case.  Rich Greene stated that OCLC supports
this proposed change.  OCLC wants to treat archival materials
separately from other materials, and sees this code as a good way
to do it.  

Paul and John Attig wondered about Leader/18, Descriptive
Cataloging Form. How does Leader/18 fit in?  The archivists
replied that this is a related code, but Leader/08 is better
overall for the purpose in mind.  Some materials are held by an
archive, but are not under archival control. Examples are Codex
manuscripts and modern literary manuscripts.  This proves an "a"
code is needed in Leader/08 to distinguish those materials under
archival control.  Diane Hillmann wasn't easily convinced; she
felt that there is a longstanding tradition to not handle
literary manuscripts archivally.  

2) Make Leader/07 "t" (Manuscript Language Material) code
obsolete.  The rationale is that "manuscript language material"
is ambiguous and misleading to both searchers and catalogers. 
The definition states that the material is usually intended to
exist as a single instance, but this characteristic does not fit
in with today's technological environment where multiple versions
of manuscripts are possible electronically.  

John Attig reported that he and Rutherford Witthus met with the
RBMS Bibliographic Standards Committee.  It became clear that
there are manuscript materials that must be distinguished from
those under archival control (Leader/08 "a").  Some examples are
theses/dissertations and individual manuscripts.  It is very
important to be able to search and/or limit a search to these
materials.  Therefore, an argument was presented to maintain "t"
and improve the definition.    

Steve Hensen reported that this had been discussed by the people
involved with this proposal. There was some question as to
whether or not the function could be handled via the 008. The
Digital Scriptorium Project is re-inventing how to catalog codex
manuscripts.  The user community wants manuscripts to be separate
from other records, yet institutions want to use USMARC for
obvious reasons. Involves a logical separation based upon good
coding. Right now the cataloger has to choose between archival
control and books.  Neither choice works very well.  Steve Davis
also suggested coding this somewhere else in the record, in a
spot not as high as the Leader.  Robin Wendler added that users
really need the ability to retrieve results merged or separate,
depending upon the specific user need.  

Steve Davis asked for more information about the Digital
Scriptorium Project.  Will it be treating all manuscripts in the
same way?  How will "medieval" be shown?  Steve Hensen replied
that the papyrus archives has about 1500 records at the present
time.  Whether using the RAD or AAPM rules, this doesn't
necessarily mean archival control applies.  Therefore,
combination of Leader/06 "t" and Leader/08 "a" is very helpful. 
Leader/06 "t" only is not enough due to the materials published
by UMI.  Leader/08 "a" is not enough due to the categories of
manuscripts that are not under archival control.  Perhaps it is
best then to code as independent characteristics.  

Paul Weiss asked for other examples of manuscripts not under
archival control.  John Attig stated that two clearcut examples
have already been given, and this is enough to work on improving
the format (e.g. theses/dissertations and individual
manuscripts).  Steve Davis felt that it will get harder and
harder, because conceptually there are many types of manuscripts. 
Robin Wendler pointed out that we have 500 years of handling
manuscripts in the original sense, and yet the rationale for
making "t" obsolete is that it is too hard to define.  Another
pointed to technology for making this problem so difficult.  We
have moved from the single possibility of handwriting to multiple
possibilities: typescripts, xeroxing, scanning images, etc.  

Paul Weiss suggested making three codes in the Leader/06
      "t" (manuscript language material) 
      "d" (Manuscript music) 
      "e" (printed map) 
and then defining a new 006 for manuscripts.  Sally McCallum
wasn't so sure that this would be the best approach because the
006 is finely tuned to the 008 (wouldn't want to change the 008
in any big way).  John Attig also felt that the 006 is not a good
field for secondary characteristics. Sally suggested that this
issue needs further analysis and a new proposal that includes a
place for distinguishing codex vs. non-codex manuscripts. There
was much back and forth, and then agreement to hold on making "t"
obsolete until all the options can be identified and analyzed. 
Certainly, making all three codes obsolete should be examined as
part of this.  

3) Leader/06 "p" (Mixed Materials) code.  It is recommended to
redefine this code to change the standard as to when to call a
collection mixed. The current definition emphasizes physical
quantity, whereas the new definition leaves it to the cataloger
based on quantity or other factors, such as the focus of a
collection or the intellectual importance of the material.   

Steve Davis asked what is the function of this byte?  To define a
system file, for retrieval, or what?  He suggested the option be
there, but didn't think universal consistency was reasonable. 
Catherine Gerhart wondered if catalogers don't use their
judgement all the time.  Isn't this the difference between
original and copy cataloging?  Wendy Duff felt that this was too
broad a view..... the archivists are requesting a specific change
to the standard so that the standard better accommodates
preferred cataloging practice.  

Robin Wendler believes that the situation is different depending
upon if a cataloger is dealing with published or unpublished
materials.  Steven Davis felt that there is no clear cut way to
decide what is predominant. He supported leaving the code more
open to cataloger's judgement, since the description occurs
within the context of the collection description.  

Paul Weiss asked about a graphic map.  Is it a map or a graphic? 
OCLC documentation tells catalogers what to do, but USMARC does
not.  He suggested using a "p" in the 006.  Rebecca Guenther felt
that this is a premature suggestion.  

Karen Coyle asked if a system can now distinguish what most users
would call a book.  She thinks "book" is useful.  Paul does not
think that this can be done now.  Steven Davis said that we now
have to think about "digital objects."  Robin suggested that,
under the Books format, we could have a digital code.  But, this
is a problem if manuscripts are cataloged under the Books format. 
Sally McCallum believes that part of the problem is one of Format
Integration implementation.  The cataloger workforms have to
catch up with FI!    

4) Redefining name of 008 field from Books to Textual
(Nonserial). This part of the proposal becomes necessary if the
changes to Leader/06 are approved, because this field would then
encompass more than books.  

5) Delete field 006 for Mixed Materials.  Mixed is now not
considered to be a physical characteristic, so this field is
logically inconsistent. It is believed that no one is using it.  

Jacquie Riley made a motion to accept the redefinition of
Leader/08 "a" and Leader/06 "p" and to delete the 006 for mixed
materials.  Both Robin and Paul spoke up against parts of the
motion, and there was no second.  

Jacquie then made a motion to redefine Leader/08 "a" and to
rename the value as in the proposal. Paul Weiss provided a
second.  There were eight votes in favor and no votes against.  

Jacquie made a third motion to accept the redefinition of
Leader/06 "p" as presented in the proposal.  Frank Sadowski
provided a second.  There was some discussion about letting the
archival community move ahead in this area, rather than hold them
up while the map and music communities are consulted.  There were
five votes in favor, two votes against, and one abstention.  

Jacquie made a final motion to approve deleting the 006 for mixed
materials from the format.  Rebecca felt that this was not
possible from the utility point of view.  Paul recommended
holding back as long as "p" was still under discussion.  Frank
Sadowski made a second.  This motion did not pass.  There were
two votes in favor, four votes against, and two abstentions.  

The rest of the proposal was tabled until the next conference. 
Input from the map and music communities will be sought by LC

Jacquie closed the meeting by thanking the archival community
representatives for months of activity and work on the various

**************** Monday, February 17, 1997 ********************* 

 The PLA Community Information Section Technologies Committee,
represented by Louise Sevold, requested that provisional status
be removed from the Community Information Format.  The resolution
from the Committee follows verbatim.   

"February 16, 1997 PLA/CIS Technologies Committee.   Lee Ireland
chair.  The following resolution was passed at the PLA/CIS
Technologies Committee meeting on February 15, 1997.    The
USMARC Community Information format was adopted as a provisional
format in 1992.  The Library of Congress developed this format at
the request of the library community to provide a standardized
method of classifying and indexing community information.    

Since its publication, the format has been widely adopted by both
the library and vendor community.  Libraries of all sizes, from
large, urban systems, to small libaries, are now using the
format.  Practically all of the major library automation
vendors-- DRA, Endeavor, Gaylord, GEAC, Innovative, SIRSI, VTLS
-- have incorporated this USMARC format into their software.  The
support of the format in library automation systems has
contributed to its widespread adoption by libraries.  

Since the publication of the format by the Library of Congress,
few changes have been proposed by those who use the format.  The
original design of the format has provided librarians with the
flexibility necessary to describe the wide variety of resources
in their communities.  

Therefore, we recommend that the US Community Information Format
be removed from provisional status.  With this change the format
would join the other USMARC formats and be regularly maintained
and updated by the Library of Congress."   

Paul Weiss asked if work was complete on the CI format.  Louise
Sevold, Diane Hillmann, and John Espley all stated that the
format is working well at this time, and there are no outstanding
issues.  They supported removing the provisional label.   

Diane Hillmann made a motion, and this was seconded by Carol
Penka.  There were six votes in favor, one against, and one

PROPOSAL 97-5 : "Changes to the USMARC Classification Format for
Multilingual Classification Schemes"   

Joan Mitchell, representing OCLC Forest Press, introduced this
proposal.  In 1993, the IFLA sections on classification and
information technology appointed a joint working group on the
development of a MARC format for classification data, which
looked at the topic of multilingual classification schemes. 
Elaine Woods was commissioned as an outside consultant.  There
were many reviews in a couple of different stages.  In July of
1996, the working group approved a requirements document, which
has led to this proposal.  This is expected to be the first of
several proposals to MARBI.  A future one may deal with the issue
of scripts.   

Joan reviewed the importance of this proposal and what the
working group would like to accomplish.  First, classification
schemes can help worldwide bibliographic control because the
notation (i.e. the class number) is not specific to any one
language.  It is a common control language that could be used as
a switching language in multilingual databases.  Any class
number's caption could be displayed in the preferred language of
the user.  This is the primary goal.  It is not possible to do
this, however, without adding the Source and Edition information
to the classification records.  It is therefore proposed to
define some new subfields ($d Source Edition Identifier, $f
Authorization, and $n Variations) in the 084 (Classification
Scheme) field, to make the 084 $e repeatable, and to define a new
field 686 for Relationship to Source Note.   

Robin wondered immediately if it might be better to show
authorized/unauthorized translations in a code, rather than
free-text in the 084 $f.  Paul Weiss suggested an indicator
value. Rebecca Guenther reported that this had been considered
but rejected.  Sherman Clarke asked for clarification; what is
being authorized here?  The number or the caption?  Joan
explained that the cataloger is showing that the edition has been
authorized or not authorized, so it has to do with the caption.
To give an example, there is an abridged, authorized French
translation of DDC, as well as an abridged, unauthorized French

Paul asked why it was necessary to code authorized/unauthorized
in every single classification record.  Couldn't there be a
look-up table?  Joan reported that there can be more than one
translation in a record in the same file.  She also said that the
plan is to use $f only when the translation is unauthorized.  She
was asked how the information will be used.  Joan replied that
they are trying to break new ground but the main purpose is to
communicate the value of the information in the record.  The
records will be used by OPACs to display captions to users, the
records will be used by other translators, and the records will
be used by catalogers.  Michael Johnson agreed with Robin Wendler
that codes would be better to represent authorized/unauthorized. 
This would facilitate machine processing.  It was suggested to
put the code "unauth" or other abbreviated data in the $f.  Joan
said she appreciated the suggestion, since many implementation
details remain to be worked out. 

A question was asked about the UDC multi-language edition.  Will
each number be represented by a single record (for all the
languages) or a record for each different caption?  Unknown at
this time.   

Paul Weiss raised a concern about the 084 $d (Source Edition
Identification).  He could see why this information is important
but felt that more data was needed for the stated purpose.  Joan
responded that further details about the translation would be
added to the $n.  Paul noted that there will be a lot of
inputting and storage of data, since the same note will be
repeated in each number's record.  Bonnie Dede explained that it
is useful to keep the information in each record.  She suggested
that "unauthorized" be input into the $n, that the $n be made
repeatable, and that the $f be eliminated.   

Diane Hillmann wasn't so sure that inputting is a problem, since
increasingly catalogers can use templates or cut and paste.  She
agreed with Bonnie that it is useful for a cataloger to see up
front what is happening, whereas if a cryptic code is input, one
must go look it up. Paul recommended that the Relator code list
include a code for each edition.  But, when combining records,
you need to know which edition is relevant at all times.  Paul
felt this could be done by the system since it could do a table
look-up.  Robin felt that there is a strong relationship between
$n and $c, and more than one subfield in the same field might
confuse the meaning of the data.  Joan explained in some detail
that each translation is its own unique thing, and that it is
very hard to keep them all straight.  The USMARC format is being
used as a transmission medium, not for storage, so she doesn't
share Paul's concern.   

Diane stated that it is important to the cataloger knowing the
exact meaning of each piece of information in a classification
record. Josephine Crawford spoke up in favor of codes, as this
would be more efficient in the long run as more and more
translations come out. Unfortunately, Joan responded, there are
many, many translations and there is no one to track them and add
codes to the Relator list. Joan emphasized that they want to look
at this issue from a multilingual and user point of view, not
from a cataloger point of view.  It is an exciting thought to
think of an OPAC in California where DDC captions could display
in either English or Spanish, depending upon the user's
preference.  They are trying to lay a foundation, and want to get
the data moved from word processing files (where it commonly
resides now) to the USMARC format!   

Robin Wendler asked how the 084 $n data would relate to the user. 
Joan said that this data would be used by the system programs. 
These implementation details cannot be ironed out until the basic
proposal is passed by MARBI.  Paul explained that he and some
other MARBI members are showing reluctance because it is not good
to start using unnormalized data, when it could be normalized up
front.  The bibliographic community has learned lessons from the
past-- for example, normalized data is much better from a data
management point of view.   

Joan Mitchell went on to describe the proposed 686 (Relationship
to Source Note) field.  She walked the Committee through a couple
of examples. The Crevalcore, Bologna example on page 5
illustrates the use of an Italian translation of the 20th edition
of DDC.  The number 454126 assigned in the 153 field is an
expansion in the Italian translation to cover more geographic
sites in the province of Bologna. The 20th edition DDC number
4541 is shown in the 686 field with an indicator value to show
that an expansion has been done.  When in the same source
edition, the 686 $2 is not used.  The $2 only shows exceptions.  

Pizza is used as an example of an adaptation.  In DDC, pizza is
considered to be a "meat and cheese pie" but, in the Italian
edition, pizza was moved to another number so that it is
classified under "bread."  This adaptation represents cultural
differences between countries.   

Someone asked why the Turkish adaptation example has some fields
in Turkish (084 and 153) and two 686 fields in English.  Joan
explained that the caption is input in the language of the
edition or translation, but that the rest is input in the
language of the cataloger.   

Betsy Cowart asked if the subfields are in any prescribed order. 
No, although there is a natural order that is used depending upon
the meaning. Sally pointed out that USMARC only occasionally
recommends the order of subfields, but that it is not needed in
this case.   

Paul asked about the 686 $o subfield.  This is the number where
the instructions are found.  Paul asked if this refers to the
source edition or the translation.  Joan replied that it refers
to the source edition.   

Paul moved to pass the 686 field as described in the proposal. 
Frank Sadowski provided a second.  There were eight votes in
favor, and no votes against.   

Diane Hillmann moved to pass the 084 field, and Elaine Henjum
made the second.  There were four votes in favor, three votes
against, and one abstention.     

PROPOSAL 96-8/9XX : "Add Fields in the 9XX Range"   

This proposal had been discussed in some depth on Saturday,
February 15. Strong opinions had been expressed in favor of the
proposal and against the proposal.   Margaret Stewart reported
that the Canadian representatives had considered Saturday's
discussion carefully.  Given all the considerations, the
recommendation was to create an appendix in the USMARC
documentation listing the CanMARC 9XX fields.  Cross reference
fields are part of these 9XX fields, and they would consider
leaving them out.  They will make every effort to show that other
9XX fields are local fields, and that these are the Canadian
bibliographic fields.   

Robin Wendler recommended that the appendix talk about 9XX fields
generically, and then supply examples from Canada, RLG, OCLC,
etc.  Betsy Cowart saw this more as a separate document than an
appendix.  Sherman wasn't clear if the document will show
"examples" or show "all uses."  The intent is to show examples
only.  Rich Greene reported that OCLC doesn't want to be included
in this appendix for two reasons.  The 9XX fields don't change
much, and OCLC doesn't want to be tied to an LC publication

Paul moved that LC and NLC staff work together to create this
appendix, given the many comments made on Saturday and Monday. 
Frank Sadowski provided a second.  John Attig asked for
clarification: MARBI then is leaving the issue up to LC staff? 
Yes.  Robin and Diane emphasized that it is very important that
it be made clear that 9XX fields are local only, so that vendors
and catalogers are not confused. There were five votes in favor
of the motion, and three votes against.     

PROPOSAL 97-2 : "Definition of Second Indicator (Display constant
controller) in 76X-78X Linking Entry Fields"   

Rebecca Guenther introduced this proposal about the linking entry
fields. A problem was introduced when the 774 field was passed
(Proposal 96-4). The $i subfield was defined for all the linking
entry fields, but no mechanism was established to suppress the
default display constant when the $i is used in the field.  The
second indicator # value is used to trigger the display of a
constant specific to the tag.  The second indicator 8 value would
be used to suppress an automatic display constant so that the $i
text can display instead.  It is also recommended that the 774
field second indicator 0 value be deleted from the format,
because it is the same as value # (Constituent unit).   

John Attig asked why the $i was added to the 786 and 787 fields,
since no display is recommended.  Rebecca responded that they
wanted to add the $i across the board, and there could be a use
for $i in 786 and 787.  Paul added that it is efficient from a
system perspective to process all the linking fields in the same
way -- i.e. display prefix from $i.  However, the 246 is not the
same, so this is confusing.  Diane Hillmann considers the 246 to
be an exception.   

As for value 0, Sherman wondered what MARBI had in mind when 96-4
was passed. Rebecca said that it was simply a mistake because of
the original two options in the proposal, and that two different
values were defined for the same thing.  Value 0 can be easily
deleted, because it was published but not yet implemented.   

Diane made a motion to accept the proposal as written.  Paul
provided a second.  There were eight votes in favor and no votes

PROPOSAL 97-4 :" Addition of Subfield $5 in field 655 (Index
Term--Genre/Form) in the USMARC Bibliographic Format"   

Rebecca explained that this was a straightforward request. 
Sometimes the physical form is represented in the 655 field, and
sometimes this form applies to a specific copy, not to all
copies.  The recommendation is to create the $5 where a cataloger
can input the USMARC code of the institution that owns the copy
with the specific physical characteristic. When the subfield is
not listed, the 655 form applies to all copies.   

Representing Harvard University, Robin Wendler urged the approval
of this subfield. There are many cases where the form in the 655
shows a very special characteristic (such as a fore-edge painting
on a rare book) and it is important to code this data precisely. 
Paul Weiss spoke up in favor of the proposal, and also suggested
that it would be a good change for the Holdings Format.  He moved
to accept the proposal as written.  Diane Hillmann provided a
second.  There were eight votes in favor, and no votes against.   

PROPOSAL 97-6 : "Enhancements to Field 007 (RSI) for
Remote-Sensing Images"   

Sally McCallum introduced this proposal, saying that it was a
follow-up on recent MAGERT work and the USMARC/CanMARC
harmonization work.  Susan Moore, MAGERT representative, reported
that the MAGERT Cataloging and Classification Committee worked on
this proposal.  There is a strong need for approval.  Margaret
Stewart worked with the Canadian cartographic community who also
believe the changes will be useful.   

Paul Weiss wondered if MARBI was being asked to approve a
situation where two different 007 fields would be input in a
single record.  Susan explained that this is not the intention. 
Either the cataloger has a map or the cataloger has an RMI -- the
two cannot co-exist.   

It was suggested to add the codes "z" for Other and "u" for
Unknown in the 08 Sensor Type byte.  Frank questioned the need
for Other.  Susan explained that sensors are either active or
passive now, but the new codes will allow for new development
which is likely to occur.   

The 02 byte is still undefined. Could it be closed up, moving all
bytes forward by one.  Gary Smith said that this should not be
done.  Sally asked why he thought this, since this 007 is a new
field and is not yet in use.  Is there a correspondence between
bytes 03-10 in the 007 (Maps) field?  No.  But, Gary presented a
convincing argument that 02 is obsolete in the other 007s and it
is best to leave it undefined here, for prgramming ease.   

Paul Weiss questioned the wording in byte 03, Altitude of Sensor.
Sometimes the target is not the earth, but can be Mercury or the
moon.  It was agreed to change the description to "A
one-character alphabetic code indicates the general position of
the sensor relative to the target" and to change the code "a"
description to "Surface" rather than "Terrestrial."   

Paul also suggested that byte 06, Platform Construction Type, is
defining some codes using feet.  Wouldn't the metric system be
better, since USMARC is becoming an international code?  It was
agreed to add the metric equivalencies.   

Robin asked about byte 05, Cloud Cover.  Isn't this really
important, and yet the coding is not accurate in all cases?  She
wondered if the byte should be called Percentage of Constricted
View instead.  Susan explained that the map cataloging community
wants to be consistent with the "Content Standard for Digital
Geo-Spatial Metadata" and this standard does not deal with other
obstructions, just cloud cover.  However, Susan will take this
thought back to the MAGERT Cataloging and Classification

Rich Greene asked about bytes 09-10, Data Types.  It was not
clear when to use the "mm" and "zz" codes.  Margaret and Susan
will get some additional information from map catalogers so this
documentation can be improved.   

Paul moved to accept the proposal with the changes that had been
discussed.  Carol Penka provided the second.  There were eight
votes in favor and no votes against.   

There was also some discussion about making obsolete the value
"r" in byte 01 of the Maps 007.  This is a possibility, but Susan
would like to first consult her constituency.  If the change is
desired later on, it will be sent through as a new proposal.     

DISCUSSION PAPER #98 : " Subentity Codes for Country of
Publication and Geographic Area"   

Sally McCallum introduced this discussion paper by explaining
that there have been requests to establish lists of subentity
codes for the Country of Publication (008/15-7,044, 535$g, 775$f,
851$g, and 852$n) and the Geographic Area Code (043).  Right now
USMARC documentation has country codes and some subentity codes
(for US, Canada, and the UK) in the 008/15-17.  There is also a
draft ISO standard where it is up to each country to select and
register their own subentity codes.  Sally mentioned the
following. First, there is a certain amount of consistency
between the various lists, but only a certain amount!  And,
second, there are constraints in the MARC format for codes.  For
instance, GACS would not accommodate the numeric ISO subentity
codes.  Third, the ISO 3166 standard is in flux, alot depending
upon the participation and stability of the country.   

This problem has been around for awhile too.  Since Australia is
now adopting USMARC, Australia would like to add its subentity
codes to USMARC.  Diane Hillmann stated that she believes that
the 008 and 043 have different purposes.  Aren't both desired? 
Yes, Sally responded.   

David Goldberg felt that it would be hard to reconcile the
differences between the USMARC lists and the ISO 3166 list. 
Sally had hoped that just the subentity list from ISO could be
used, but David explained that some countries use a number and it
is only meaningful when paired up with the ISO country code. 
Diane suggested using the full ISO code (country and subentity)
in the 044 field.  This would be strange to US catalogers but
would make sense to the rest of the world since these codes are
heavily used elsewhere  (e.g. CH for Switzerland, not SZ).  Gary
Smith reiterated Sally's comment that the ISO 3166 codes are
unstable, because they change when the country changes.  Karen
Anspach supported Diane's idea, because it would mean LC would
not have to maintain a different USMARC list. Sally said that
each country eventually has to face up to the issue of code
stability.  She also said that LC would not establish a subentity
list until a country asked for it.  Susan Moore suggested looking
at the LC G schedule to see if the coding there might be helpful. 
Perhaps the 052 or the 033 could be helpful.   

John Espley reported that VTLS has overseas customers, and they
would like to use the 008 Country code.  Rich asked if the other
countries interested at this time in using the USMARC format see
it as a barrier that USMARC subentity codes for their country are
not yet established.  Generally no, since the countries just use
their own codes.  However, Sally recognizes that these records
move around at an international level and she wants to look at
the issue from the big picture point of view.  E.g. Enable
systems to validate a code established by another country or not? 

Sally said that one possible approach is to let the first 26
countries get subentity codes in the Country Code list.  Another
possibility is to let all countries "expand" into another
subfield where a variable length subentity code could be
recorded.  Would a Swiss library, for instance, be willing to put
008 CT "sz" and then use a subfield in another field to show the
Swiss canton using the ISO standard code?  If this practice were
instituted, then it follows that US records should convert the
subentity from the 008 to the subfield.  To allow for past
practice and have a flexible approach in the future, it was
suggested to set up the 043/044 with indicator codes for the type
of code (USMARC or ISO), to put the country code in one subfield
(could be optional if already coded in 008), and to put the
subentity code in another subfield.  The main thing is that if a
cataloger is using the ISO list, the subentity code requires the
ISO country code to be meaningful.   

Based upon this discussion, Sally will try to put together a
proposal for a future meeting.     

DISCUSSION PAPER #100 : "Script and Romanization Issues in the
USMARC Authorities Format"   

The discussion paper was not yet ready for distribution.  Sally
explained though that the intention is to develop principles in
regards to script and romanization in the authorities format, and
to consider system efficiency, inputting efficiency,
multi-national needs, and multi-lingual needs.     

Meeting participants agreed that this is an important issue. 
There are field and record level issues to work through.  Right
now the authority record has 7XX fields and a parallel record is
created for the heading in another language.  Would it be better
to have a single merged record for all the variations?  Called a
"mudball" record.  If this is the case, what kind of system
changes would be involved?   These are the kinds of things that
should be addressed.    


Sally and Jacquelene attended a CC:DA meeting to discuss a joint
meeting with MARBI at the annual conference in San Francisco. 
Would like to discuss the CC:DA report by the Metadata/TEI
subgroup at this meeting. Want to try to collect the decisions of
people putting AACR2 into TEI, and make a cross-walk from the
format to the rules. It was suggested that this report by
distributed ahead of time to MARBI as a discussion paper.  

MARBI has received a request from the LITA TESLA Committee to
co-sponsor an ALA program in the Summer of 1997 on UNICODE. 
Corrie Marsh has been in touch with Jacquie.  The request is to
sponsor in name only -- MARBI does not have to do any work!  The
title of the program will be: Multiple Languages, Unicode, and
You.  Paul moved that MARBI co-sponsor this program in name only. 
Diane provided a second.  There were seven votes in favor, and
one abstention.  

Sally and Jacquie reported on the work of the Character Set
Subcommittee at the conference.  They both sat in on the meeting. 
The Subcommittee is making progress on the three possible
solutions to the ASCII clone problem.  Some additional Arabic
characters have been identified and will be sent to the UNICODE
people.  Finally, it has been decided to recommend a subcommittee
for the CJK work, so Sally is preparing a charge.  Jacquie is
looking for volunteers for this new Subcommittee.  The charge
will include the same guiding principles (e.g. reverse mapping).  

[Minutes prepared by Josephine Crawford, June 1997]               

Go to:

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