Single Records for Online Versions of Print Serials

Background:

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.

Proposal:

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.

Basic strategy for the record chosen:

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

Example:

(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

Questions raised:

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?

Go to:

CONSER Program Home Page
Program for Cooperative Cataloging Home Page
Library of Congress Home Page

Library of Congress