MARBI Members:
Priscilla Caplan LITA U of Chicago
James Crooks RASD UC Irvine
Karen M Drabenstott RASD U of Michigan
Shelby Harken ALCTS, Recorder U of North Dakota
William W. Jones LITA New York U
Gary Strawn ALCTS Northwestern U
Flo Wilson ALCTS Vanderbilt
Larry Woods LITA U of Iowa
MARBI Interns
Josephine Crawford ALCTS U of Wisconsin
Jacqueline Riley RASD U of Cincinnati
Paul Weiss ALCTS Nat'l Lib of Medicine
Representatives and Liaisons
John Attig OLAC Penn State U
Sherman Clark CC:DA Amon Carter Museum
Bonnie A. Dede SAC U of Michigan
John Espley AVIAC VTLS
Susan Flanagan Art Libraries Getty Center Lib.
Society of N Amer.
David Goldberg NAL NAL
Richard Greene OCLC OCLC
Robyn Greenlund MicroLIF Data Trek, Inc.
Maureen Killeen ISM ISM
Karen Little Music Lib. Assoc. U of Louisville
Elizabeth Mangan FGDC LC, Geog. and Map Div.
Sally H. McCallum LC LC, Net Dev/MSO
Susan Moore MAGERT U of Arizona
Marti Scheel NLM NLM
Stuart Spore AALL NYU Law
Lennie Stovel RLG RLG
Rutherford Witthus SAA U of Colorado, Denver
Young-hee Queinnec NLC Nat'l Lib of Canada
Other attendees:
Diane Baden Minuteman Library
Ross Bourne British Library
Johanna Bowen SUNY Cortland
Ann Case H.W. Wilson
Juiwen Chang RLG
Anne Flint Ohio Link
Janet Fox U of Chicago
Carol Goodson LITA Program West Georgia College
Alison Gunson Calif. Inst. of Technology
Diane I. Hillmann Cornell Law Library
Gail Hodge RMS Assoc., NASA STI
Lynn El-Hoshy LC/CPSO
Rob Jacobson Media Flex
Michael Johnson Follett MicroLIF
Erik Jul OCLC
Sherry Kelley UCLA
John Kloswick Mich. State U
Karina Labrenz MARCorp
Mary Larsgaard UC Santa Barbara
Faye Liebowitz U of Pittsburgh
Bob Mead-Donaldson Florida Internat'l U
Margaret Mering ALCTS Ser Cat U of Nebraska
Sara Mitchell MIT
Jane Murray U of Maryland, Balt.
Glenn Patton OCLC
Ellen Rappaport Albany Law School
Holly Schmidt BNA
Brian Schottlaender UCLA
Ray Schwartz Columbia U
Margaret Shen Cleveland Public
Stephen J. Squires MLA rep to CCDA U of NC at Chapel Hill
Robin Wendler Harvard
Kathryn ___ U of North Texas
General Announcements
Flo announced that a character set committee has been set up
including Larry Woods as chair, Sally McCallum, Randall Barry, Paul
Weiss, Rich Greene, Joan Aliprand, John Espley, Robyn Greenlund and
is expecting a report at Midwinter. The draft of the minutes was
put out on USMARC and hoped that was helpful. Review of the MARBI
charge is ongoing.
LC Announcements
Sally McCallum made several announcements. The listserv was moved
to a new machine 2 weeks prior. It is USMARC@loc.gov and can be
subscribed to by sending SUBSCRIBE USMARC@LOC>:GOV to
LISTPROC@LOC.GOV. Problems with archiving should be remedied next
week. There are several new publications: bibliographic format
including 010-8XX integrated with place holder for 006; country,
gacs, relators lists. A new cleaner edition of Symbols of American
Libraries will be out next year. Specs and USMARC Holdings will be
out in the fall. Classification could be out in the fall, but
concensus was to wait until after next ALA. LC is on schedule with
conversion in relation to format integration. The Concise document
may be updated in the fall. Paul pointed out the 245 GMD move
requires changes in documentation.
Proposal 94-9: Changes to the USMARC Bibliographic Format to
Accommodate Online Systems and Services
Disposition: Passed as amended and with recommendations for further
review. Summary of amendments:
* "i" added to 008
* "e" changed wording in 008, 270's name is "address" and is to be
added and be repeatable, and include $r hours and $z public note
* need to clarify field definition and scope
* use 307 for hours without $c
* no 531 field being added
* $w is to be added to 856 with editorial changes and an example
* 506 neeeds to come back in a proposal
* 270's in CIF need to come back for review
Sally introduced this as a companion to the proposal to accommodate
electronic resources in databases. It includes service aspects
(fees, contacts, etc.). Proposed changes are on p. 10. "i" for
online service vs. "o" was discussed. Paul questioned "and may
contain bibliographic information" in the definition on p. 12.
Larry didn't see other mnemonic usages elsewhere. John asked to
verify if 008 is better than the leader for this information, but
Sally says the question that came up was in relation to GILS. Paul
was concerned about "not fully content designating information" in
MARC and then calling it MARC which Karen Coyle brought up. Z39.2
defines that it is MARC and Sally said people often use it but it
needs tags and content. It was decided to use "i" rather than "o".
Paul asked about the use of "computer file" even though databases
aren't really files. We need to call it something. Paul asked about
"e" on p. 12. It was suggested to remove "data with".
Discussion continued on defining community information fields: 270,
301 or 307, and 531. Paul indicated the address definition is
rather vague and wondered if that was OK. There is no relator code
list here and it is repeatable, and $i can distinguish type of
address. Sally didn't think we needed multiple 27X's for this type
of information. Robyn said you can't really identify "primary"
address for a computer file. John Espley suggested we could rename
the address field in CIF to just "address". Priscilla asked if you
can have 270 repeatable in the bib format and not in CIF. They are
not the same type of format. Paul pointed out CIF is provisional
and we could change it to be repeatable. Sally suggested a proposal
for CIF changes would be needed. David questioned 270 in the bib
format. 260 has reference to publishers' addresses and John
;pointed out the sequence doesn't fit in AACR2. A guest asked if we
are trying to create mini-directories in the bib records, or are we
just trying to make a pointer to the resource. Robyn pointed out
there is a problem of point of view between who is cataloging the
material and what information they have. Indicators could be used
with blank-don't know, 1-primary, 2-other. Priscilla pointed out a
service could have multiple addresses that need to be linked and
sequenced to 856. Robyn said vendors will now be faced with
multiple array in bib records which isn't there now. Paul
disagreed. Priscilla thought 270 is for humans and 856 is for
machines. Discussion flowed to the fact that it is primarily for
linear display. Paul said we aren't making distinctions clear. Next
we need more descriptive text explaining that 270 is how to find
out about it and 856 is how to get to it.
The addition of relation code $4 was discussed. Elizabeth pointed
out 94-17 intends to use multiple $4's. Flo summarized that it
should read "270 Address", not "primary address"; 270 is
repeatable, a later proposal should be made to address "primary" in
CIF 270; if indicators are to be used, they need to be in a new
proposal; clarifications in text are needed to make 270 and 856
clear. Paul said we should follow MARC guidelines with 270 as
highest level of the hierarchy so 270 is the contact if it covers
everything, whereas 856 is about the service and if each address
has its own contact it can be indicated because 856 is repeatable.
Discussion of 301 or 307 hours followed. How is $c Time
differential determined? Is it between where you are and where the
file is which will vary in bib records, or is between where you are
and Greenwich time? Robyn asked why do we need hours. If it is for
hours of availability of service, that is 856; if it is for
organization, then it is 270 and you need to know when you can call
someone. Marti also thought it needed something like "EST" that a
computer can use to compute time from your site to the services
site to figure out if it makes sense to try to make the connection.
It was suggested that $z in 270 be for hours of contact and call it
public note for hours and $r for hours. Paul asked where then do we
put service hours. Is 856 actual connect hours and 506 is a note
about hours when it is available. Discussion argued away from using
301 or 307 and in favor of 506 a public note to explain hours and
856 would be used for electronic hours. Priscilla suggested we see
a proposal for the 856. Diane Hillman added that 856 may end up as
protected information and argued for a separate proposal for 856,
but felt 301 would be able to show up as HOURS better in public
display. 506 is a restriction on use, and 301 is when it is
available. Straw vote favored 307 for hours, not 506. Subfielding
of 307 was discussed. $c is being eliminated because this is to be
eye-readable. CIF 301 change to 307 would need to be re-evaluated.
Paul asked what is "additional information" in $b. Discussion led
to just plain hours in $a and other information in $b with 307
repeatable if need be. Regarding 531, the suggestion was to move
information to 506 and then subfielding in 506 needs to be
readdressed. John tried to clarify $w-Record control number in 856.
Is it for the control number of the bib record for the service?
Priscilla suggested that $w would be the control number of the
service available through DIALOG or MELVYL, etc. which would be
another bib record. Young-Hee asked about linking fields, but Paul
pointed out it is a record link, not a field link. Lennie
questioned the repeatability of $2 in 856 example. Sally said
Rebecca thought there could be 2 methods of access but we could
also repeat 856. John asked why "source of" was being eliminated.
Bill said it isn't a source, it is a method of access which really
makes it different than other $2 definitions. John tried to
reconfirm that the $w in 856 would be expected to be entered as $w
in 780 and 785. $2 should not be repeatable. Priscilla didn't
remember the label URL was to be used with $u but the proposal
seems to say we label it URL. Lennie thought the URL people wanted
URL in front of $. Flo said that this is really not part of the
proposal and may be pre-mature to discuss, and the wording may
appear differently so we shouldn't discuss it. Paul wondered if
MARBI needed to address $u even though it was not part of the
proposal. Rich and Cilla both felt that we need to review it
editorially in the adoption of the proposal over the list. Paul
pointed out that leader byte decisions need to be made. Robyn
questioned if there is enough for us to act on and people can use
it without definition of 506 and leader bytes or not. Paul
presented some questions. Leader byte 06-m computer file,
presumably would be used. Byte 07-bib level should have "n" for not
applicable because its not a collection or monograph. Sally said LC
sort of decided to follow loose-leaf guidelines and ended up with
"m"; Diana Hillman said Cornell ended up with "s". Byte 17-Enc lvl
- as appropriate. Byte 18 - code according to how you cataloged
it. Examples of 245 fields have variations in punctuation. Paul
asked if 270 is restricted to online resources and not applicable
to books, for example. Sally indicated it was intended to be
restricted to the purpose of the proposal.
Discussion Paper 78: Location and Access Information for
Non-Internet Resources in USMARC Records
Disposition: Proposal for Midwinter
The question is should there be two separate fields for 856
information or should the subfielding be changed in 856. Robyn
indicated phone numbers are not always universal. All examples
listed the lowest baud rate, but most people need to know the
highest, so she is hoping for better examples. Lennie didn't get
the impression of a redefinition of 856 fields from the proposal
and wondered if that had been already discarded as an option and
forced the option of including an 857. Priscilla said some URL
information may be discarded and $a could be redefined. Paul didn't
want to see an 857 and preferred option 3. A guest suggested 856
should not be bound by TCP/IP or a provision should be made for a
phone number. John suggested an indicator change to help define $b
as TCP/IP or phone or whatever. John Espley wondered if LC was
suggesting major changes because there is concern for work done
already by vendors using 856. Paul reminded us that it is
provisional. Priscilla thought URL ought to be looked at but as
Diane Hillman said, if 856 gets used for non-Internet sources then
we shouldn't abandon 856 URL information. John Espley indicated he
is in favor of option 1.
Flo summarized that there is general agreement in favor of a single
856 and that it be looked at in light of URL. Discussion led to
deciding a proposal should be made from this discussion paper.
Pricilla said an 856 should stand alone and we should look at phone
number representation in 856.
Proposal 94-12: Core Record Designation in USMARC Bibliographic
Records
Disposition: Option 2 accepted as written with LC deciding on use
of code values 3 or 4.
This was a discussion paper last meeting and it is in Appendix A of
the proposal as developed for books. The proposal includes three
options: 1) 042 with indication of pcc, 2) 042/encoding level, 3)
042 with indication of pcc and level. Encoding level information is
included to compare with core record proposal for discussion.
John Attig brought up the fact that the core record is defined so
far for books only, but the list in the core column list does
include items from other formats. The national level record is
really not part of MARBI's purview and its definition may change
through cataloging groups. Sally feels they either need to be
clarified and defined as separate types or merged together. Once
they decide, then MARBI documents it. Robyn said CDS tests against
lists to make sure a record has what fields should always be
present. Rich Greene said OCLC wants it to be available as a
standard for vendors and OCLC for discussion. Lennie said the
definition of "full" still is in MARBI's purview as a flag in the
record. John reported that catalogers need an identifier that they
recognize as a part of the program, just like CONSER.
Rich Greene said option 1 is preferred at OCLC because OCLC has
already dealt with coding for nccp in 042 and at this time Encoding
level is same in full and core. Priscilla said core doesn't regard
a record without a series as full. We could redefine Enc lvl full
to include NLRB full and PCC core. Sherman pointed out PCC core
talks about being upgraded to full. Sally said even "full" records
can sometimes be upgraded. Paul asked, isn't it used to adjust
workflow because people don't perfectly follow standards anyway.
Marti spoke to option 2 because there could be a possibility of
different types of "core records" and Encoding level could be
different in each case. Jo also supports option 2 because of
identification for cataloging and to get lists for review and test
if users get better service from one type over another. Glenn
Patton suggested level 2 and 3 are both really "full". John said
the whole point of this is so people don't have to make
distinctions. Young-Hee pointed out the core record contains fields
not defined in AACR2 which is where level 2 and 3 are defined so
one can't always follow that logic. Diana Hillman said even if
people decide to use core records, they need to be able to identify
one from the other. Sally, trying to summarize each proposal, said
option 1 presumes a core record is full, option 2 is full, and
option 3 is the same as 2 and also identifies even more. The 042 is
trying to say headings are verified except for series. Proposed
Encoding level 3 doesn't say where the core level came from without
042. Young-Hee said CANMARC already has defined Enc lvl 3, but 4 is
open. Sherman and Priscilla pointed out that if you are not a PCC
member, you can't put PCC in the 042 and would have to use an
appropriate Encoding level. Robyn and Bill spoke to the need to
identify who is trying to follow core standards. Priscilla asked
for the definition of Encoding level 3 and wanted to know if it
really means the core standards are being followed. Discussion
focused on confusion with the definition of Enc lvl 3. Lennie
argued for blank being either core and full both being full,
whereas Sally pointed out that different fields are higher in core
and full. There are problems if this is not clearly stated so that
a machine can handle the difference. Bonnie said the purpose of the
creators of the core records was that you could count on
authorities having being checked for access points and records not
having too much stuff. Diane Hillman also pointed out this is an
effort to save time and also have confidence in the record, but a
library needs to be able to upgrade some records for local needs.
John feels these are two different levels that need to be
identified; full and core are not the same. Robyn is concerned that
in time records will get modified within systems and we will be
back to records we can't trust. It was suggested that Encoding
level 3 is for the core record, 042 PCC is just if you're a PCC
member, and if you're not a member, use 040 $d. Priscilla moved we
accept option 2 as written with LC deciding on use of 3 or 4.
Seconded and passed.
Proposal 94-13: Interactive Multimedia Code for USMARC
Bibliographic Format.
Disposition: Accepted option 1
Sherman reported that the committee [CC:DA on Interactive
Multimedia] discussed MARBI's proposal and the future possibility
of inclusion in AACR2. The 008 is not covered. 008/26 may be
valuable, but GMD may be easiest to find. John reported on the AV
committee and OLUC committee comments. AV requests MARBI assure
multi-media be able to be cataloged now. LDR/06 or 008/26 would
work. The materials are unique and not really part of computer
files. OLUC wasn't sure it was a new format requiring 008/26 but
for the time being LDR/06 "m" would be OK. Rich Greene said the
Joint Steering Committee discussed if it's really a new chapter and
not up to MARBI. Interactive multimedia is closer to computer files
than 94-14. It was pointed out that on page 5, Attachment A,
computer files should be "m". Also a new chapter in AACR2 doesn't
drive the decision to create a new 008. Lennie isn't sure 008 is
enough, but need an LDR/06 and then what do you define in 008/26?
Paul said we need to be able to follow the Guidelines as published
and thinks it can be done without LDR/06 or 008/26 defined now.
However, it would require going back and fixing records if LDR/06
or 008 were redefined. People could work with just 245 $h. John
said if you define LDR/06 you have to have 008/26. Using existing
formats force us to call it computer files, but the definition in
the Guidelines says it isn't computer files. Larry pointed out
these materials could be viewed as kits or visuals or something,
but not as a computer file. Sherman said we have other cases where
we stick things into LDR/06 that don't really fit. Priscilla said,
since this doesn't appear to be the time to define a new LDR/06 and
we just put services in LDR/06 in 94-14, she supports option 1.
Priscilla moved we accept option 1. Gary seconded. Motion passed.
John still thought we ought to keep in mind the limitations of
LDR/06.
Proposal 94-11: Addition of Subfield $n (Note) in Field 037 (Source
of Acquisition) in the USMARC Bibliographic Format
Disposition: Accepted as proposed except to change $n text to:
textual note pertaining to acquisition of the item.
The proposal adds a note field in 037. Gail Hodge of NASA SII said
they get documents in one format, but distribute to others in other
formats. There are times they can't exactly reproduce it (eg.
can't do color). They don't feel it's really related to price, but
rather how delivery can be made. Paul was not really opposed, but
thinks $f makes more sense than $c or a new $n. Lennie agreed. Paul
interpreted $f as a very narrow definition of format and $n would
allow more description. Robyn thought delivery instructions would
fit somewhere other than $f. Sally tried to explain why technical
reports need a little more information because they are not really
published. Bill noted the example information seemed to show a
need to always have $f $c in pairs of information. Priscilla
suggested it contains a textual note pertaining to acquisition of
an item, and examples ought to include delivery type information.
Sally was concerned about $c price and how NTIS uses it because
prices fluctuate. Paul pointed out that if we change as discussed,
then it's harder for the proposer of the proposal. Larry said $n
could just be a general note to refer to any field. Priscilla moved
to accept the proposal as written except change $n text to: textual
note pertaining to acquisition of the item. Larry seconded. Motion
passed.
Proposal 94-16: Encoding of Cancelled/Invalid Report Numbers in the
USMARC Bibliographic Format.
Disposition: Accepted option 2.
The proposal provides two options for identifying valid versus
invalid or cancelled numbers in 088. Marti spoke strongly in favor
of option 2 with review in the future of bringing 022 in line with
other fields. Gary moved option 2 be adopted. Priscilla seconded.
Motion passed.
Discussion Paper 79: Defining Subfield $v for Form Subdivision in
the USMARC Formats.
Disposition: Ready for a proposal
Sally brought this back because of concerns about impact. She tried
to bring out impact questions in the discussion paper. Flo said we
have to think how users use their systems and how would having form
subdivision help users and then what is the impact on systems.
Bonnie spoke from SAC on their straw vote. Overwhelmingly people
wanted this form subdivision. Karen Drabenstott has done some
research showing users want or don't want form which means it has
to be identified. SAC tried to address each item. Paul said item 4
on p. 7 - implementation - is then the real problem if people want
this. Bonnie noted 655 had been suggested on the listservs. Bonnie
said SAC felt it needed both because usage of 650 and 655 are
different. Example: 655 is a bibliography, but 650 is a topic with
a bibliography. Flo indicated a need to identify if the group does
in fact want form subdivisions before we go through implementation
problems. Bonnie said SAC thought LC should not have to deal with
this problem because other thesauri are being used or being
developed. Marti said NLM has been dealing with it in MESH and
would use the subdivision if available in the next generation of
their online system, but right now they use order in the subject to
find. Rich asked what does NLM really do? Marti and Paul further
clarified how MESH works. Tony spoke about AAT not being a
particularly system oriented thesaurus, but she sees a need for
form data is growing and where this data is placed must be
identified. Jim Crooks said online systems almost make it harder to
quickly see form subdivisions like guide cards did in old card
catalogs. He sees this proposal as the attempt to enable systems to
provide that. Rutherford would like to be able to qualify searches
by form. AAT and LCSH are used by the archival community and they
support both 655 and 650 $v. Paul explained how MESH explodes
subject headings hierarchically and it is useful to the medical
community which speaks in favor of having form subdivisions. Lennie
asked, what would you display to users?-topic subdivided by topic?
John Espley asked how do you display all these variances to users.
Paul suggested there are several ways. Priscilla pointed out that
how a system exploits an option or doesn't, could make it worse for
users. The movement right now is not to display hierarchy to users.
Arlene indicated it could be confusing if the users presumes the
form refers to all topics in the work and it may not. Lennie
pointed out a form could be linked with the right subject. Flo
asked for a straw vote to have form subdivisions in addition to 655
fields, independent of implementation issues. The vote was in favor
of form subdivisions. Larry and Sherman again reiterated the need
for systems to deal with it.
Implementation issues were discussed. Do we ask LC to change or
give them the option to not change LCSH? Sally said they can't
really tamper with MESH. Sally asked Lynn if 655 could be used as
a choice without doing $v. She said since $x would have to be
redefined to add $v, therefore they would have to respond by no
longer using $x as they have. Priscilla said the discussion seems
to have changed from would thesauri need to be changed to LC has
to, and deciding if LC can or can't afford it isn't the question
because it would affect every system. Paul commented on Lynn's
comment saying we already violate subject rules by using form in
$x. Young-Hee said you can't force anyone to use something even if
we define it. John asked, can we take LC out of the loop? Sally
said this topic came up in a conference that LC held. Paul didn't
think that should dictate the end of the proposal. Sherman said the
dual function of a subject bothers him. AAT seems to resist telling
the user anything whereas MESH defines it specifically. Lynn thinks
it could be handled such that a term could be used in either way.
Flo asked if vendors could speak to implementation. Rich said OCLC
has the same problem as LC of what to do now and whether to do
retrospective work. Right now they say it's up to keepers of the
thesauri whether or not a field applies and the decision to
reconvert probably needs to be made. Arlene reported that SAC
discussion viewed that it could be implemented now with
retrospective work done in the future. If $v is not an option, 655
would be the only thing left and SAC after 3 years doesn't see that
as enough for LCSH. John said authority record format would need to
be modified such that it would allow us to begin pulling apart
topic from form and then that would facilitate retro. Bonnie
pointed out when LC has global change capability it will help a
lot. SAC concluded local system retro could not be done completely
accurately - probably 5% or so would be errors - because for
example "bibliography" at the end may be a subject even though it
is often form in that location. Priscilla reminded us vendors of
automated authority control will be affected. MARBI's role is not
to tell LC what to do when a local system could very well find
other ways of providing information to users. Sally agrees MARBI
maybe shouldn't tell LC what to do; instead the LC Cataloging
Directorate needs to review what the impact would be and also look
at authority records. Paul asked, have we agreed $v is valuable in
some vocabularies and LC still needs some investigation? Bonnie
asked if we can give $x to LC for now and $v to other systems -
consensus was no. Marti reiterated MESH sees $v as very valuable
and LC needs to at least accept records with $v. Arlene has had
indications that LC is not willing to take the time to investigate
$v until it is a defined thing. Larry offered that $v could be
optional. Tony asked if people at LC can be talked with while a
proposal is being written. John Espley said we need to keep in mind
the cost to redo systems - what vendors will spend and will then
cost libraries. Jo listed: 1) tag list needs to be made - not hard;
2) validation routine needs to be set up - not hard; 3) authority
processing could be very time consuming or costly; 4) evaluate how
indexing works in individual systems and what would it cost. Paul
asked why did this come back as a discussion paper when at the last
meeting we decided it should be a proposal. Sally said people were
worried about impact and that made it worth of another discussion
paper. Flo asked if we missed any other questions. Bill brought up
the CCC task force on subject authority. Lynn said the committee
hasn't gotten that far. Bill asked to verify that $x redefinition
would need to be included with the proposal. John will poll vendors
reactions to this. Robyn said vendors are being pressed to do X12,
formation integration, etc. At some time they will say "no or it
will cost you" and then do you still want the change? Flo took a
straw vote to see if there should be a proposal for $v for form
subdivisions. The vote was yes. John reminded us of a proposal in
Denver about authority records and nothing was completed with it
and thesauri could find it useful. It may also be useful to this
discussion. Marti offered to help Sally.
Report form AVIAC Liaison
John Espley reported from the AVIAC discussion about $v for form
subdivisions. Vendors are very concerned about the cost of
retrospective conversion, both to vendors and libraries. They asked
if we could proceed slowly. They suggest we should get cost
estimates. They would like an algorithm to define how to do to
conversion with LCSH primarily and all applications of $v anywhere.
Sally said LCSH needs to decide where it can go, wants to go, and
what they can do. John indicated more discussion on listservs would
be helpful. Several people said there are needs in some libraries
for it quickly. Maureen pointed out ISM authority control would
have problems with $a $v and $a $x that turned out to have the same
terms. Jo suggested a sequence of questions on listservs. Jo
volunteered to start it up. Marti would like vendors we all use to
comment too, separately from LCSH. Robyn said she had a sense
vendors were concerned about change whether LCSH or not. James
questioned if vendors who create online reference databases don't
also use tags and aren't those vendors to be taken into account.
Proposal 94-17: Changes to the USMARC Bibliographic Format to
Accommodate the Content Standards for Digital Geospatial Metadata
(CSDGM)
Disposition: Approved with changes as discussed
Sally introduced Betsy Mangan and Mary Larsgaard. The Federal
Geographic Committee is trying to define what elements are
necessary for geospatial metadata. Betsy has to make a match
between their data and MARC. It is hoped that the agencies creating
data will fold what's needed for the record into and be a part of
the data created. This would avoid duplication. LC and the National
Archives are the only agencies not collecting data. An executive
order by the President says by Jan. 11, 1995 all digital data must
be made available preferably using USMARC. John asked if all the
separate data elements require separate content designation. Betsy
said the data will be manipulated and it will be based on what data
is in a field that can be identified - i.e. yes. Mary said digital
geospatial data is being used every day by map librarians to
provide reference service. John asked if it is imperative we
complete this. Betsy said through the Internet the Federal
Committee will have an indexing service mounted to help index the
places all federal digital data can be found. The group decided to
begin with fields that are being modified that we already use. 034
second indicator "undefined" is not possible. All current data is
"bounding coordinates" so it will be blank, 0, 1 in order. It is
preferred to use blank so we don't have to redo all old records.
Paul wondered if digital always applied or could it have the same
value for paper. Discussion of the first paragraph on p.7 resulted
in eliminating "For digital items," in the second line. Larry and
Paul again questioned blank vs. 0 [zero] in 034 asking can a record
have only one latitude or longitude. It was decided to use blank-
not a ring or not applicable, 0-outer, 1-exclusion in order. 037 $h
is redefined as "file decompression technique". Rich wondered if in
the past we didn't put in indicators for microforms and instead
used subfields - eg. $f for microform. It was decided to have no
indicators in 037 and leave as currently defined. John asked what
the difference is between $f and $g. Betsy explained that it
depends on proprietary software and what version it is and what it
can produce. Betsy said there is a list of formats being used. They
needed $g to distinguish CD-ROM vs. computer file, etc. Lennie said
it was hard to figure out some of the definitions without an
example. Paul said the question is whether or not separate
processing is needed on the field, and if not, could $f and $g be
put together. Betsy says users will want to search for specific
formats because it can be used by the software they have. Robyn
said if data in the delimiter is identifiable, a vendor can find it
and what's in it and in this case would probably be displayed
together. The concensus flowed to provisionally try $f to hold all
data under $g $h $i $j on p.10. Betsy said people will order the
format they can use and it will order that, but everything else in
037 is the same no matter what format it is in. The data set has
a stock number no matter what format. That brings you to a
repeatable $f or an additional field that describes additional
format characteristics information in $g that's repeatable. It was
decided $g is repeatable as additional format characteristics.
530 isn't as relevant compared to 856 which is how you can get to
it, but it doesn't say what format and cost you can get it in. Paul
suggested we make wording in 037 and 856 clear. Flo wanted it
clarified if 037$g is provisional or full. It was decided it is
provisional. 255 is tied to 034. AACR2 only talks about bounded
coordinates and all that is in it (p.11) is new since AACR2. 034 is
machine readable and 255 is for display and it contains $b. It was
decided to remove "For digital items" in the Field Definition.
Susan said right now 034 says it's created from 255 so both fields
must exist. 255 as written except "for digital items" accepted as
official [not provisional]. Security, 355, was discussed. Some of
the same systems originate this data as those that originally
requested 355 of MARBI. Paul asked if $e is controlled. Betsy
replied probably not. It was decided to remove "data set" in first
indicator 0. 355 was officially approved [not provisional]. Using
537 would be reinstating an obsolete field. It is the source of the
item used to obtain the data - it becomes a mini bib record
describing what was used to get data from, eg. old paper, map, etc.
Paul wondered if linking fields to a real bib record wouldn't work
- 7xx fields. Betsy said they had originally asked the creators of
data to include a citation but they didn't understand what was
needed so the data was passed into subfields with additions of $s
and $v. They also felt it important to embed the source of data in
the record about the data now digitized. Lennie asked why was the
field made obsolete. It was made obsolete even though the computer
community had supported it anyway. Mary said many sources of data
of varied types could have been used to create the new data set
being created and users need to know where it came from to either
validate the data set or get back to original sources. When asked
if a general 500 would work, Betsy reiterated the need to identify
the data. Paul said it's nice to be able to find these specific
sources of data but again isn't it a linking field. The 537 needs
to be reworked as a linking field and dealt with on the listserv to
try to reach a provisional level field.
New fields were discussed next. Regarding 252 and 253, John said
the information is outside of AACR2 and is leery of using them in
this position, plus there is not much room. Betsy said 25X is not
critical and just followed 255 pattern and maybe 35X would be OK.
It was decided it is provisional and to review as 25X versus 35X
keeping in mind that specific subfields may need review in the
future. Sally wants to review the class of data in 3XX and 2XX
before a decision is made. It IS mathematical and logical in 25X
but not required by users to display there.
352 for organization of geospatial data was reviewed using the
revised page distributed at the meeting which lists both indicators
as undefined. John was concerned about having two field describing
organization of data. Betsy and Mary both said it could be any
graphical image; it could be vector or rastor. "Geospatial" is too
specific. The name of the field was changed to "Digital Graphical
Representation". Also any reference to "geo" should be removed.
Data in this field can't be analog, ever. The field is provisional
and repeatable because not reviewed anywhere but at the meeting.
Paul asked if "geospatial" needs to be in 514. John asked if we are
going to be asked to make lists and fields like this for everyone.
Betsy said the need is to use terminology using "accuracy" to
define the name of the field. Why subfield all of this note if it's
going to be displayed as a single note? Betsy thinks users want to
know if a statement exists in the record about a certain type of
accuracy. Betsy said FIPS173 standard defines how to determine
these levels of accuracy. The question continues as to whether this
is needed for special indexing or special display. Sally thinks
this is for sure provisional and should just leave it. Priscilla
asked why we are being conservative in 037 and leaving all this
here. John pointed out 037 is an existing field which we don't want
to meddle with, but 514 is new. Marti said a not too complex
example would be helpful. Lennie said users who use it need to see
it in a real system. Betsy says they don't care about displays. For
them, searching is the key in finding the data they need. Paul
suggests we accept it as it is with wording changes to delete
"geospatial" in the title of the field; change "thematic" to
"attribute" in $a $b $c; $g to Horizontal position accuracy value;
and $j to Vertical position accuracy value.
Paul questions the relationship of 566 to 351. It seems that 566
describes each piece of 351 cited. John suggested maybe a 551 to go
with 351. This field is provisional. Regarding 3.4 Add Codes on p.
6, Paul asked what is a "prc" Process contact. Information would be
put in 270 to explain who to contact if mathematical data is
converted. Again it was decided "digital geospatial" was too
limiting and will be removed. $r could be in 270 or 7XX - "mdc" is
how original data was structured and created, whereas "prc" would
be how its been changed. Metadata will accompany digital data to go
to the cataloger. Page 6 accepted with rewording of the last line:
"...the original description from which this record was derived"
and remove "digital geospatial" in prc definition. Gary moved we
approved 94-17 as discussed. Seconded and passed.
MARBI has helped carry out an Executive Order of the President!
Proposal 94-14: Extension of USMARC Authority Fields 053 and 083
for Local Use
Disposition: Approved as written
OCLC is interested in being able to adapt authority records to
local needs. These fields are the only two they felt they needed.
John asked if it is necessary to include $5 as there is concern
about lots of local information in a record, or could the
convention of $d in 040 work. Bill said libraries in consortia need
to know which institution added information. Paul said it may also
be necessary to know even at the originating institution. Gary
moved it be accepted as written. Larry seconded. Passed.
Proposal 94-15: Field Link and Sequence Information in the USMARC
Formats.
Disposition: Adopted technique of $8 linking, field link type is
mandatory, and tag is not used
Sally explained this proposal follows discussion paper 78 and
previous MARBI discussions about linking and sequencing. She also
said multiple versions possible usage is included in this
discussion. John said the strength of the proposal is that it
provides a generalized structure for $8 for linking. Jo said she's
been using linking for holdings and thought including the tag would
be clarifying. John pointed out $6 uses tag and $8 doesn't. Paul
said some information is tied to tag and some is not. Sally
indicated using tag could link back to the record directly. Tags
are not used for anything. The link number is used to link - 1's
are linked to 1's. Link number is before "." and sequence number
follows. Lennie said we need a clearer definition of link.
Priscilla suggested we scrap the tag. Paul suggested we use: <:link
number>:.<:sequence number>:\<:field type>:.
Joe summarized the sequence
number sequences the field in the group numbered as a link number.
Diane Hillman pointed out in holdings $6 we presume we have to
sequence because we'll have multiple holdings so we sequence. In
this case we may not always need a sequence. Is there a conceptual
difference - a parent and several children, or several children.
David tried to affirm that this could be used for multiple
versions. Robyn said the link type needs to consistent within a
record. Paul asked shouldn't these NOT be decimals? Yes, they are
not decimals so remove 0's (zeros) in examples. Sequence number is
a whole number and may vary in length. Music community wants $8 for
100 and 240, but not 245. If less than all, must state link with
$8; if applies to all, do not use $8. Again, people need to see
examples of display. John said this is also important for searching
to make it clear which work the performer is doing. Karen Little
said the music community prefers 1 record with linking over using
analytics. Karen said subject headings are chosen in order of
predominance when a work comprises several items. Analytics versus
link is a problem: analytics take time and the link is somewhat
limiting. Diane said catalogers just have to make judgments as to
importance of individual parts version collection being adequate
according to AACR2 and their users. James wondered about the
relation of the 970 BNA is using. John said there is a problem of
record size limits in creation of 970. There are also limitations
in systems, Z39.50, etc. Karen said 240 may not always be used, but
music catalogers often include it anyway and with linking they are
more likely to. Jo said analytics are nice but they have to face
problems with linkage. John asked, do users want to see the whole
record or just the part of the record they had searched. Paul said
field link types should be mandatory in the bib format. Lennie felt
better using linkages and considering field link types later. Sally
would prefer to have something defined so the linking subfields are
distinguishable from holdings and people can start using this
proposal. John brought up "repeatability" - is it in field blocks
or in records? Paul said the order of fields also needs to be
considered. Sally still would like to settle the structure of $8.
Diane maintained repeatability must be addressed first. OCLC is not
sure what they're going to do but think it would work. RLG wouldn't
do anything for 6 months; they wait for printed documents. NASA has
done linked records in their system. Gary moved we adopt the
technique of $8 linking and say field link type is mandatory and
not use tag. Bill seconded. Passed. Specific proposals are needed
at Midwinter for field type to be addressed then and have time to
look at examples. Absence of field link type means it's holdings
information. Repeatability will come back in another proposal.
Proposal 94-10: Encoding of Patent Information in the USMARC
Bibliographic Format
Disposition: Postponed until Midwinter
Patent people have a very organized way of defining data elements
which results in requiring very few additions to meet their needs.
Sally thinks $1 and $q could be concatenated together; $n should be
$a. OCLC has a problem with 016 because it's in CONSER records
everywhere. We need to find another tag number. Bill is concerned
about $c with one-character codes left justified - it this going to
work between systems? Priscilla said $c has a list of codes that
are being followed, so what would the difference be what is used?
Robyn suggested 02X might be a possible tag area. Paul asked if
there isn't a problem with having the country code in the fixed
field and the $g and $h country codes or plain language. Subfield
code changes were discussed: $n Number to $a, adding $i
informational phrase [?], $p party to application, $q qualifier.
John questioned using country coding as part of numbering. Shelby
indicated her Patents Librarian was adamant it needed to included
with design patents. This proposal will be postponed until
Midwinter and discussed on the listserv.
Discussion Paper 80: Component Item Entry Field
Disposition: Discussion delayed until Midwinter
Lennie spoke to the background of this discussion paper. There is
linking to another record and linking to electronic representation
of data. The concern is more with linking. Paper to be discussed
at Midwinter.
General Discussion
John brought up ISO3166 and wondered if MARC commented. David said
the State Dept. uses different codes. Sally thinks a voting
representative for ALA is supposed to circulate documents to those
who would be interested in commenting. Myron Chase is the ALA
representative. John asked if MARBI is paying attention to the Text
Encoding Initiative (TEI) which contains file description
information. Sally said she sent Randy Barry to a conference held
at Rutgers on TEI.
Library of Congress