I believe the user tasks that we are trying to support are to_/ i)/
_describe the extent of the item to be cataloged in one sub-field of a
field, e.g. pages, volumes, cassettes, total playing time, etc.; and
_/ii)/_ differentiate multiple part and serials items from monograph
item, sound recording, videodiscs, music score, etc. in a catalog under
the constraint of number of fields to be displayed by the local catalog
database, and system compatibility requirements, where items of multiple
arrays have been served through a single "flat" and one-size-fit-all
database, which has been changed from mainframe, client-server systems,
multitier architecture systems with Z39.50 and Web as front end to Web
as Infrastructure over the years.
In addition to the changes of system architecture serving the creation,
search and retrieval of bibs in a catalog database, all the subfields of
a field in a bib record have to survive the following:/_
_/
1. changes of the cataloging rules e.g. ALA rules, AACR1, AACR2,
various interim guidelines, etc.
2. changes of encoding schemes, USMARC, etc. and cross walks;
3. field indexing and display battles that we are all familiar with,
e.g. which field goes into brief vs. long display and which field
is used for keyword search, fielded search and hot-linked search
keys in simple, advanced, federated, mobile-search, and other
forth-coming modes, e.g. social and semantic modes;
4. variations of cataloging practice that catalogers have to work
around - _/4.1) /_with local ILS systems, _/4.2)/_ in compliance
with resource sharing agreement with bibliographic utilities,
consortium, and distributed multiple campus networking
environment, /_4.3)_/ pressure to produce, e.g. quota, and_/
//4.4)/_ little admin support.
What is more, such subfields have also to survive the limited amount of
access permission of the systems given to professional catalogers for
record creation, database cleanup, and data quality control using
quantitative measures; and availability of good copies/examples to follow.
Most catalogers have to make decisions in the dark for compatibility
issues and display limits at subfield, field, and bib level within a
bib, and in resource sharing environment within the constraint of their
local system implementation, particularly when standards are behind the
needs to provide access for the items to be cataloged.
In the context of compatibility requirements and constraints as what
I've described above, the approach for designating 300 $a for items with
non-transmedia format can be illustrated as the following:
11 v. :$bill. ;$c24 cm
32 p. :$bcol. ill. ;$c26 cm.
1 sound disc (46 min.) :$banalog, 33 1/3 rpm, stereo. ;$c12 in.
11 sound discs (13 hr., 3 min.) :$bdigital ;$c4 3/4 in.
1 videodisc (60 min.) :$bsd., col. ;$c4 3/4 in.
1 videocassette (ca. 124 min.) :$bsd., col. with b&w sequences ;$c1/2 in.
1 score (79 p.)$c26 cm.
1 online resource (1 map) :$bcol. +$b1 pamphlet (18 p.).
It gets complicated when cataloged items are in transmedia format. The
extent of the item to be cataloged does not change whether the form of
items is in:
1. tangible form 008/22 q - "Direct electronic" or
2. intangible form 008/22 o - "online" or
3. other formats such as 008/22 b - "Microfiche," 008/22 # -Blank,
e.g. print, etc.
In such case, the 300 field is left blank or something like "XML encoded
text" is in its place. The last mile that we created for the user to
figure out the extent of the item is to check into 534 field or 362
field if the field gets displayed in the OPACs by the cataloging agency
and systems implementation teams. An example for the item might be:
534 ##$pTranscribed from:$tBeyond illustration : 2d and 3d
digital technologies as tools for discovery in archaeology
/ edited by Bernard Frischer, Anastasia Dakouri-Hild.
$cOxford : Archaeopress, 2008.$exxiv, 168 p. : ill. (some
col.), maps (some col.) ; 30 cm.$z9781407302928
$z1407302922
How realistic is it for a medium-size library with a collection of 1
million items and staff of less than five to add such subfields in the
field within each bib bundled inside a package of hundreds or thousands
of bibs to be processed manually due to the fact that no access granted
to catalogers for batch processing tools ranging from editors, loaders,
data recovery utility, report writer, to analytical measures for data
quality control? It's another story as far as how catalogers have
creatively worked around the limits of these tools.
It seems redundant when 300 $av. and 362 $a, e.g. Began with vol. for
1978, both presented in a bib. When we have to struggle with number of
fields to be displayed, we have to weigh our decisions based on:
1. collection size;
2. trends of top-searches and subsequent users' behavior for online
vs. print, multimedia vs. transmedia, etc. mixed in the
collections that have been served within the constraint of a
single database for one-size fit all contents, media, and carriers.
Not all local catalogs could display the extent, numeric and
chronological designation of a journal in one brief display, e.g.
300 ##$av. :$bill. ;$c28 cm.
310 ##$aAnnual
362 1#$aBegan with vol. for 1978.
The term "volumes" or "v" becomes useful when you see the forest of bib
control environment, not just the single leaf. I checked into J. McRee
Elrod's comment on 300 $a electronic texts ( v. : ill.) last night.
For items in transmedia format, unless 534 field is used, catalogers
have to work around again as the way Mr. Elrod illustrated or use 506
field unless the ILS systems can populate 534 field based on 007/01, and
other fields under the condition that full-MARC compatibility have been
enforced by the cataloging agency and local system implementation over
the years.
For items in non-transmedia format, new 336, 337, and 338 fields can
alleviate problems to describe content type, media, and carrier, e.g.
http://www.loc.gov/standards/valuelist/marcsmd.html. But the controlled
terms that we've used are not in alignment with the common vocabulary
used by end users. For instance, how often do we call a "movie" for a
"motion picture?" Imagine that if we tell our friends, let's go for a
motion picture tonight, and how they would look at us.
In summary, our strategy to implement RDA has to include the principle
of "honoring tradition and embracing future in K.I.S.S. (Keep It Simple
and Stupid) manner." I can imagine that once LC and OCLC finalize their
policy statement <http://www.oclc.org/us/en/rda/policy.htm>, ILS vendors
and libraries have to come up with internal policy and procedures to
work around again. Sorry about the long message!!! Like everyone else
in this list, I am still pondering, exploring, learning, creating,
contributing, and sharing as I go along. Hope it helps!
Cheers,
Amanda Xu
On 9/23/2010 11:45 AM, Jonathan Rochkind wrote:
I have never understood why cataloging standards result in:
300 $a v.
Even knowing that stands for "volumes" -- why is this supposed to be
useful? I get when it says "2 v.". That's telling you there are two
volumes. But when it just says "v." -- can anyone explain to me what
the point of this is supposed to be? Is this supposed to be useful
information somehow, "v." ?
Jonathan
J. McRee Elrod wrote:
Jacqjie Samples said:
I have a question about recording 300 $b and $c for print serials
that are >not yet complete
Our clients will not accept an empty 300$a with AACR2, and I assume they
will not accept it with RDA. They want an SMD, whether it be:
300 $a electronic texts
they reject "online resource" as too general
300 $a v.
becoming
300 $a volumes
Just as $a will change when completed, so may $b and $c. But they
want what is now known, e.g.:
300 $a electronic texts ( v. : ill.) :$bdigital file the PCC PN
BSR moves "ill.: to $b, and omits "digital file"
300 $a v. :$bill. '$c28 cm. becoming 300 $a volumes
:$billustrations ;$c28 cm.
As a paid outsourcer we must provide what our clients say their
patrons want, rules, LCRIs etc. notwithstanding.
Notice the spaces after $a, which our clients now want to distinguish
"v." for volume from "v" for five. Whether whey will want the spaces
with "volumes" we don't yet know, but we use them with "electronic
texts".
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__________________________________________________________
--
--
Amanda Xu
Assistant Professor
Information Technology Librarian for Collection Management
Room 0364F Bldg LIB
James E. Walker Library
P.O. Box 13
Middle Tennessee State University
Murfreesboro, TN 37132
a...@mtsu.edu (email)
615-904-8510 (office)
