MARBI Members:
Priscilla Caplan LITA Univ of Chicago
James E. Crooks RASD Univ of Calif, Irvine
Shelby Harkin ALCTS Univ of North Dakota
Sandra Lindberg RASD Lafayette Public Library
Jacqueline Riley RASD Univ of Cincinnati
Paul Weiss ALCTS Univ of New Mexico
Larry Woods LITA Univ of Iowa
Robin Wendler LITA Harvard University
Jacqueline Riley RASD Univ of Cincinnati
MARBI Interns:
Elaine Henjum LITA Florida Ct. For Lib Auto
Carol Penka RASD University of Illinois
Representatives and Liaisons:
Joe Altimus RLG Research Libraries Group
John Attig OLAC Penn State Univ
Randall K. Barry LC LC, Net Dev/MSO
Betsy Cowart WLN WLN
Bonnie 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
Maureen Killeen ISM ISM Library Info Services
Rhonda Lawrence AALL UCLA Law Library
Karen Little MLA Univ of Louisville
Sally McCallum LC LC, Net Dev/MSO
Susan Moore MAGERT Univ of Northern Iowa
Young-Hee Queinnec NLC NLC
Marti Scheel NLM National Lib of Medicine
Louise Sevold PLA/CIS Cuyahoga County Pub Lib
Patricia D. Siska ARLIS Frick Art Ref Lib
Rutherford Witthus SAA Univ of Colorado
Other attendees:
John Albright RTIS
Joan Aliprand Research Libraries Group
Karen Anspach EOS International
Kathy Bales Research Libraries Group
Connie Barrencleigh Health Canada
Sara Ramser Beck St. Horn's (?) Public Library
Julia Blixrud CAPCON Library Network
Francis Bondurant New York University
Arevig Caprielian New York Society Library
Ann Case H.W. Wilson Co.
Sherman Clarke New York University
Karen Coyle Univ of Calif Division of Lib Auto
Carroll Davis Columbia University
Michael Fox Minnesota Historical Society
William W. Jones New York University
Lola Halprin Emory University
Ruth Haas Harvard University
Diane Hillmann Cornell Law Library
Jean Hirons Library of Congress
Charles Husbands Harvard University
Sherry Kelley Smithsonian Institution Libraries
Rhoda Kesselman Princeton University
Kris Kiesling RLG / SAA-CAIE
Mary Larsgaard Univ of California, Santa Barbara
Elizabeth Lilkes Brooklyn Historical Society
Clifford Lynch Univ of California Div of Lib Auto
Andrew MacFowan The British Library
Elizabeth Mangan LC / G&M
Ingrid Parent National Library of Canada
Cecilia Preston ----
Patricia Rader New York Public Library
Becky Ringler Univ of Calif, San Diego
Barbara Roberts DC Public Library
Frank Sadowski University of Rochester
Jacque-Lynne Schulman Natl. Library of Medicine
Louise Sevold Cuyahoga County Public Library
H. Shoemoh (?) British Library
Thom Shudargas CCLA / Tallahassee
Ann Sittirn Health Canada
Sandia Smalley Harvard University
Gary Smith OCLC
Stuart Spore New York University Medical
Steven Squires Univ of North Carolina at Chapel Hill
Dianne Stalker State Univ of New York at Stony Brook
Barbara Story LC
Vitus Tang Stanford University
Susanne Warren Art & Architecture Thesaurus
Bob Warwick Rutgers University
William Wilson New York University
Bob Warwick Rutgers University
Jill D. Yaples Binghamton University Libraries
MARBI Recorder:
Josephine Crawford University of Wisconsin, Madison
*****************************************************************
Saturday, July 6, 1996
*****************************************************************
Priscilla Caplan opened the meeting with introductions and an
announcement about a planned MARBI Character Subset meeting.
---------------------------
DISCUSSION PAPER NO 96 : Defining a Uniform Resource Name Field
in the USMARC Bibliographic Format.
Rebecca Guenther introduced the first discussion paper on Uniform
Resource Names (URNs). She explained that this paper is more
"FYI" than for any serious discussions leading to MARBI decisions
in the near future. She suggested that it might be useful to
post links from LC's web site to the important IETF (Internet
Engineering Task Force) documents.
Cliff Lynch brought some up-to-date news from the recent Internet
Task Force (ITF) meeting, since the discussion paper was written
before the meeting was held. He said that the original URN group
was disbanded and the charter of a new group was well received.
Cliff expects
a URN syntax paper by December; he thinks this paper will provide
enough flexibility to incorporate existing schemes. It is likely
that an existing system, e.g. ISGN, could be embedded into a URN
scheme. Cliff also expects a long and painful standards process
to hammer out the resolution issues. One or two resolution
schemes will be worked on separately by the new group.
Apparently, the handles scheme has not been well received enough
to date to be considered, and PURLs (from OCLC) are considered to
be a form of URL. The primary scheme under consideration is a
hybrid of Ron Daniels' work and the Domain Name Server scheme.
Priscilla thought it would be helpful to have a review before
proceeding. A URN is a consistent name regardless of the
location of the electronic resource or network object. A URN is
only useful when it can be resolved, meaning:
-- your Internet request returns one or more locations.
-- your Internet request returns metadata about your object.
-- your Internet request returns your object itself.
MARBI needs to be thinking about:
-- what should library users get back? All of the above, or
does it depend upon the situation?
-- what is the relationship to cataloging records?
Paul Weiss stated a preference for using the 0xx field for the
URN rather than the 856 field. Karen Coyle agreed; she advised a
repeatable field at the bib record level. Cliff felt that there
is no clear answer: there are multiple and complex relationships
involved. How much should libraries try to track? Paul pointed
out that the 020 has similar implementation problems. Priscilla
remarked that different naming agencies will have their own
rules. The question of single or multiple records will be wide
open. Should $8 be used for linking purposes? Rebecca discussed
various naming authority possibilities within the library
community --LC, an ALA body, NISO, or other.
Joe Altmus wondered how serials would be handled. If there is no
connection between the number of URNs and cataloging records,
will a URN change occur when the publisher changes but the title
does not?
Rebecca believes that publishers will not follow a single scheme
themselves. Paul said that we have been dealing with similar
problems but on a smaller scale. Cliff encouraged the library
community to hash out the intellectual content issues related to
URN. He said that the IETF has no expertise or interest in this
area. The library and publishing communities should work
together.
John Attig had two points to make. First, some things we already
do can become URNs, although the URN syntax may require
additional information. Second, when there are multiple URNs for
an object, catalogers must choose which to use. Rebecca said
this is a time for librarians to be proactive rather than
reactive. The bibliographic community can establish its own
naming
authorities and rules on such situations. No one was quite sure
who/what this should be though.
It was agreed that MARBI should promote discussions on URNs.
----------------------------
DISCUSSION PAPER NO 97 : Coding Digital Items in Leader/06 (Type
of record) in the USMARC Bibliographic Format
There have been various related discussions in the past, the most
prominent involving a recent Maps proposal. This DP seems to
emphasize cataloger flexibility dependent upon various factors,
such as form and user needs. The paper supplies a proposed
revised definition for Leader/06 Computer File "m" code.
John Attig suggested discussing the big picture first -- he
believes that the issue is wider than digitized
materials. Too many materials are a valid member of two or more
categories and it does not serve the users for catalogers to
select one only. He sees systems relying upon the leader/06 for
processing when this is not always helpful. His example was a
limit in OPACs. Robin Wendler believes it depends upon the
situation. Sometimes a primary limit is helpful, other times
multiple limits for the same object is better. Rich Greene
reported that the Leader/06 is used very heavily by the OCLC
de-duplication programs. It would be a major effort to change
these programs. He agreed with Robin that the situation varies
from the user perspective. Karen Coyle reported that the Melvyl
programs also do much duplicate detection; it would be much
harder since the leader/06 was an optional field. Priscilla
wondered if the Leader/06 will be needed once multiple versions
are always on the same record. Does it boil down to a content
versus carrier issue? Randy Barry said that the analogy to
microform breaks down with executable computer files. Priscilla
agreed; since there is a one-to-one relationship between the
Leader/06 and the 006 fields, there is a fatal flaw if the
Leader/06 "m" definition deals with executables only.
Priscilla suggested that the cataloging community work on
guidelines, while MARBI keeps the USMARC definition more open
ended. Paul Weiss said that the OCLC documentation does give
some direction now. For instance, it tells catalogers what to do
when cataloging something like a map puzzle (two cataloging
aspects). He said that the concept is good, but that detailed
guidelines are difficult to formulate. Catherine Gerhart agreed
to take the issue to the ALCTS CCS CC:DA Committee.
Priscilla asked if there was a consensus to open up the Leader/06
computer file definition. Betsy Mangan asked if MARBI could
recommend that content be coded in the 008, while the carrier is
coded in the 006. Would this be possible? Randy thought that
the 007 must also be considered. Sally reported that originally
MARBI tried to keep physical description codes in the 007 and the
bibliographic description codes in the 008. She suggested that
if an 007 is used, perhaps the 006 would be unnecessary. But,
unfortunately, there is the legacy of the past to consider.
The group discussed in some detail what types of material ought
to be coded under a revised definition of Leader/06 Computer
Files code. Paul believes it is appropriate for executable
software. Robin said that Harvard wants to use this code for
statistical data or social science datasets (the latter usually
don't have print equivalents). Another suggested expanding the
use to raw computer data. What about kits? What about source
code? What about files where both software and data are combined?
It was suggested that issues for digital material be dealt with
separately from other combinations. Participants requested that
the discussion paper come back as a proposal with two options:
one a narrow option to define code m as just executables and a
broad option to define m to include executables, data sets, and
raw non-numeric data. It was also recommended to consider
revising the definition of kit and look at code p for mixed
materials.
It was agreed that the issue needs more analysis and discussion,
and everyone was encouraged to post examples on the USMARC list.
----------------------------
PROPOSAL 96-7 : "Changes to FTP File Label Specifications for
Electronic Files of USMARC Records"
Sally McCallum introduced this proposal. It was discussed as a
discussion paper at the last meeting, when RLG in particular had
some particularly helpful comments. COBRA is a grouping of seven
national libraries in Europe; if these changes are adopted by
MARBI, COBRA would promote the use of this FTP standard in
Europe.
Priscilla asked first if there were any general comments. Karen
Coyle stated that she was surprised that the proposal covered
SGML since she does not see this as a communications format; was
the theory that libraries would use for USMARC file exchange
only? Sally responded that a Document Type Definition (DTD) is
being worked on now to make it possible to transfer a MARC SGML
record.
Someone asked about file names. Comments on their structure were
part of the earlier Discussion Paper, but is no longer needed.
Priscilla then began to run through each of the specific
proposals:
1. Change label file character set.
There was a little discussion about the OR character. No
objections registered against this proposal.
2. Change end-of-field (EOF) character symbol.
Marti Scheel asked if systems wouldn't use the recommended
character in the data itself. This does
happen according to OCLC. Rich Greene asked why the proposed
standard calls for having two marks (# followed by carriage
return or carriage return/line feed), since this seems redundant.
Sally said that LC prefers a line feed only. Gary Smith thought
that most FTP programs will be able to adjust to the standard.
Randy Barry asked if a line can be too long, and a line feed
would be needed on its own. Priscilla wondered if there could be
a fatal flaw in using the carriage return/line feed
alone. A system might end up with just a carriage return, since
the line feed is optional; what would then happen if the data
itself includes a carriage return? This might cause a problem. Is
the # mark really important to COBRA? Unknown.
Robin summarized the point of the discussion by saying that a
Carriage Return alone was too simple and an end-of-field
character was too much. There did not appear to be a consensus
at this point in the meeting. Either CR alone or CR + line feed
could be used.
3. Add optional Country Identifier field.
No discussion. No objections.
4. Make the Format Field mandatory.
There was a little discussion, but no objections.
5. Add optional Format Qualifier Field.
Gary Smith asked why not use an existing field. Sally responded
that the advantage of adding a new optional field is that there
will be minimal change to existing programs. Gary suggested
adding to the end of the FOR field. Sally said that Gary
suggests a more elegant solution, but that it would be hard to do
in a fixed field. In general, the working principle with
Proposal 96-7 was to modify as little as possible of the existing
fields to make implementation easier for all concerned.
6. Add optional Character Set fields.
Paul felt that the example was confusing. Little other
discussion occurred. No objections.
7. Add optional Character Variation fields.
No discussion. No objections.
8. Add optional Final Destination Identification field.
Paul suggested that this be a higher label. Perhaps change
position? The order of data elements in the past has been
mandatory before optional, and fixed length before variable
length. Therefore, Priscilla had assumed the FORmat field would
move up once it became mandatory. However, others in the room
had not assumed this. After discussion, there was general
agreement that the order is not important because programs will
look for the presence of tags.
Paul Weiss moved that MARBI accept the proposal with a single
change: drop the # mark as part of the end-of-field marker.
Define the end-of-field character to be carriage return or
carriage return followed by a line feed. There were six votes in
favor and no votes against.
------------------
PROPOSAL 96-8 : CAN/MARC Changes for Marc Format Alignment
Sally explained that she would like to introduce Proposal 96-8
today, so that Ingrid Parent (Directeur
General, Acquisitions and Bibliographic Service, National Library
of Canada) could say a few words on behalf of the National
Library of Canada (NLC). The detailed discussion would occur on
Sunday and Monday with Young-Hee Queinnec serving as the NLC
representative. Sally reviewed the process to date: two
discussion papers and impact statements have proceeded the
proposal. The statements in particular were very helpful in
formulating the proposal. Even though the process of alignment
is a difficult one, there are benefits for all in terms of record
sharing and less complex systems. Unfortunately, Canada has a
particular problem using CONSER records due to CanMARC/USMARC
differences and alignment would improve this situation. Sally
noted that archival data elements have been excluded from 96-8
and will be dealt with at a later time. She didn't expect a vote
on everything but would like for there to be significant
progress.
Ingrid Parent thanked Sally for her welcome and said she was glad
to be attending her first MARBI meeting. She reviewed the
history of the MARC harmonization effort, in terms of the British
Library initiatives and the general interest in cataloging
simplification. She pointed out that CanMARC and USMARC are not
very different compared to differences with the other MARC
formats. Unfortunately, resolving differences is not an easy task
due to the complex systems and large databases involved. Ingrid
asked MARBI members to keep in mind that there had already been
much negotiation and compromise. What was brought to MARBI in
the form of 96-8 does not show the fifty or so changes which
Canadian libraries have volunteered to do already, because
Canada's user base is smaller.
Unlike the U.S. community, the Canadian bibliographic community
has to meet bilingual requirements in the creation of cataloging
records. English and French are both official languages by law.
9xx linking fields are used for this purpose, but should not be
considered "local" fields. They have been part of the Canadian
standard all along (with hindsight, another set of fields might
have been selected). MARC format harmonization or alignment is
an opportunity to make the USMARC format international in scope.
There will be much work to accomplish this, but the benefits are
even
greater.
Priscilla asked Ingrid about the many options stated in the
proposal. Are all options acceptable to Canada? Not at all.
Young-Hee will describe the Canadian preferences in later
discussions.
John asked how the UKMARC project is going. Sally said that she
expects to deliver a discussion paper at the '97 Midwinter
meeting followed by a proposal at the Annual Conference. Will
any of the decisions here have to be reworked when the UKMARC
proposal is under discussion? Sally thinks not. Most areas
don't seem to overlap. The one exception might be the 016/010
fields. Robin asked if the British have used the 9xx fields.
Sally thought this might be the case.
John Attig noted that bilingual support is a big topic,
considering both authority and bibliographic formats. Marti
suggested we all think "multi-lingual support" instead.
Priscilla asked where the archivists are in their work on
CanMARC/USMARC harmonization. Rutherford Witthus reported that
the Canadians have been in discussion for some time. By the end
of the summer, much discussion within the Society of American
Archivists should have occurred. There is also a plan to meet
with vendors. He expects a discussion paper by the '97 Midwinter
Meeting, which will include a definition of archival control.
----------------
BUSINESS MEETING:
There were a number of announcements about new LC USMARC products
(Update 2 to Bib Format; new Organization Code List edition
(formerly Symbols of American Libraries) are out; Community
Information Update #1 is ready for printing.)
Sally reported that there are many calls for an up-to- date
Concise publication. Office staff are in the process of marking
up the Concise in SGML, adding examples in the process. The new
version will be put up on the USMARC Web site, and also offered
(as in the past) as a print publication.
Sally discussed a USMARC Web site on documentation status. The
printed updates are once a year or when needed, and there is
sometimes a need to know what the approved changes are, so it is
planned to update the Web status document just after each
meeting.
Sally reported that the MARC SGML Document Type Definition has
been received from the contractor. The purpose is to be able to
translate from USMARC to SGML MARC. LC is now contracting for a
converter program. The DTD and the converter (when completed)
will be available from the USMARC homepage.
Actually, there is one Bib DTD (has bib, holdings, and community
information) and one Authority DTD. There is a ten-page
explanation at the beginning. There are many comments through
out. It is a long DTD because generic subfields were not used
and it does include obsolete data elements. Sally suggested that
the DTDs be considered an "alpha" version, since MARBI might then
want to form a working group for a close review. The expectation
is that the end result will be a new USMARC standard.
There was a question from the audience about progress on LCCNs.
Will there be an internal LC workaround due to the century
change? The first internal change has been implemented in
splitting the Books file at LC. Sally reported that, because LC
staff are involved in a major effort to purchase an integrated
system, LCCN plans are only at an idea stage at this time. LC is
thinking that a four- digit LCCN would be implemented. Sally
emphasized that comments about impact are still usefule. There
probably will not be a MARBI proposal.
Sally raised the interesting question of the future name of the
format. USMARC will not work after the harmonization project is
completed. Sally and others have considered on IMARC (I can
stand for International, Information, Internet-Marc, etc.).
What will be the governance for international MARC? This is
under discussion as part of the British and Canadian
harmonization work. Probably each country will keep their own
advisory process in place. There may then be an IMARC Advisory
Group where each of the three involved countries (US, UK, and
Canada) can veto a proposal. What about the other countries like
Australia, Spain, and Switzerland? This hasn't been addressed as
of yet.
The conversation then moved on to discuss the Classification
Format. It has been designated "provisional" for some time now.
LC has about 700,000 records to date. There has been only minor
tinkering with the original provisional format to date. Is it
now time to remove the provisional designation?.
What is happening with non-LC classifications? The Dewey people
are planning to distribute Dewey tables using the USMARC format.
The National Library of Medicine is not planning on doing the
same thing with the NLM classification scheme, because it may be
abolished all together.
Are there any objections to removing the provisional status?
Paul Weiss presented some concerns that there are major
structural problems with the USMARC classification format. Bonnie
Dede suggested looking at international classification needs.
It was acknowledged that the mechanism for moving from
provisional to full status is not clear. Larry Woods moved to
remove the provisional designation from the classification
format. Paul Weiss provided a second. There were three votes in
favor and one vote against.
*****************************************************************
Sunday, July 7, 1996
*****************************************************************
PROPOSAL 96-10: USMARC Character Set Issues and Mapping to
Unicode
Larry Woods introduced Proposal 96-10, which is the result of
several years work by numerous people and an earlier discussion
paper. Working principles were communicated earlier and are
summarized in the Proposal. Round-trip or bi-directional mapping
is really important due to the mixed timing on implementation of
the Unicode Standard across systems.
Mapping has been completed for the majority of characters, as
listed in the paper. Problems and issues have been identified.
Larry asked everyone in the room to make a correction on page 3:
change F7 from "LEFT HOOK WITH TAIL" to "LEFT HOOK COMMA BELOW."
Larry defined "ASCII clone" to be various digits and punctuation
marks duplicated in the Latin, Cyrillic, Hebrew, and Arabic
USMARC character sets. The Unicode Standard provides only one
standard value with which to encode each of these characters.
The Standard includes an algorithm for the display of text which
accommodates ASCII punctuation marks and digits. If the UNICODE
conventions are used, it is not possible to map a string of
characters from USMARC to the Unicode Standard and back to USMARC
(round trip mapping), and to guarantee that the output will be
identical. Larry reviewed three options for dealing with this
problem:
1) map to some near equivalent (could lose data in
round-trip or bi-directional processing)
2) map to private use space (each system programs)
3) map to Latin equivalents but precede and end with a
special non-displaying character (new option not described in
Proposal 96-10).
Priscilla stated that the primary issue before MARBI members is
whether or not the proposed mappings are acceptable. The
secondary issue is to see if there is a preference for one of the
options for dealing with the ASCII clone round-trip-mapping
problem.
Joan Aliprand would like to see rigorous evaluation of the three
options for handling ASCII clones. If Option #1 is chosen, RLG
would have to rewrite current programs. Joan asked for a working
principle of "don't modify data unbeknownst to the data owner."
Larry gave an example of the bi-directional mapping problem. You
have a character string in Hebrew encoded in USMARC and this
character string begins with an opening parenthetical mark. The
character string is translated to Unicode as the bib record moves
to another system. Then it is translated back to USMARC as it
moves again. Because the translation is not perfect, the
parenthetical mark could curve the wrong way to the user
afterwards.
Larry would like to see all the options explored in more depth,
particularly the third option. Sally encouraged vendors and
systems to participate in the analysis, since the RLG
contributions have been so helpful. John Espley agreed to ask
system vendors for impact statements at the Monday AVIAC meeting.
John Attig asked about the work involved in implementing Option
#2 (using private use space). Would each site have to program
each use of the private space, representing significant work
across the bibliographic community? Yes. A few others agreed
that Option #2 was not good and would like to know more about
Option #3. Priscilla asked if there is a consensus that Option
#2 is not a good option. Yes, there was a consensus.
One member of the audience pointed out that we cannot assume that
users will have a library character set available on their
workstations. Another member asked about the property of
right-to-left (as in reading Hebrew). How will this be conveyed
in bi-directional mapping? Not answered. Robin Wendler asked if
only libraries have to deal with these mapping problems. Randy
Barry saw the problem as preserving current coding while the
computer world is in transition to the Unicode Standard. He
expects the problems to be solved eventually as standards fall
into place across systems.
Paul Weiss emphasized that the problem of round-trip mapping is
not an inherent problem with the Unicode Standard. It involves
mapping to/from USMARC. He believes the problem is due to a
shortcut that was taken when the original ASCII clones were set
up in USMARC.
Priscilla asked if there was any discussion on the proposed
mappings in Appendix 1. There was a question from the audience
on adding some badly-needed new characters to the USMARC
character set. Paul Weiss stated that it had been agreed to deal
with additions later. Joan Aliprand said that RLG is using a
superset of USMARC characters and can therefore accept additions.
In answer to a question about the next step in the process, Sally
said that two things will happen. First, more languages will be
mapped. Second, a Unicode MARC record will be set up for a test.
Why were Unicode precomposed characters (letters with accents)
not used in the mappings or allowed as alternate encodings for
the USMARC two-character encodings? Randy said that he has tried
to determine the universe of letter-with-diacritic combinations
and it was to large-- besides which, Unicode did not have
equivalents for all the possible combinations. Joan explained
that precompositions will be dealt with in a later phase of the
Unicode project.
The audience again raised the question of expanding the set of
characters in the USMARC format. Several urged that this be
done. Joan thinks it should be straightforward to map these, but
Randy Barry had a different experience when he worked on it. He
said it was harder to map two codes to one, than to map one to
one.
Sally ended the discussion by thanking the Subcommittee for all
its hard work and by saying that she expects the USMARC format to
have an expanded character repertoire in the future. Paul Weiss
moved that Proposal 96-10 be approved, with the exception of the
ASCII clone issue. Shelby Harkin provided a second. There were
five votes in favor and one abstention.
------------------
DISCUSSION PAPER #95 : Enhancements to field 007 (Map) for
Remote-Sensing Images in the Bibliographic and Holdings Formats
Sally McCallum briefly introduced the paper which discusses the
need for more 007 codes for remote-sensing images. Susan Moore,
representing MAGERT, provided more detail on why codes for the
altitude and attitude of a remote-sensing device, amount of cloud
cover, characteristics of the sensing platform, and recording
technique would be helpful to users.
John Attig suggested a separate 007 field for remote- sensing
images, rather than additions to the Map 007. Priscilla asked if
remote sensing can create data files. Mary Larsgaard responded:
yes, the data collected can be place into data files. They are,
however, still considered cartographic.
Paul Weiss asked why use the 007 for these codes? Cloud cover is
not a physical characteristic of the image itself, but indicates
something about the content. Apparently, cloud cover information
often tells the user about the quality of the image. The amount
of cloud cover can impact upon the "usefulness" of the image.
Therefore, one might say it indirectly describes condition.
Rich Greene reported that OCLC staff like RLG's suggestion to
look at a separate 007 field. It is important to know how much
of the Maps 007 field would transfer over. Randy had been
thinking along the same lines, that a separate field might be
better. Susan said that the data elements are not related to the
034 at all. Paul asked if all the needed data elements are now
known. He prefers selecting a variable rather than a fixed
field, so that additions are easier. Sally agreed that the 007
is supposed to be about the item from a physical point of view,
rather than bibliographic (008). She acknowledged that, while
these distinctions are generally maintained, it is not 100%.
John Attig brought up the Canadian aspect in regards to this
discussion paper. CanMARC contains six of the proposed data
elements in a local 009 field. As part of format harmonization,
Canada would like to move the coding into a non-local field.
Priscilla asked if there was a consensus present. There was
agreement that adding codes to an existing fixed 007 field is not
desirable. There was agreement that the data elements must be
accommodated. It was agreed to explore other options, such as a
new 007 field or a new variable field.
------------------
PROPOSAL 96-8 : CAN/MARC Changes for Marc Format Alignment
The Proposal had been introduced the day before. There are
just over twenty different changes, all of which are to be voted
on separately. Due to some people's schedules, it was agreed to
deal with the map proposals first.
PROPOSAL 96-8/007-01 (Globe):
Susan Moore reviewed the two codes requested by Canada, "e" for
lunar globe and "u" for unknown. She reported that MAGERT
supports the request, even though a small number of records will
have to be converted. Paul Weiss moved in favor of the Proposal
and Larry Woods provided
a second. There were six votes in favor of the motion and no
votes against it.
PROPOSAL 96-8/008-18-21 (Maps):
Susan Moore explained the two proposed changes. First, it is
desired to change the name of the code "c" so that it is clearer
to catalogers. Second, it is desired to add an "m" code for rock
drawings. Priscilla asked if there were strong feelings against
the name change and new code. No. Paul moved to accept, and
Larry seconded. There were seven votes in favor of the motion,
and no votes against it.
PROPOSAL 96-8/008-22-23 (Maps):
Canada requests the addition of three new codes dealing with
projection types:
az Azimuthal, other type
bz Cylindrical, other type
cz Conic, other type
In preparing the analysis for this Proposal, LC staff looked at
the records that had previously been coded "zz" for Other. Of
the approximately 180 different projections which have been coded
as "zz", only two additional new codes are apparent, Chamberline
trimetric projection ("an" suggested) and Lambert conformal
projection ("dl" suggested). Young-Hee Queinnec reported that
Canada prefers Option 1 (adding five codes and not making any
other codes obsolete) because it is less change and less work.
Option 2 involves adding the same five codes but also making
three codes obsolete. Susan reported that the U.S. map community
had no strong feelings in either direction. Priscilla asked if
anyone wanted to speak up in favor of Option 2. No one. Paul
Weiss moved that Option 1 be approved, and Larry Woods provided a
second. Seven members voted in favor of the motion and no one
voted against.
PROPOSAL 96-8/008-24,25 (Maps):
CanMARC has 39 prime meridian values, using both character
positions 24 and 25 for them. Six of the 7 USMARC prime
meridians are also in the CanMARC list, but with different codes.
Canada requests that the USMARC values for positions 24 and 25 be
abandoned and the 39 2-character codes in CanMARC be adopted.
Susan Moore explained that the prime meridian can be any
longitude, so the list of possibilities is almost infinite. She
reported on the MAGERT position: it is acceptable to drop
position 24. Unfortunately, LC cannot drop byte 25 because it is
used for duplicate detection and resolution. It must remain as
is. Paul moved to drop byte 24 but not byte 25. Larry provided
a second to the motion. Seven members voted in favor of the
motion and no members voted against it.
PROPOSAL 96-8/009:
Canada proposes to add Field 009 to carry detailed data on
Cartographic Material. It would be a detailed physical
description fixed field. Unfortunately, part of the data defined
in the Canadian 009 is currently already defined in other fixed
fields, as detailed in the Proposal. There was lots of
discussion and explanations about specific codes. For instance,
what is a landset image and how are they handled? Mary Larsgaard
explained that they are collected as digital data and then
printed out. UCSB has several million landsets coded as 007/04
"a". There was discussion about the separate supplement code
(008/25 "f") and bound with code (008/25 "g"). Betsy agreed that
they don't fit well, but they do occur and are needed. Paul felt
that the 007/06 codes and terminology were confusing. In
general, many felt that more analysis and information was needed.
Definitions could be improved upon, and it might be better to
hold back on a vote until the 007 issue could be fleshed out in
more detail. Priscilla asked for a straw vote on whether to vote
now or postpone. It was about even. Priscilla and Sally
decided to table the Proposal for the present.
*****************************************************************
Monday, July 8, 1996
*****************************************************************
Priscilla suggested that the Committee begin at the top and work
in order, skipping those proposals reviewed the day before. She
reminded everyone that there was no pressure to pass something at
this meeting, if more information would be helpful to the
decision-making process.
PROPOSAL 96-8/LDR-17:
Sally McCallum gave a brief introduction into the reasons for and
against a new encoding level code. Young-Hee explained why
Option 1 (adding value 3) is preferred by Canada. The
abbreviated level is lower than minimal level because no series
statement is included. Catalogers need this value as it provides
a signal to add information to bring the record up to the minimum
level. She went on to say that there is tremendous pressure to
catalog more with fewer resources, and the abbreviated level code
is a useful mechanism. Originally it was used for pamphlets and
ephemera but now it is used for all sorts of materials. She
emphasized that Option 1 is really preferred. John Attig
confirmed with Young-Hee that Canada is willing to convert some
records at the end of the harmonization process; in fact, the
cost to NLC and Canadian libraries will be very high based upon
what has already been agreed upon. Priscilla asked what
determines a USMARC encoding level; she pointed out that OCLC has
ENCL "i" and other non-USMARC codes. John Attig replied that it
depends upon whether or not a code is useful beyond one utility
or a limited user community. Young-Hee and others could see some
usefulness for value 3 beyond the Canadian community. Robin
asked for a quick summary of the differences between abbreviated,
partial, and minimal. Young-Hee provided the following details:
--Preliminary is used when an update of the record is
expected.
--Partial is used when distributing LC records to Canadian
libraries.
--Abbreviated is lower than minimal. NLC will not update
ever but other libraries may do so.
Betsy Mangan stated that the LC Map Division would find it very
helpful to have the value 3 added to the Encoding Level byte.
Paul Weiss saw a use in managing a cataloging workflow. He would
assign higher-level staff to value 3 records, since authority
control work may be required on these records. Sally asked Rich
Greene if OCLC has a similar code already; unfortunately not,
since most of the OCLC codes are variations on the current USMARC
codes. Catherine Gerhart agreed with Paul about workflow
management. Priscilla asked if anyone had a problem with adding
Value 3, if it wasn't for the system impact as detailed in the
Proposal. For the most part, no, except that different standards
might define Abbreviated differently and this could cause a
problem when records are exchanged. Rich added that a cataloger
may need to look at the 042 to see whose definition of
"abbreviated" applies to the cataloging record. Sally spoke
about the need to reconcile definitions for minimal cataloging.
Bonnie Dede spoke up for convenient access to each definition,
perhaps in a USMARC appendix. Others felt it was more
appropriate for the USMARC codes to be generic, and that utility
or system documentation should be specific. Priscilla agreed
with Bonnie that it was easier to manage abbreviated records if
they do have a unique encoding level. In that sense, most people
were in favor of Option 1.
Priscilla Caplan then asked the Committee to discuss the issues
raised in the impact statements. Rich Greene reported that it
would be a very painful process for OCLC to add any new encoding
levels because the byte is used extensively throughout the
software. The work for value 4 (Core Level) is not yet done; in
fact, if value 3 is passed, OCLC would probably do both together.
Young-Hee asked if OCLC could drop "3" records until the new
encoding level was programmed. Rich confirmed that this could be
done without much effort. Young-Hee reported that NLC is even
now releasing "3" records; it is unknown how LC processes them.
Perhaps they are dumped and not distributed to USMARC record
subscribers. Sally asked if OCLC would want libraries to input
"3" records, if the value was passed. Yes, Rich said, since OCLC
libraries might also find the code to be useful for workflow
management. Priscilla asked other systems for comments. Joe
Altimus reported that RLG was comfortable with adding value 3 to
byte 17 of the Leader. Marti Scheel reported that the National
Library of Medicine supports the change. Michael Johnson,
representing MicroLif, felt that some if not many system vendors
would find the additional code to be useful. Priscilla summed up
by saying that people are generally in favor. Adding the new
code is hard for OCLC to do, and more information is needed from
other systems who might have some difficulties.
PROPOSAL 96-8/007-02: The usefulness of the codes for facsimile,
original, and reproduction has been questioned now that more and
more bib records are merged. Also the values have been difficult
to distinguish. Sally said that U.S. practice has been in error
in the past, whereas the Canadians did not make the same mistake.
Young-Hee said that Canada would accept either option. Rich
asked for clarification on the end result of the two options.
Basically, byte 02 would end up with a different definition
(blank versus obsolete). Paul supported Option 2; he trusts
catalogers to stop using an obsolete code; there is no system
effort to change existing records with any obsolete value. After
more discussion, Paul moved to accept Option 2. Robin provided a
second to his motion. There were five votes in favor of the
motion and no votes against it. PROPOSAL 96-8/008-39: Sally
explained that NLC would like a unique Cataloging Source value so
that NLC records would not be considered to be LC records. Three
options are given in the Proposal:
--Option 1: "f" for NLC
--Option 2: result is a simplified set of values
--Option 3: more generic set of codes
Young-Hee reported that Canada prefers Option 1, but could live
with Option 2. Option 3 involves too many changes. Marti Scheel
reported that NLM has used the "b" code consistently since 1993
and does want to retain it. Michael Johnson wondered if the list
of national libraries will keep expanding in the future. Paul
suggested making the byte obsolete, since the codes have been
used inconsistently in the past and usefulness is minimal at this
point. Rich Green reported that OCLC uses this byte a lot in its
software. Adding codes for new national libraries requires some
work, but not as much than if the code was made obsolete. Diane
Hillmann agreed with Paul. Bill Jones asked if Option 3 implies
you look elsewhere for the information. Sally replied in the
affirmative. Robin said Harvard would find Option 3 inconvenient
since the byte is used for system processing in combination with
the Encoding level byte. Gary Smith confirmed that it is not so
hard for OCLC to add new codes to byte 39, whereas it is harder
to change existing codes or make the byte obsolete. To others,
Option 3 seemed more rationale as more and more countries begin
to use USMARC (or IMARC as discussed in the Business Meeting).
Priscilla asked how catalogers use the code in their work.
Catherine said that it depends upon the system in use and what
fields display on a given screen; a cataloger may need to look at
the 040 field. The cataloging source code is very useful during
retrospective conversion of records. Gary Smith liked Paul's
suggestion to make the code obsolete. Sherman Clarke thought
Option 3 would be OK for first-level sorting of incoming
materials. Priscilla concluded that the Committee could not
settle on one of the three options at this meeting, but that the
discussion had been useful.
PROPOSAL 96-8/008-24-27:
Sally explained that NLC proposes adding codes for Theses and
Treaties to the Nature of Content byte. Young-Hee had no
comments. Bonnie requested two editorial changes: The definition
for the "m" code should be "theses" and the definition for the
"j" code should be "patent documents." Rhonda Lawrence pointed
out that most U.S. treaty sets are serial records and that some
universities have "best thesis" series. Since the Nature of
Content byte has been in alignment for the most part with bytes
24-27 (Serials), this raised the issue of adding the same codes
to the Serials bytes. Randy and others pointed out some ways
that the two lists have not been in perfect alignment: some codes
are obsolete in one list but not in another list, "z" is defined
inconsistently, etc. Larry Woods moved that codes "m" and "z" be
approved for both books and serials, with the editorial changes
suggested by Bonnie. Paul Weiss made a second. Six MARBI
members voted in favor of the motion and no members voted against
it.
PROPOSAL 96-8/008-33:
Sally introduced the Proposal by saying that USMARC has in past
had an on/off byte for fiction, whereas CanMARC has had the same
on/off code as well as specific genre codes for the Fiction byte.
The proposal is to make values 0 and 1 obsolete, and to add
various "alpha" codes for various genre. An impact comment
pointed out that mapping from the old codes to the new codes
would be impossible by machine. Young-Hee pointed out that the
current list of Canadian codes is closer to what is used in
UKMARC and UNIMARC. Larry Woods and John Attig expressed concern
about the "scope" of the byte; to what extent should genre codes
be assigned here? Larry felt there was too much mixing of apples
and oranges. Bonnie Dede agreed that the new codes clouded the
Fiction description of the byte too much. She asked if the
Nature of Contents code might not be a better place for the
Canadian codes. Sally discussed the trade-off between fixed
field codes versus variable field codes or phrases. True codes
seem to work better in international usage. A British attendee
reported that the UKMARC codes for various genre in this byte
have been assigned to records in the BLAISE system and are used
for UKMARC users for retrieval. Sally asked if there was any
known difficulty with the overlap in definitions. Perhaps a
little during training but it generally doesn't seem to be a
problem. Short stories is viewed to be a form of fiction, but
the unique code is useful in a practical sense. Rich Greene
expressed mix feelings, although he understands and wants to
support uses outside of the U.S. He believes that the Brazilians
see this byte, as currently defined, as a problem in their use of
USMARC.
Paul remarked that the ALCTS SAC Form/Genre Subcommittee worked
on a coded list, but decided that text or phrases worked better
in the end. He suggested retaining "0" (Not Fiction) and "1"
(Fiction). He expressed concern about code "m" (Miscellaneous)
and preferred a definition of (Multiple Forms) for "m" with
another code for (Other). Catherine suggested using "u" for
(Unknown) instead. Someone else preferred using the fill
character rather than a pound sign for (Non- ficton).
The Proposal was amended as follows: Retain codes "0" and "1"
and add "type not further specified" to each definition. Make
"#" ("Non-fiction") obsolete in CAN/MARC so that Canada will not
have to convert records if not desired. Change the definition
for "f" to "Novels" (not Non-Fiction) and value "m" from
"Miscellaneous info" to "Mixed forms." Paul moved to pass the
amended Proposal. There were seven votes in favor of the motion
and no votes against it.
PROPOSAL 96-8/008-18-19:
Canada requests that three codes be added to the list of Form of
Composition bytes; this is Option 1. Option 2 proposes making
these bytes obsolete. The three proposed codes do not present
problems for those already coding and the Music Library
Association is in favor of Option 1. Paul questioned the "sd"
(Square dance music) code, since square dance music is not a form
of composition even if the call is embedded. Karen Little agreed
with Paul. The music community realizes that the field is a
mess: the definitions are inconsistent and the code list is
incomplete. However, overhauling the whole list is not feasible
and allowing new codes for those who want them is the best course
at this time. Larry moved to approve Option 1. Sandra Lindberg
provided a second. There were seven votes in favor of the motion
and no votes against it.
PROPOSAL 96-8/008-23-27
There is a typo in the Proposal; there are five bytes in this
field, so attendees were asked to change "24-27" to "23-27."
Sally explained that the bytes are defined for accompanying
matter for visual materials, especially archival motion pictures.
LC does not use currently. It is known that the UCLA Film
Archives does not use. It is unknown whether the field is used
in other USMARC systems. CanMARC defined byte 23 for "Form of
Item" and left only four bytes (24-27) for "Accompanying
Materials." Sally summarized the three options in the Proposal:
change American values to Canadian values, add Canadian values
but leave American values alone, and make the field obsolete.
Young-Hee reported that Canada did not consider the obsolete
option, and she would like to take this back for discussion.
Maureen Killeen reported that, in a sample of 20,000 Canadian
records, only 6% had these bytes coded. Paul thinks that the 006
and other places in the MARC record are a better place for
Accompanying Materials codes. Rich Greene reported that OCLC
staff prefer the obsolete option; the other options would be hard
to do. Gary Smith added that since you can't tell when something
is coded by a cataloger, you can't switch your list of codes
mid-stream. Priscilla asked if others agreed that Option 1 is
not viable. Yes, there was agreement. Young-Hee asked the same
question about Option 2, because Canada didn't think it was
viable. John Attig suggested that there not be a vote today.
Let the bibliographic community discuss Option 3 is more depth.
Sally agreed to re-write the proposal, favoring Option 3.
PROPOSAL 96-8/016:
CanMARC has field 016 defined for the NLC record control number;
it is comparable to field 010 used for the LC record control
number. It is the citation number in Canadiana. This Proposal
has three options:
#1 Add the 016 field for the NLC Control Number.
#2 Change field 010 from LC Control Number to National
Bibliographic Agency Number and add $2 for the code or name of
the agency.
#3 Make both 010 and 016 obsolete. Use field 015 for National
Bibliographic Agency Control Number, with undefined indicators
and subfields $a and $z.
Young-Hee reported that Canadian systems process this number
extensively. Field 015 is also used a lot and the numbers vary,
so she believes that it would not be good to go with Option #3.
Priscilla proposed another option: use 016 with a $2 to show
bibliographic agency. She thought generalizing a new USMARC
field would be best in the long run. John likened this idea to
the 035 field, and Young-Hee agreed. Another stated the 035 is a
junkyard. Paul felt the easiest solution is to define the 016
and have a blank indicator for NLC and other indicators for other
agencies. A visitor from the United Kingdom reported that the
016 is used in UKMARC to show authority control in a bib record.
Priscilla pointed out that there is no option that won't require
conversion by someone.
Paul moved to accept Priscilla's suggestion. Define 016 as a
national library control number. Assign the blank indicator to
NLC. Define the 7 indicator to refer to a $2. Define subfields
$a, $z, and $2. Use the NUC symbol in the $2. There was more
discussion about the name of the 016, and there was some concern
about the 015 field. It was agreed to develop this new option in
a second Proposal. Paul withdrew his motion.
PROPOSAL 96-8/028-Ind 2:
Sally introduced this Proposal and stated that the problems here
are very difficult. CanMARC overlaps with and reverses values
from USMARC. Another complicating factor is the fact that some
libraries still use these USMARC codes for printing added entry
cards. The Proposal gives two options:
#1 Redefine into in/off display of the note.
#2 Retain the USMARC values unchanged.
Karen Little reported that the Music Library Association wants to
retain the ability to distinguish and maintain an 028 as an added
entry. Marti Scheel reported that NLM supports this position,
and prefers Option 2. Kathy Bales suggested adding two new codes
with the Canadian definitions. Young-Hee pointed out that this
defeats the goal of harmonization, and John pointed out that
record conversion would still be necessary. Paul reported that
his system uses this indicator for indexing and display. John
supported the MLA position, that libraries printing cards should
not be forced into printing unneeded cards and then tossing them.
Young- Hee stated that it would be an expensive conversion for
Canada, if the USMARC codes are imposed on them. Priscilla
didn't think the conversion would be so difficult. Rich was
concerned that card production would be a mess if the meaning of
the codes was reversed in some records but not all. Maureen
reported that ISM's position is neutral on the two options; ISM
does use this indicator for printed products but also USMARC
records are allowed in the ISM database now. Priscilla said that
perhaps the only way to be fair here is to make the field
obsolete and start all over again. The consensus was to revisit
this Proposal at the Midwinter meeting.
PROPOSAL 96-8/082-Ind 2:
In the Dewey Decimal Number field, it is proposed to add one
value and adjust the existing ones as follows:
0 Assigned by LC Dewey agency
1 Assigned by other national Dewey agency
4 Assigned by other agency.
Sally reported that the LC Dewey Office likes this proposal. To
be able to distinguish who has assigned a Dewey number is useful
in several ways: for teaching in the field, for promoting
consistency in the assignment of numbers, and for automatically
generating mappings between LCSH and Dewey numbers. John was
not sure that the proposed Indicators of 1 and 4 would be
helpful; Rich reported that it did help in a large database of
shared records when multiple agencies assign Dewey numbers.
Young-Hee suggested that an alternative would be to let a blank
mean "Not Specified." If this were done, Canada would not have
to convert records. Sally said that blank had the "Unspecified"
before and that it is now "Obsolete." This could be withdrawn.
Priscilla asked if there were any objections. No. Any more
discussion? Sherman asked about Dewey-like numbers and Young-Hee
explained they were handled in the 082 field. Paul moved to
accept the Proposal and to re-activate the blank code. Another
member provided a second. There were seven votes in favor and no
votes against this motion.
PROPOSAL 96-8/085
Canada requests a new field to carry the CODOC shelving number
that is applied to Canadian federal and provincial government
documents in Canada. It is a variable-length code consisting of
alphanumeric characters. CanMARC currently uses the tag 088 for
the CODOC number and is willing to change since it conflicts with
the field 088 (Report Number) in USMARC. Sally explained that
the CODOC number is like the government numbers in field 086 but
it is assigned by non- government agencies and is a local schema.
Two options are presented:
#1 Use field 085.
#2 Use field 084.
Young-Hee reported that Option 1 is preferred because conversion
will be much easier. The 086 was considered by the Canadian
community but there are some subtle differences. The CODOC
number is generated by the library cataloger, instead of being
assigned by a government agency like the SUDOCS number is
assigned by the Superintendent of Documents. Sally said it would
be possible to redefine the 086 definition, if people wanted to
consider the 086 as a third option. Young-Hee thought that
indexing could be a problem in systems, if the CODOC number was
added to the 086 field. Diane Hillmann liked the 086 option,
since the number sounded to her like a SUDOCS number. Robin and
Priscilla disagreed; they thought it was closer to an 084 number.
Diane Hillmann and others expressed concern regarding Option #1,
from the point of view that it is not a good idea to assign a new
field tag in a limited circumstance. It was agreed that more
information is needed on the assignment of CODOC numbers by the
Univ of Guelph cooperative project. Sally suggested that this
Proposal be postponed until Midwinter while she and others did
some more analysis.
PROPOSAL 96-8/9XX:
Sally introduced the topic of CanMARC 9xx fields and referred to
the remarks on Saturday by Ingrid Parent. These are not really
local fields. They are legitimate names, uniform titles, and
cross-references in equivalent French and English forms. The
data logically resides in authority records, but is needed in
bibliographic records if a local system has no authority control
module. Unfortunately, the CanMARC 9xx fields conflict with
USMARC local fields.
Young-Hee explained that Canada is a country with two official
languages, and that this condition creates specific bibliographic
needs. Unilingual publications are cataloged in the language of
the item but include subject headings in both English and French.
Two separate records are created for bilingual publications with
the English language record carrying English subject headings and
the French language record carrying the French subject headings.
This is a very sensitive subject politically. Years ago, Canada
selected the 9xx fields for equivalent headings in order to not
conflict with USMARC.
Paul asked why cross-references are included, since these are not
language driven. Young-Hee said that it is the legacy of the
past; it may no longer be done, but there are still records with
9xx cross-references.
Priscilla reviewed use of 9xx fields in USMARC. If a single
library or system defines, this is OK. If a group of libraries
agree to use locally, this is OK. She suggested that we look at
the Canadian practice in the same way. Information about the
Canadian 9xx fields must be distributed, and each system would
decide what to do with incoming 9xx fields. The question becomes
how to document. Young-Hee had some concerns about this
approach, because, in CanMARC, 9xx are not local fields. Also,
who would be the maintenance agency for the documentation? Under
Option 1, it would be USMARC. Under Option 2, it would be NLC.
Paul felt that there is a better way to deal with translated
data, and that treating the Canadian 9xx like local fields does
violate USMARC principles. Bonnie agreed. The bibliographic
community needs to gear up to better serve users with different
primary languages. She suggested MARBI work on some longterm
solutions for the bigger issue.
John asked, if Option 1 (CanMARC 9xx documented in the official
USMARC documentation) is selected, would Canada expect U.S.
systems to load and process? Young-Hee said not at all. It
would be published for the information of those receiving the
equivalent language fields, but these fields could be dropped
before loading. Michael Johnson observed that it would be
impossible for vendors to support different local fields when
distributing records. Young-Hee repeated her suggestion that the
fields be deleted before loading into U.S. systems. Priscilla
pointed out that Canada will continue to use 9xx fields. The
practical issue at hand is how to handle the documentation. John
agreed. Young-Hee emphasized that the 9xx fields are part of the
CanMARC standard, and will become part of USMARC after
harmonization is completed.
Paul did not like Option 1 because, in his view, it would set an
unfortunate precedent. He felt that the CanMARC use of 9xx
fields is no different than OCLC's documentation on 9xx fields.
Catherine said that as a cataloger she has been fighting for
authority control modules in local systems for a long time. She
did not want to open the door to having authoritative name fields
in bibliographic records, even if these are equivalent fields
only. John said that Canada is now paying a price for having
solved an important problem using the tools available at the
time. It is now time to look to the authority format to control
multi-lingual terminology.
Priscilla suggested that it would be good to follow the Internet
Metadata approach. Establish a 9xx registration process, so that
more information is available in a central place. Sally agreed
completely and suggested that it would not be hard to publish
registered 9xx definitions on the USMARC home page.
Sally and Priscilla asked if there were any further comments.
No. It was agreed to defer the rest of the CanMARC authority
proposals until the Midwinter Meeting in February 1997.
Discussion is encouraged on the USMARC list in the meantime.
Library of Congress