MARBI Members:
Priscilla Caplan LITA Univ of Chicago
James E. Crooks RASD UC Irvine
Shelby Harkin ALCTS Univ of North Dakota
William Jones LITA New York Univ
Gary Strawn ALCTS Northwestern Univ
Flo Wilson ALCTS Vanderbilt Univ
Larry Woods LITA Univ of Iowa
Jacqueline Riley RASD Univ of Cincinnati
MARBI Interns:
Josephine Crawford ALCTS Univ of Wisconsin
Paul Weiss ALCTS Nat. Lib of Medicine
Representatives and Liaisons:
John Attig OLAC Penn State Univ
Jui-Wen Chang RLG RLG
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
Karen Little MLA Univ of Louisville
Sally McCallum LC LC, Net Dev/MSO
Susan Moore MAGERT Univ of Arizona
Young-Hee Queinnec NLC NLC
Marti Scheel NLM NLM
Sushila Shah AV Committee Macalester College Lib
Patricia D. Siskin ARLIS Frick Art Ref Lib
Stuart Spore AALL NYU Law
Rutherford Witthus SAA Univ of Colorado
Other attendees:
Hiroko Aikawa Cleveland Public Library
Joan Aliprand Research Libraries Group
Melissa Becker FLICC/FEDLINK, LOC
Elizabeth Black University of Toronto
Candy Bogar DRA
Lori Bronars Yale University Kline Science Library
Suzanne Bureau CISTI, Ottawa, Canada
Kevin Butterfield Univ of Michigan
Sylvia Carson Penn State University
Ann Case H.W. Wilson Co.
Ho-chun Chin Research Libraries Group
Sherman Clarke Amon Carter Museum
Karen Coyle Univ of Calif Division of Lib Auto
Alan Danshin British Library
Carroll Davis Columbia University
Stuart Ede The British Library
Marcia Evans University of Alabama
Laine Farley Univ of Calif Division of Lib Auto
Patti Page Fields FLICC/FEDLINK, LOC
Lori Franz Univ of Michigan
Linda Gabel OCLC
Nancy Greene Univ of Wisconsin, Madison
Julie Grygotis Univ of Michigan, Ann Arbor
Robert C. Hall, Jr. MIT/Concord Free Public Library
Stephen Hearn Univ of Minnesota
Norma Hendrickson Library of Congress
Elaine Henjam Florida Center for Library Automation
Diane Hillmann Cornell Law Library
Lynne El-Hoshy Library of Congress CPSO
Bruce Johnson Library of Congress
Mary Larsgaard Univ of California, Santa Barbara
Fay Leibowitz Univ of Pittsburgh
Debra J Leslie Library Company of Philadelphia
Sandra Lindberg Broomfield, Co.
Kathryn Loadman Univ of North Texas
Elizabeth Mangan LC G&M
Ralph W. Manning National Library of Canada
Catha D. Massey Univ of Georgia
Susan Oros Research Libraries Group
Cecilia Preston ----
Holly Schmidt Blackwell North America
Kathy Schmidt Univ of Wisconsin, La Crosse
Jacque-Lynne Schulman NLM
Carolyn Sherayko Indiana University
Ann Sitkin Harvard Law School Library
Gary Smith OCLC
Elisabeth Spanholt State Library of Louisiana
Steven Squires Univ of North Carolina at Chapel Hill
Barbara Story LC
Jennifer Swede Univ of Pennsylvania
Pat Thomas Stockton-San Joaquim Co Pub Library
Sarah Thomas LC
Cecilia Tittemore Dartmouth College
Diane Vizine-Goetz OCLC Research Office
Bob Warwick Rutgers University
Robin Wendler Harvard University
Lisa Wise NASA Center for Aerospace Info
Dolores Yang Univ of Michigan
MARBI Recorder:
Josephine Crawford University of Wisconsin
*****************************************************************
Saturday, June 24, 1995
*****************************************************************
Priscilla Caplan opened the meeting with introductions, a review
of agenda changes, and an announcement about the planned Unicode
meeting. John Attig asked why the Philadelphia minutes had not
yet been distributed, and emphasized that he finds the minutes to
be very important. Jo Crawford explained that a draft had been
completed but had not yet been reviewed by LC staff and Priscilla
due to an email snafu. Catherine Gerhart reminded the group that
it had been previously agreed to post draft minutes to the USMARC
list.
PROPOSAL 94-10 : "Encoding of Patent Information in the USMARC
Bibliographic Format"
Sally introduced this proposal and remarked that the proposal had
been improved due to the Midwinter meeting discussion. There are
fewer new data elements, and Linking Entry Fields are used. One
noteworthy change is the 013 $d which is a repeatable subfield
because of the different types of patent dates. A parenthetical
status has been added to give more meaning to the dates (e.g.
granted versus effective). It was suggested that the
parenthetical information should be published so there would be
consistency. Sally agrees.
Is there a reason to have a two-digit year? Sally reported this
is done to follow the ANSI standard; when it is revised, will
change to a four-digit year.
David Goldberg reports receiving patents with barcodes at the top
of the document. The barcode represents the U.S. Plan Patent
barcode. Would it be appropriate to include?
Paul Weiss stated that he is uncomfortable with the 013 since it
will run out of subfields and there is a break with the USMARC
principle of "one record, one document." John Attig is more
comfortable with the proposal because he sees patents as a
different animal; the proposal introduction explains that patent
documents range from the application document to the approved
patent document.
If this barcode is like a UPC, Young-Hee Queinnec reminded the
group there is a place for it in the format. Priscilla believes
more needs to be known about the barcode before deciding what to
do about it. She isn't so concerned about the scarcity of
subfields as Paul. It was agreed to treat the barcode in a
separate proposal if it can't be treated like a UPC.
Priscilla asked about the 013 $c (Kind of Document), questioning
that either a term or a code could be input. However, there are
other precedents for this (such as NUC codes in the 040).
The codes are published though in the WIPO standard.
Paul Weiss asked about the relationship between the 013 $b, the
260$a, and 008/15-17; in the example on page 10, there is
an inconsistency. Sally explained that 013 $b is the country
corresponding to the number in 013 $a. Acknowledging the larger
issue of consistency between dates in variable fields and those
in fixed fields, John Attig pointed out that the utilities do not
require the two to be the same. Priscilla clarified that the 008
has the date of the document, whereas the 013 has different
processing dates (e.g. date of receipt of patent application,
date patent granted, etc.).
Paul questioned whether or not the 013 $a (Number) doesn't more
appropriately belong in a linking entry field of a related
record. It was pointed out that there may be multiple times that
a patent document is filed by an inventor. Both domestic and
foreign applications are made; therefore, the numbering and
country must be separate. Is the publisher the patent office of
each country? Should there therefore be different records for
different countries? Or, should 013 $b be repeatable when the
patent goes to different countries; under this approach, the
defining characteristic of the 013 is the number. Sally plans to
review this issue with Randall Barry.
It was suggested that the documentation be more specific in
regards to the relator terms in 700/710 $e, whether or not a term
or a code, and how to standardize.
John questioned placing the qualifying information in
parentheses. An alternative would be to make the $e repeatable.
Priscilla is not sure that the $e necessarily applies to the
date. Paul agrees with John and likes repeating so that the
history is kept together. One solution is to couple $d and $e
together when appropriate with both repeatable. It was agreed
that there is ambiguity regarding the date, the date
qualification, and the status.
If there are no fatal flaws to the proposal, it was suggested
that the proposal be approved, so that patent libraries can use
and see how it stands up. Paul suggested provisional approval,
due to unresolved issues. Young-Hee pointed out that once
records are created in databases, provisional approval is
somewhat meaningless.
COMMITTEE ACTION : Flo Wilson made a motion to accept the
proposal as presented. The motion was seconded by Larry Woods.
The motion passed, seven to zero. Sally will pursue the
unresolved issues.
---------------------------------------------------------------
PROPOSAL 95-13: "Improved Coding for Citation Data in Field 524"
Stuart Spore (AALL) discussed the proposed changes to field 524:
make it repeatable, add $2 for Source, and add $3 for Materials
Specified. Priscilla asked if there has been much use of 524 to
date; Stuart believes that the archival community has used.
Young-Hee Queinnec informed the group that Canada supports the
proposal; one suggested change though is to precede the year with
a slash in the $2.
There is no authoritative scheme (as of yet) for codes
representing the citation source, but LC would publish one if
this proposal is passed. In the case where there is no $2,
Priscilla wondered if one would assume that the source is the
publisher-- yes, or else, have a publisher code. Rutherford
Witthus (SAA) pointed out that AMC format users leave out the 260
field, so a "local" code would be used (present in several code
lists already). Agreement: Do not put in a $2 unless there is a
code from the authoritative list, or there is a "publisher" code,
or there is a "local" code.
It was suggested that "preferred" should be dropped from the name
of the field, once it becomes repeatable. Several agreed since
there are a number of competing source schemes for legal
materials. However, will this confuse the archival community
since they may be using the field from the point of view of
"preferred form of citation." A compromise is to leave the name
the same but explain in the documentation, especially since name
changes do cause much effort as they must ripple through all the
network's documentation, even in its briefest forms.
Paul Weiss sees some errors in the examples, which he will turn
in. Flo Wilson made a motion to accept the proposal based upon
the discussion. Seconded by Shelby Harkin. Seven members voted
in favor; there were no votes against.
-----------------------------------------------------------------
PROPOSAL 95-6 : "Linking Code for Reproduction Information in the
USMARC Bibliographic Format"
Sally introduced 95-6 by stating that handling reproductions or
multiple versions is a continuing discussion, with progress
towards a usable solution. The $8 is a method of checkmarking
reproduction information buried in a record with both original
and reproduction descriptive data. Sally also noted that RLG
posted some good questions on the USMARC list, especially whether
or not the $8 should be defined across all variable fields,
including the 533.
John Attig recollects past discussions where a number of people
felt that it was preferable to use regular fields for
reproduction descriptions rather than using the 533. Involves
redefining the concept of repeatability (i.e. 245 field). John
would very much like a good analysis with pros/cons before MARBI.
Priscilla felt that the discussions leaned towards using the 533
as defined now. Bruce Johnson remembers a preference for the
"full-record technique", but certainly not a consensus. He
agrees with John that the proposal should flesh this out in more
detail before moving forward. If this technique is approved,
will it be mandatory or not; John Attig feels a decision is
important.
Sally McCallum reported though, that LC has a large number of 533
fields and would not split them out into 245, 260, etc.
retrospectively. Nothing is clear cut: Robin Wendler reminded
the group that the series statement is an access point and
therefore needs to go into the 440 or 7xx. Bruce agreed that it
is not possible to record all reproduction descriptive elements
in a 533 field; those data elements requiring indexing should not
be placed in a 533 given most systems.
Is the 533 field adequate in many or most cases? Unknown. There
seems to be two possible approaches:
1) Break out into all regular fields, with $8 linkage.
2) Use the 533, plus a few other fields when the 533 does
not have a defined subfield for the data element.
Paul Weiss believes that there may be display problems, because
the 533 is not comprehensive enough, with the second approach.
Young-Hee Queinnec is also concerned that the result will be a
mixed-up record. Canada describes the reproduction in a 534
field where there is a $t. Perhaps add this to the 533? Sally
stated that the $8 technique is so powerful, it is important to
understand the implications of each approach. Others agreed.
Bruce urged a resolution to the multiple versions problem, given
the years of discussion. He reminded the group that there is a
great number of complaints about current approach.
John Attig brought the discussion back to the purpose of the
proposal. He speculated that local systems want to be able to
create a subrecord for reproductions, to hang off the original.
Priscilla said she is hearing less and less discussion about
separate records for original and reproduction, and more
discussion about a master record with both. If a local system
wants to extract the reproduction information to place into a
subordinate record, she thinks the $8 technique will work. The
Airlie House proposal suggested subordinate holdings records, but
it was too hard for the utilities to implemement. This proposal
gives local systems a tool to handle reproductions as preferred
in the local system.
Josephine Crawford explained the use of the master record
technique at the University of Wisconsin-Madison. Reproduction
information is added by hand to the bibliographic record of the
original (a 533 field and other bibliographic fields like a
series added entry); then, the holdings record has the 007 field
for the reproduction as well as the enumeration/chronology fields
if appropriate. The $8 technique would allow more precise coding
in the bib record, making it possible for a local system like UW
to make improvements to display, indexing, and output programs.
Cornell University does something similar. Diane Hillmann had
posted an example on the USMARC list where she repeated the basic
fields and marked them with the $8; she did not use the 533
field. However, she sees the need to grandfather in existing 533
fields. She also noted that she did not deal with the 007 field.
Don't the records get real long and hard to read when different
reproductions are posted to the bib record for the same original?
Yes, indeed, although Jo Crawford noted that the $8 linking
technique could be used by a system to put up an understandable
display for the cataloger. Examples posted by Sherman Clarke
kept together the fields relating to a particular reproduction.
[Clarke's Federal Register example describes 11 different
reproductions, for partial serial runs.]
Paul Weiss reported that NLM just wrote a specification for
distributing one record with both original and reproduction data.
The 533 field is assumed. The 007 for a reproduction can be in a
holdings record.
What about repeating 245 fields, with a $8? Rich Green discussed
everything OCLC would have to do if the 245 became repeatable.
It was agreed to not get into this, given that current systems
cannot handle repeating 245 fields at this time. It was also
pointed out that usually the title of a reproduction is not
different from the original.
The question was then asked which fields can have a $8? It was
agreed that all except the fixed fields and the 245. But, what
about fields with matching 533 subfields? Should it be mandatory
to use or not, or be flexible either way? Flexibility means we
could perhaps grandfather in existing 533 fields, but with
movement away from the "limited" 533 field. Diane Hillmann asked
the group to support catalogers in pushing the state of the art,
so that cataloging can remain relevant to users' needs. She
applauded the frequent use of repeating fields in the AMC format.
No consensus developed at the meeting; technical analysis is
needed because MARBI does have to worry about impact on
databases. Bruce Johnson pointed out that the issue is smaller
if system designers have two specific approaches to handle,
rather than complete inconsistency in databases. Rich Greene
stated that OCLC is taking the narrow point of view, because the
533 is already used by some programs.
Several straw votes were taken at this time. Everyone in the
room was invited to participate.
-- Can you live with a requirement to use the 533 field,
except in those cases where a subfield does not exist for the
data element (in which case, use the regular field with a $8)?
31 people voted yes, no people voted no.
-- Or, would you prefer for the option to do either? Only
nine people voted yes.
-- How many people prefer NOT to have the option? 14 people
voted yes.
Based upon the straw vote, it was agreed to bring a new proposal
to the San Antonio meeting where the 533 field will be required.
The proposal will list the fields where $8 with an "r"
reproduction code is NOT allowed. The proposal will also analyze
pros/cons of the following:
1) code $8 if 533 only field with reproduction data?
2) if both $6 and $8 present, what should the order be?
3) deal with the GMD in the 245 field.
4) deal with multiple 007 fields.
5) deal with use of $3.
It was also suggested to add a local system example where the
"master bib record" approach is used rather than cloning. Should
show what is brought in from a utility as well as what is
exported to another utility or a union list.
-----------------------------------------------------------------
PROPOSAL 95-8 : "Define Field 856 (Electronic Location and
Access) in the USMARC Classification Format"
Sally introduced by saying this proposal is a straightforward
request to add the 856 field to the classification format. The
purpose is to provide a link from a USMARC class record to a
related electronic resource. For instance, where a visual aid of
some sort acts as a guide to the classification number. LC is
exploring placing such files on a WWW server, adding a URL to the
classification record, and then providing direct access from the
classification record to help catalogers work effectively.
John Espley pointed out that it is also necessary to add the 856
field to the community information format, in a separate
proposal.
Young-Hee asked if a link to the image file of a document should
be placed in the bib record or a classification record?
Conceptionally, the classification record is preferred. However,
some systems like VTLS are putting these kinds of URLs in the bib
record. It was agreed that this proposal is dealing with a
different situation, linking to an "appendix" of the
classification schedule. A pointer, not really a location.
COMMITTEE ACTION: Flo Wilson moved to accept the proposal as is.
Gary Strawn seconded her motion. There were six votes in favor,
and no votes against.
*****************************************************************
Sunday, June 25, 1995
*****************************************************************
PROPOSAL 95-12 : "Change Subfield $v (Record Control Number) to
$u in USMARC Authority Format"
Rebecca Guenther introduced this authority format proposal, which
has been prompted by the decision last winter to establish a $v
for form/genre in subject heading fields. There are two
components to the proposal:
1) Change the Record Control Number from $v to $u.
2) Define $v for form/genre subdivision in 7xx linking entry
fields.
The issue addressed is whether any systems have been using the $v
for the record control number. Gary Strawn reported that
Northwestern has used the field alot, but never this subfield.
LC, OCLC, and Blackwell representatives also reported no use of
this subfield.
Gary Strawn moved to approve the proposal. There were several
seconds. Six members voted in favor, and no one voted against
95-12.
-----------------------------------------------------------------
PROPOSAL 95-10 : "Making Field 755 obsolete in the USMARC
Bibliographic Format"
Rebecca introduced this proposal, referring to the earlier
discussion paper (DP 82). It has proved difficult to distinguish
between the 655 and 755 fields in practice. Given the discussion
at Midwinter, it was originally thought to have an electronic
vote. However, there was one person who wrote against the
proposal on the list, so it will be voted on in person where
there is more opportunity for discussion.
Marti Scheel asked if $a is repeatable or not. It is not
repeatable (the error in the March '94 USMARC documentation will
be corrected).
Gary Strawn made a motion to pass the proposal as is. Bill Jones
seconded the motion. Six members voted in favor, and no members
voted against it.
----------------------------------------------------------------
PROPOSAL 95-11 : "Definition of X55 Fields for Genre/Form Terms
in the USMARC Authority Format"
Rebecca briefly reviewed the long history of this proposal. At
the last meeting, people were leaning toward new fields, rather
than use of the 008. LCSH work is underway on the issue of dual
use headings (e.g. Artists books can be used both as form and as
topic). The proposal presents two options:
Option #1: Separate authority records for dual use, defining
155, 455, 555, and 755 for genre/form headings
Option #2: Single authority record; use X55 for genre/form
only terms and X50 with 008/18 for dual use headings.
John Attig asked if he is correct in assuming that Option 2 is
preferred by LC due to existing authority database. LC is
examining whether there should be disambiguity upfront.
Apparently Barbara Tillett prefers two records, but there has
been no official decision pending final analysis.
Gary Strawn asked, if Option #1 approved, should 008/15 be coded
appropriate for use as subject (???). Redefine subject or genre?
Sally doesn't think so. Bill Jones says that the code really
means that the heading can be used in 6xx fields.
Marti Scheel reported that NLM favors Option #1, believing that
there would be maintenance problems with Option #2.
Young-Hee Queinnec sees some possible disadvantages with Option
#1: duplication in indexing (unless indexed together); users
having to search in both places (if indexed separately). Bill
Jones implemented this in his system and has no problem with
duplicate strings because the indexing is based upon the field
tag. John asked if duplicate records cause confusion on
displays? No, because indexed separately.
Pat Thomas preferred two records so that scope notes will be on
the appropriate record to explain the different uses.
Priscilla sees a preference developing for Option #1. Is anyone
else supporting Option #2? No. The group asked that the
sentence be deleted about having to create two records and leave
that up to the thesaurus.
Stuart Spore would like to see a provision for faceting,
modifying descriptors. Perhaps in 7xx to correlate AAT and LCSH.
John finds this interesting because faceting puts together the
string in the record, even if each heading authorized separately.
Paul suggests a separate proposal to handle faceting, it is found
to be desirable. Sally and Priscilla agree.
Larry Woods moved to accept Option #1 of Proposal 95-11. There
were several seconds. Six members voted yes, and no members
voted no.
-------------------------------------------------------------
PROPOSAL 95-9 : "Encoding of Digital Maps in the USMARC
Bibliographic Format"
The purpose of this proposal is to create a better method for
handling digital maps in USMARC. It was introduced by Betsy
Mangan of LC Geographic and Maps Division. The current wording
for Leader Byte 6 is too restrictive; want to change wording from
"printed map" to "cartographic material." In addition, the
proposal calls for adding a digital code to 008/25. After Format
Integration, prefer for digital maps and paper maps to be handled
together, because the content is of primary importance while the
physical format is secondary. LC's database only contains 25
digital maps and these will be changed by hand, if the proposal
is approved.
Paul Weiss believes the proposal raises many, many issues. Not
sure if ready for approval. He would like to see MARBI look at
the whole picture of multiple formats post format integration.
Priscilla was not sure if it would have been better to do a
discussion paper first, because there is much support. Betsy
added that Project Alexandria is underway now, and Mary Larsgaard
from UCSB is here for the discussion. Special material
catalogers support this strongly, and request approval. Sally
said that the issue came up quickly, and she thought it would be
possible to act before looking at the larger issues.
John Attig thinks that data archivists will not agree with map
librarians. He thinks either choice is incorrect at this point.
There was some agreement to change the wording of value "e" in
Leader Byte 6. Then the proposal becomes an option, not a
requirement for catalogers. Paul pointed out that there are two
codes to consider: "e" for printed map and "f" for manuscript
map; he thought "g" for digital could be coded in the 006 after
Format Integration, but wanted to know what should be done about
the "f" code. Betsy thought that it would be ok to not retain
"f", because there are other ways to show the manuscript aspect.
If the "f" code is retained, it was suggested to change wording
to "manuscript cartographic map." The example to consider is a
digitized manuscript map.
Paul wondered about music codes "c" and "d" since the same split
of printed and manuscript occurs; he reminded the group that
changing the leader is tricky. Catherine Gerhart is concerned as
a practicioner; the computer file cataloger needs the whole
picture analyzed before changing practice. Mary Larsgaard from
UCSB believes that this is equally true for the map cataloger.
Users overall are interested in content, not the container.
Priscilla pointed out that Format Integration gives us a mixed
world. John thinks that we must work to see how to make acees
possible under both aspects, content and container. Need to
examine the uses made of the Leader.
Catherine brought the discussion back to the practical
implications for catalogers; what about the GMD in relation to
the proposed new code "g" in 008/25 (Tpe of Cartographic
Material). Apparently, the Joint Steering Committee for AACR2
will be looking at the basic concept of the base description of
form. A major change could be coming. Sally doesn't think we
should wait for these new cataloging directions. It is OK to
have an 008 that does not match the 245 GMD.
Larry Woods moved to approve the proposal with an amendment:
approve the wording changes in Leader Byte 6 (codes "e" and "f"),
but delete the change to the 008/25. Fields 006 and 007 can be
used to show computer file aspects. Gary Strawn seconded. Five
members voted yes, and no members voted no.
John Attig is very uncomfortable with solving the narrow issue in
this motion. LC staff agreed to write a discussion paper
addressing the broader issues. In addition, the question was
asked if LC will redistribute those 25 records after recoding
them.
---------------------------------------------------------------
DISCUSSION PAPER #87 : "Addition of Subfield $l (Uniform Resource
Locator) in Linking Entry Fields 76X-78X"
Rebecca Guenther introduced this discussion paper which is
related to DP#88 and DP#89. It is desirable to add a URL
subfield in the linking entry fields for cases when the
electronic resource does not have a separate bibliographic
record. The paper discusses a couple of options. Since the URN
Internet standard is moving along too slowly, it would be good to
do something in USMARC. Examples of both electronic books and
serials are given in the paper.
John Attig said that the USMARC principle is usually use one spot
only. Why not just continue with the 856? What is the status of
the URL? Priscilla said one should normally use the linking
fields to connect to other bib records. This is a link to the
object itself. Paul agrees completely; this is a major change in
the use of the linking fields. Representing two bibliographic
items in one record. But, Sally sees the linking entry field as
a citation referral, not two bibliographic descriptions.
Larry asked if the URL is for the item being described, or is the
URL for the item to which there is a link. The latter. Others
asked if the URL standard is stable. Some programs are under
development for automatic updating; maintenance issue here.
Rebecca is monitoring the URI lists and reported there are too
many competing URN proposals still. The URL is like a shelf
location, and the URN is like a control number. John summed up
his view by saying we are left with a piece of dynamic data which
could go in more than one place. Sally reminded the group that
often the linking entry field is the only place to put the URL
because the related record does not exist. Have to work in this
environment now. Weigh the different results for users of moving
ahead versus holding back. When people use linking fields, don't
they jump to the other record? Sally says not available in many
cases.
Some felt that if an object is worth pointing to, it is worth
creating a bib record for it. Jui-Wen Chang suggested using the
$l only when no related record exists; but then harder to
maintain when related record does get created. Young-Hee
Queinnec suggested a skeletal record with a URL as a practical
alternative. Bill Jones said the proposal is encouraging people
to create a complex record structure, on a changing situation.
Better to encourage a new bib record, and put the URL in the 856
of the second bib record. Stuart Spore suggested renaming the $l
to electronic citation where any URL could be input, until the
Internet standards settle down.
Rebecca pointed out that the URL seems similar to the accepted
practice of placing Record Control Numbers in the 76X-78X fields,
at least for the object linked to. But others felt that the
issue is whether there is any point in duplicating the URL in the
linking entry fields if already present in the 856 of its main
bib record, particularly because of the URL's transient nature.
Bill asked if systems will make automatic connections? Yes,
people believe this is happening and will happen more. John
Espley pointed out that many classic works are now out on the
Internet; would people add the URL to the linking entry fields in
all those bib records? Better to use the 856 in electronic
object's bib record. Paul agrees; the purpose of linking entry
fields is to link to other bib records.
Candy Bogar said that DRA systems staff is uneasy about programs
looking into various fields to make the Internet link for users.
Priscilla asked if users will be impatient if they have to look
up another bib record. Paul thinks that there is a system
architecture issue here; there could be a hot link to the other
bib record, with another hot link to the full-text. Michael
Johnson said that DataTrek is another vendor preferring the 856
approach. Stuart pointed out that as more and more versions are
available online, it is helpful to display a description before
making a link. Separate record better until URN standard
available. Sally asked how the user gets to the related record.
The DRA system uses the number in the linking entry field
(ISSN, ISBN, or Record Control Number). The VTLS system links
through the title in the linking entry field $t or uses a number
if there. In other words, whatever is indexable can be used.
Priscilla summed up the discussion by saying that creating a $l
subfield in the linking entry fields is not a good idea because
the URL is too unstable. The preferred method is to place the
URL in the bib record for the electronic item. The linking field
should point to this bib record.
MARBI did not support bringing this discussion paper back as a
proposal.
-----------------------------------------------------------------
DISCUSSION PAPER #89 : "Defining Field 774 as a Component Item
Entry Field in the USMARC Bibliographic Format"
This is a revision from an earlier discussion paper. Some RLG
libraries use a local 789 field, with links down, not up. Lennie
Stovel has mapped the 789 field to the 774 so that all libraries
could use this technique. Only one data element did not map (789
Subfield $i). The primary question is how to link the component
part. The discussion paper lists three options. Given the
earlier discussion, will throw out Option #1 (URL in linking
entry field). Option #2 involves using the $8 in the 856 and 774
fields; a link code would need to be defined. Option #3 suggests
using the Subfield $3 (Materials Specified) in the 856 field;
some kind of unique identifier would be recorded in both the 774
and 856 fields. A basic assumption is that, for some collections,
libraries do not want the overhead of creating separate bib
records, and yet want to make hot links.
Paul Weiss sees similarity with one proposed solution to the
multiple versions issue. Priscilla asked about AMC records.
Paul said describing as a set. John did not think the concept
was dissimilar-- a different type of contents note. Sally said
that we have a new generation of demands on bibliographic
control. We are dealing with new material types. Always had
problems with the linking entry fields. Used in systems for
additional access, rather than for real purpose.
Paul asked about the $i on page 6. The definition is a little
vague. There is flexibility so that it can be defined by each
specific project. Supposed to be an accession number, item
number, or file name; will probably be used for an actual link.
Priscilla asked if we really want to dismiss Option #1. The
maintenance issue still exists with the other options. She
prefers Option #1. Paul said that the sum of 856s is equal to
the 245; he sees a tighter bib record with Option #2. John
Espley asked if the 774 has some subfields not in the 856. This
was clarified: the 774 is a mini description field whereas the
856 is for location and access. Karen Little expects that there
will be 856 fields where a link with 774 would be appropriate.
Larry Woods suggested thinking about a union catalog, each
location with a slide.
Sally reminded the group that in 1980 a USMARC principle was
established that principle component parts should be described in
a new bib record. However, given evolving bibliographic needs
and the attempt to improve access through electronic means, the
774 field seems like a good idea to her. Paul agreed that it is
useful for serials where only some issues have titles and can be
analyzed.
After this discussion, there was agreement that Option #1 is not
acceptable. Each of the questions on page 8 were discussed in
turn.
1) How should the definition of component part be revised in
USMARC to include the applications detailed in this paper?
Remove "physical part" in the definition. Component part was
carefully defined in 1980, when separate record model preferred.
The USMARC terminology is different from AACR2 terminology. The
AMC people haven't followed the strict definition in USMARC.
Bill Jones reminded the group that the definitions are found in
the leader, so address this in Leader documentation.
2) Should any new data elements needed for field 774 (Subfield
$i and second indicator) be defined across the linking entry
fields or be restricted to this field? John Esley wondered
about the 787 field. Does the definition fit? Some say no, some
say yes. RLG comments on the USMARC list discussed the 2nd
indicator: define if additional display constants are needed.
"Component Part" suggested at the meeting, but it was also felt
this may not be understood by users. Won't work if there are
different uses of 774. Agreed to define the second indicator.
There was not a consensus about extending the 2nd indicator
across the other linking fields (some felt good idea to be
parallel, others felt to wait until there was a need).
3) Should field 774 be defined to include all of the subfields
of the Linking Entry fields 76X-78X? Yes. There will be more
uses than those described in the paper.
4) Which option is preferred for linking the 774 field to the
eleectronic item? Is it necessary to have more than one
technique depending upon the situation? Option 2 preferred by
many in the room. However, Young-Hee Queinnec stated that Canada
prefers Option 3 as being the least disruptive. Paul said that
the problem is when there is no $i. He suggests that both
techniques be acceptable in the proposal. Priscilla thinks
people can use Option 3 now. MARBI should approve Option 2 in
specific situations.
5) If Option 2 ($8 technique) is selected, should the subfield
$8 link code be defined across linking entry fields, across
bibliographic fields, or restricted to field 774? Can't fully
answer without more examples. Subfield $8 has been restricted by
type, not by field so far. Paul Weiss suggested looking at music
examples.
6) Is it necessary to sequence the 774 fields? No, not beyond
what is already available in $8.
7) Should the second indicator for Display Constant Controller
be used? Yes. In all 76X-78X fields or only field 774? Both
opinions expressed. Should other display constants be defined?
Perhaps.
-----------------------------------------------------------------
BUSINESS MEETING:
Bibligraphic Update #1 has gone to the GPO printer. Today's
changes will be folded into the Authority Format update. Final
edition of Format Integration document is out, and members will
receive copies. 29 classification schedules are done, with nine
to go plus proofreading and editing.
There have been internal meetings at LC on SGML within USMARC.
Want to draft a formal DTD. Need external funding to do this.
Year 2 of Format Integration is pretty much on schedule. If
there is slippage, will extend out to Jan or Feb. of 1996 only.
John Attig if there is any chance of an up-to-date concise?
Electronic Concise up to date except authority. All MARBI
proposals kept online with cover sheet showing disposition.
Marti Scheel asked if there is any more information on dates in
the 006 and 008 fields? Use of "u" in Date1 or Date2 (e.g.
19uu). Sally said they are working on it as quickly as possible.
What about Discussion paper #84 on 100 years of LCCNs? LC staff
prefer a short-term solution now, because there are lots of
records to load now.
Larry Woods reported on the Character Set Subcommittee. Will put
together another interim report and send out on the USMARC list.
Basic and extended latin script table is done. Also, three Greek
characters and subscript and superscript. Cyrillic, Hebrew, and
Arabic characters look easy to map because there are ASCII
clones. But have identified 10 characters in USMARC that are not
present in Unicode; will request that they be added to Unicode.
And, there is one Hebrew character that maps to two Unicode
characters, so have to resolve this conflict.
*****************************************************************
Monday, June 26, 1995
*****************************************************************
DISCUSSION PAPER #86 : "Mapping the Dublin Core Metadata Elements
to USMARC"
Rebecca Guenther introduced this paper, explaining that it was
written as a result of the Dublin "metadata" workshop held at
OCLC in March. The workshop brought together parties active in
the Internet, electronic publishing, and librarianship. The
result is a beginning: 13 optional core data elements to be
supplied by the creator of an electronic resource (called "Dublin
Core"). These data elements all are repeatable (although more
specific rules can be defined for subsets) and can be expanded
for specific uses. In addition, the data elements can be mapped
to several transport syntaxes, not just USMARC. Rebecca sees a
need in USMARC to have a code in the leader to show that a USMARC
record has been created by extracting these Dublin data elements
from an electronic resource; one can than envision a cataloger
enhancing such a record once the data elements are captured into
a cataloging database. This in part answered John Attig's
question as to the purpose. Sally explained that another purpose
is to provide some standard description as part of the electronic
resource itself. Even though transitory perhaps, it will provide
some measure of bibliographic control which is better than what
we now get from authors.
Paul Weiss asked who will give the final stamp of approval on the
Dublin data elements. Not determined. The IETF may establish a
working group on metadata. Is it then worth making the effort to
map? Priscilla felt that a discussion of the data elements is
useful at this time, since the Dublin work will be discussed at
various international meetings in the future, and will affect the
development of the Uniform Resource Characteristic (URC). See
the Web document mentioned in DP #86 for more details.
Karen Coyle asked for clarification about the date mapping to 260
$c. She wondered if we might get other data, like a version
number. Rebecca responded that there had been another data
element for edition/version but it was dropped due to poor
definition. Attig reminded everyone that we currently use dates
to monitor editions. Karen asked about a date attached to the
description. Priscilla said that there is a version number
assigned to the metadata, like the 005. Sally said it depends
upon the context-- the metadata may be packaged with the file or
may be extracted and available elsewhere. Karen's last question
involved a user being able to find the most recent version of a
file, since various copies/versions may be stored around the
Internet. Attig sees this as a major record management issue,
with too many unknowns at this point. Priscilla said it was up
for the various groups and task forces to work out this problem.
A member of the IETF in the audience (Cecilia Preston) asked why
this is important. Answer: so that a user has some assurance of
consulting the up-to-date version, when this is important.
The meeting moved on to discuss author and agent (author is
considered to be one type of agent). Priscilla reported she
doesn't like the "Other Agent" terminology; others agreed. In
the author field, the name "should be given in the natural sort
order of the language being used" but Priscilla thinks that
perhaps the final report changes this to inverted order.
Apparently, the current intent is to invert both Author and Agent
names, if this is the natural language convention, but currently
there is a discrepancy between the author and agent descriptions.
Gary Strawn asked for this to be verified. Gary also asked if the
two Von Neuman names on page 6 represent the same person.
Unknown.
Diane Hillmann has advocated for the author field, and she is
comfortable mapping this into a 7xx field. She is concerned
though about losing the "other agent" distinction if both are
mapped to the 7xx. This will be solved because the Other Agent
should have a ROLE subelement which can be mapped to the $e
(Relator Term). Paul Weiss also thinks putting both fields into
the 7xx field is best at this point. The consensus was that the
two data elements (Author and Other Agent) should be merged.
Gary Strawn questioned why personal names will not have a ROLE
subelement, whereas corporate names probably will. Priscilla
thinks this is an oversight. Attig believes more attention needs
to be given to definitions and version control. In regards to
subject access, it was agreed that an indicator code for
controlled subject headings (with specific codes for specific
thesauri) and another code for uncontrolled headings would be
helpful. Rebecca said there is now a SCHEME subelement for the
thesaurus.
Several "title" issues were discussed. First, there are big
system implications for handling repeatable 245 fields. Second,
titles are NOT required (although Attig felt the creator of the
file will put some importance into supplying a title). Third, a
supplied title field may actually be equivalent to supplied
keywords.
Some were surprised at the Coverage field describing spatial and
temporal characteristics of the object. Apparently, there was a
strong lobby for it, causing the Dublin dozen to expand to the
baker's dozen! John Attig suggested a different mapping: the 522
for spatial) and 523 for temporal (instead of 034 or 255). Paul
thought the coverage label should be changed if limited to
spatial or temporal data; Priscilla agreed.
Paul thinks that the Object-Type will be hard to map. Other
possibilities are 300, 655, 653, or 516.
Priscilla brought up the question as to how to best integrate
these outside records into OPACs, suggesting a code in Leader 18
to identify them. This might work, thought Rich Greene, but a
040 $e would also be helpful. He thinks these records might go
into an auxiliary file or might be integrated into the main OPAC
file. Betsy Cowart would like the encoding level to be partial
or preliminary, rather than Leader 18. Paul likes 040 $e DUBL as
a way to sort out the source of the cataloging data. There was
some agreement that there should be a single code for
descriptions following the Dublin core. Stuart wondered if two
institutions couldn't map differently? Yes, this might happen,
but a standard will be helpful given record sharing.
To wrap up, Priscilla suggested more discussion on the USMARC
list. She will send out a message indicating the Web address of
the Dublin report, and asking for discussion.
-----------------------------------------------------------------
DISCUSSION PAPER #88 : "Defining a Generic Author Field in
USMARC"
Sally McCallum introduced this paper by pointing out that the use
of the USMARC standard is expanding in many new directions. The
fine distinction between types of authors, main and added
entries, etc. is hard to sustain in some of these new
situations. The paper suggests three solutions to this problem:
1) Use 7xx fields in a non-standard way (done now at times)
2) Relax 7xx definition, and add an "unspecified" indicator
3) Establish the 720 field for author names not formulated
according to cataloging or thesauri rules.
Paul Weiss thinks that the third option is a good idea, when
incoming records have names which cannot be mapped accurately to
1xx or 7xx with current indicators. He saw the need for a
broader field name for 720 than Author (but not Agent!). Young-
Hee Quiennec suggested using fill characters for the tag when
unknown (that is, 7||$a). John Attig didn't think this
was possible as a tag must consist of ASCII characters to
validate the tag against a table. Paul pointed out that
sometimes a blank can substitute as a fill character but other
times a blank has a specific meaning in USMARC. Priscilla
thought this suggestion, although intriguing, would create havoc
in existing systems.
Diane Hillmann supports the 720 idea, because the more we ask the
Internet community to do, the more unrealistic our expectations
are. For workflow purposes, reported Marti Scheel, NLM would like
an indicator to show if a name is under authority control or not.
These records could be handled separately or not at all, because
integration into current workflow doesn't seem realistic. John
is not sure if this indicator would have any value. DP85 is
related to this issue; if a generic author field were available,
this may satisfy NLM's needs.
Rich Greene said the heading comes in and you have to deal with
it. If there is no distinction between personal and corporate
names, you can try to match them against database. You have to
do something in order to index them (at least in OCLC's system).
Another possibility might be to create a general author index,
but this has implications for OCLC's charging scheme.
Priscilla said that local systems can usually distinguish between
names under control and uncontrolled names in a keyword index.
Larry Woods made a general observation regarding what is
currently happening at Stanford University. He sees a trend
toward loading of records with no intervention by library staff.
Priscilla agreed.
Question 1 on page 6 was discussed a little above, but no
clearcut direction emerged. In regards to Question 2, the
consensus of the meeting was to go with a 720 Name field. Marti
suggested the field name "Personal Name or Other." Others
suggested just "Name". In regards to Question 3, some
subfielding in the 720 field was preferred (especially, $a and
$e). However, a first indicator code for type of name (personal,
corporate, conference) was not supported; better to map to the
proper 7xx field if type of name is known. However, Karen Coyle
would like to avoid incoming fields with no subfield designation
ending up in a proper 7xx field. Robin Wendler suggested each
system would make its own mapping decisions, based upon how much
detail is available in the incoming record. Give the option for
distinguishing between personal/corporate/conference, with option
to set indicator to unknown if not supplied. John Attig
suggested further exploration of the indicator issue. Question 4
asks if an indicator for form of personal name would be helpful
to improve indexing (i.e. inverted form, direct order, or
unknown). This will support machine processing and improve
search results.
Sally agreed to flesh out these issues in a proposal for a later
meeting.
-----------------------------------------------------------------
DISCUSSION PAPER # 85 : "Changes to Personal Name First Indicator
Values"
NLM has requested the addition of a new first indicator value for
the 600 and 700 fields: value # (blank) meaning "no information
provided." The new indicator would be used for when non-AACR2
records like Medline records are mapped to USMARC. Betsy Cowart
wondered if a fill character wouldn't suffice as well, without
defining the blank. Bill Jones pointed out that some authority
programs use indicator values in authority processing, and others
do not. Karen Coyle reported that, when the Melvyl loading
program deals with the Medline tapes, the indicators are left
blank and this does not affect Melvyl indexing. On the other
hand, David Goldberg said NAL has discovered the same problem
with Agricola records, as attempts are being made to create a
single database composed of both the NAL OPAC and Agricola
records. Marti urged one of two solutions: define the blank
indicator value or establish the 720 field with a
personal/corporate/conference indicator. John Attig asked, of
these two solutions, which is the least disruptive to existing
systems?
The second change is suggested as a way to cut down on
differences between USMARC and UKMARC, thereby improving the
ability to share authority records under the NACO program. Both
formats have the same indicator with the same values, but the
applied definitions for single and multiple surname are
different. Before dropping the distinction between single and
multiple surname, it is important to know if systems make use of
this indicator for some purpose (i.e. for filing or indexing).
Bill Jones believes that the indicator value for multiple
surnames is helpful in authority processing, perhaps for creating
an automatic cross reference or for database maintenance reviews.
He doesn't think systems are using this indicator for filing
purposes though. Someone asked if any British systems use the
indicator codes for filing? Unknown, although Sally reported
that the British Library staff are comfortable with dropping the
indicator value. Betsy Cowart asked if authority records would
be redistributed if the indicator values are changed. Sally
replied that this probably would not occur.
Priscilla asked for a straw vote on the second change. Five
people voted in favor of the change, and one person voted
against.
-----------------------------------------------------------------
DISCUSSION PAPER # 90 : "MARC Format Alignment"
Sally McCallum introduced Stuart Ede (British Library) and Ralph
Manning (National Library of Canada) who are attending the
meeting to discuss DP # 90. CanMARC has had good alignment
with USMARC for the last ten years, and the National Library of
Canada regularly sends a representative to MARBI meetings.
However, UKMARC is quite different from USMARC. UKMARC has
mostly been developed for book material, with a little coding for
non-book materials. UKMARC does not include the ISBD
punctuation in the data itself; instead, more subfielding has
been defined in its place. USMARC has much more detail for
coding non-book materials, and this is seen as an advantage by
the British Library. There is interest in our use of the 007 and
008. The British Library initiated the discussions to
investigate closer alignment, which might then result in
decreased costs and increased record sharing. Impact on
databases and systems will be investigated though.
Marti Scheel pointed out that the paper discussed the
bibliographic format. What is intended in regards to the
authority format? Sally said both formats will be analyzed for
alignment. Apparently, the UK does not have an official UK
authority format. BL does have an internal authority format
which will probably correlate well to USMARC.
Young-Hee Queinnec discussed a few differences between CanMARC
and USMARC. Apparently, differences with name fields were
discontinued a few years ago. There are more note fields in
CanMARC compared to USMARC. More importantly, CanMARC has a
block of 9xx fields for "equivalent headings" (i.e. translation
of a heading into another language).
John Attig asked about the goal of the alignment. Sally said the
goal was for libraries in all three countries to use the same
format. Whether or not this can be achieved depends upon system
and database impact. The impact may be quite large; the US
bibliographic community is probably not ready for a change
as large as format integration. Rich Greene said that much
alignment will prove to be easy, whereas some will be very hard.
Paul Weiss agreed; one community or both will have to convert
data in order to achieve true alignment.
Stuart Ede explained that British libraries are interested in
receiving US copy cataloging over the Internet, without the
expense of switching records from USMARC to UKMARC. He expects
much enthusiasm for the basic goal, but some trepidation on how
to achieve it. The big issue with alignment is how much effort
it will take. A process has been worked out, where system impact
will be carefully evaluated before proceeding. Sally said that
MARBI can expect various papers as a result of the ongoing work.
John Espley said that he expected the vendor community to be very
supportive of this goal. Although most countries base their MARC
format on USMARC, the differences are significant. Right now
vendors must write conversion programs when moving data between
US utilities and local systems in other countries.
Australia, New Zealand, Poland, Spain, Switzerland, and Turkey
have adopted USMARC. Members wondered about Japan and Germany.
Stuart Ebe reported he has discussed this project with the Head
of the Deutches Bibliothek, and an observer may be sent to join
meetings in future. Sally reported that the Germans are also
looking at AACR2 (the German MARC format supports their own
cataloging code).
Library of Congress