Related documents: |
Cataloging multiple manifestations of a publication on a single bibliographic
record is a dream that has led to
some marvelous theorizing, but few practical results as yet. There is one specific
area in which publishing
trends are forcing us to accelerate our attempts, in at least one area: the
proliferation of remote access
versions of serials.
CONSER has recognized that although remote access serials with differing formats
may properly be cataloged
on one record, this concept has not been applied to different editions:
31.3.4. Multiple document formats. Electronic serials may be issued in different
"file" or "document" formats in order to meet the needs
of their users. Some can be issued as plain ASCII text documents. Some are available
in "formatted" text versions, such as TeX or PostScript .... A serial
may be available in one, all, or a combination of these formats, and over time,
the available formats may change .... Current CONSER policy is to create only
one record with a note (usually 516) that lists the various document formats
in which the electronic serials has been issued ...The need for a CONSER policy
is based on the realization that the rules for edition and notes relating to
online editions (AACR2 9.2 and 9.7B7) do not cover either traditional serial
editions or these types of document formats. Rather, they focus on revised or
updated "versions," such as upgraded versions of computer software.
-CONSER Cataloging Manual
CONSER has, until now, created new records for each aggregator's (defined by
CCM as an umbrella term for
all types of publishers of remote-access serials) version of a remote-access
serial, if any electronic-version
record is used (CCM31.3.5C). Historically, imprint changes in a print serial
have not led to a new record; but
print serials do not continue to be produced under two different imprints over
time; however that has apparently
become the norm in electronic journal publishing. The proliferation of separate
records for different versions
increases the likelihood of inadvertent duplication, frustration for searchers,
and irritation and confusion for all
concerned. The time has come to revisit how to provide a less-confusing catalog
record, while minimizing the
amount of local editing that must be done, since the need for extensive local
editing undermines the purpose of
identified authenticated serial records.
Catalogers should use one bibliographic record for all iterations
of an online version of a journal,
that, in its print counterpart, would be cataloged on a single record. This
concept applies to electronic titles that
are new to the database, as well as those that have multiple records already
existing in the utilities. By allowing
the main description to be "aggregator neutral" we can eliminate the
need for record editing and simplify the
national database. Automated addition of desirable, but not essential fields,
such as file formats, and system
requirements can certainly be done at the local level.
1. Leader/07=s
2. 022 field: e-ISSN: use subfield "a"; print ISSN: use subfield
"y"; if the e-ISSN and the print ISSN exist on the
resource, use both in one 022. Example:
022 1534-2345 $y 0002-1345
3. 130 field: Use the qualifier (Online) and any other terms which need to
be brought over from the print version.
Do not use terms indicating the online publisher or aggregator. Example:
130 0_ Cell stress & chaperones (Online)
not
130 0_ Cell stress & chaperones (Online : BioOne)
4. 246 field(s). Use for titles that may appear on various manifestations. Example:
246 1_ $i Title on University of Chicago Press title bar: $a E-AJS
5. 260 field: To the extent possible we should put the "primary publisher"--the
publisher of the content, not the
aggregator--in the 260. Do not use a date of publication. This information goes
in the individual 856 subfield
"3."
6. 362 field. Do not use.
7. 500 field. Use a description based on note, basing it on the first iteration
to be cataloged. Use the name of
the aggregator/publisher in parentheses after the numeric and chronological
designation. Example:
500 Description based on: Vol. 31, no. 1 (Jan. 2001) (Project Muse); title
from journal home page (viewed
Apr. 12, 2002)
8. 506 field. Do not use. If needed, restrictions on access may be added in the 856 subfield "z."
9. 516 field: Do not use.
10. 538 field: Use only for Mode of access note.
11. 710 field. Do not use a commercial publisher/aggregator in the master OCLC
record. This should be
reserved for local use
12. 773 field. Use this field as a host item entry for the database/aggregator
home page. Normally use first
indicator "one" so that the host won't display in the OPAC. There
(will be) a list of publisher/aggregators with
their respective OCLC numbers maintained in Module 31. Example:
773 0_ $t ScienceDirect $w (OCoLC)45128052
13. 776 field. Use to link to other formats. Use the appropriate ISSN in subfield "x." Example:
776 1_ $t Cell stress & chaperones $x 1355-8145 $w (DLC)sn 96039532 $w (OcoLC)35230300
14. 856 field(s): Add URLs for each iteration. With each URL added, put the
complete holdings coverage
offered by the distributor in subfield "3" (this may not be the coverage
for which the institution has licensed
access). Record the issue designations in the same manner as they appear in
the 500 DBO note.
856 40 $3 v.31(1997)-v.34(2000) (Project Muse) $http://muse.jhu.edu/journals/milton%5Fquarterly/
856 40 $3 v.31(1997)- (FirstSearch) $u http://firstsearch.oclc.org/journal=0026-4326;screen-info;ECOIP
856 40 $3 v.31(1997)- (Ebsco) $u http://www.egbsco.com/online/direct.asp?JournalID=101046
856 40 $3 v.35(2001)- (Ingenta) $u http://www.ingenta.com/journals/browse/bpl.milt
(Based on two OCLC records #45312161 and $42017129)
OCLC: 45312161 Rec stat: c
Entered: 20001109 Replaced: 20020315 Used: 20020415
Type: a ELvl: 7 Srce: d GPub: Ctrl: Lang: eng
BLvl: s Form: s Conf: 0 Freq: b MRec: Ctry: ilu
S/L: 0 Orig: EntW: Regl: r ISSN: 1 Alph: a
Desc: a SrTp: p Cont: DtSt: c Dates: 2000,9999
1 010 2001-211372
2 040 RCE $c RCE $d NSD $d OCLCQ
3 006 [m d ]
4 007 c $b r $d c $e n $f u
5 012 $l 1
6 022 0 1537-5390
7 037 $b University of Chicago Press, 1427 East 60th St., Chicago, IL60637
$c $198.00
8 042 nsdp $a lcd
9 082 10 301 $2 13
10 090 HM1 $b .A7
11 049 CUSL
12 130 0 American journal of sociology (Online)
13 210 0 Am. j. sociol. $b (Online)
14 222 0 American journal of sociology $b (Online)
15 245 00 American journal of sociology $h [electronic resource].
16 246 13 AJS
17 246 1 $i Title on University of Chicago Press title bar: $a E-AJS
18 260 Chicago, Ill. : $b University of Chicago Press,
19 500 Description based on: Vol. 106, no. 1 (July 2000) (University
of Chicago Press); title from contents screen (viewed
Oct. 30, 2001).
20 530 Online version of a print publication.
21 538 Mode of access: World Wide Web.
22 650 0 Social sciences $v Periodicals.
23 650 0 Sociology $v Periodicals.
24 710 2 University of Chicago.
25 773 0 $t University of Chicago Journals Division $w (OCoLC)44248181
26 773 1 $t JSTOR $w (OCoLC)36027621
27 776 1 $t American journal of sociology $x 0002-9602 $w (DLC)
05031884 $w (OCoLC)1831931
28 856 40 $3 v.106:no.1(2000:July)- (University of Chicago Press) $u
http://www.journals.uchicago.edu/AJS/journal/home.html
29 856 40 $3 v.1:no.1(1895:July)- (JSTOR) $u http://www.jstor.org/journals/00029602.html
1. If this technique is adopted what information will be lost?
2. How many notes do we need? Are the notes in the above section enough?
3. Potential problems of having different standards for monographs and integrating resources?
4. How do people make use of these records?
5. Is the description of this "aggregator neutral" record too generic to be of use?
6. What is the impact on usability to libraries? Will catalogers mind stripping
multiple URLs from the cataloging
record (with the full realization that they won't have to recatalog if their
library changes vendors next year!)
7. What to do with existing records? redo as they are come across? project?
8. Would this approach be sustainable, easy to interpret, and maintain? We
are trying to create a record that
would require very little maintenance to the basic description.
9. What about non-CONSER libraries that want to add information about a new
aggregator? notify their closest
CONSER neighbor? notify OCLC through the 952 field? do it locally?
10. What about non-aggregators that have input records for online versions?
OhioLink has input over 700
journal records with a URL that is OhioLink specific. Add these to the merged
record? Delete?
11. What about OCLC's need to record holdings associated with individual purchases?
How would they handle
this with such an approach? Would stepping up OCLC WorldCat Collection Sets
be an answer here?
12. How do vendor solutions, such as TDNet and Serials Solutions fit into this?
It would seem as if the vendors
would appreciate having a clean generic record to with which to work.
13. Is an aggregator equivalent to a print subscription provider?
14. If this is accepted, should there be an LCRI? information about this in Module 31?
15. If this proposal was acceptable to CONSER, but unacceptable to some significant
portion of other OCLC
users, what kinds of problems would result from allowing the single provider
records to continue to exist?
Related subsequent documents: |
Go to: