Library of Congress

Program for Cooperative Cataloging

The Library of Congress > Cataloging, Acquisitions > PCC > CONSER > Cataloging Issues > CONSER Aggregator Survey

Results of survey (as of Sept. 17, 2002)

Total responses received: 104

Nature of the responses:

CONSER institutions: 18

Most of the responses are from academic institutions, with a few public libraries. Most of these are small to medium size institutions, with few of the large research libraries, outside of CONSER. A number of responses were received from Canada and Australia. Many of the comments, particularly those received early on had few or no comments, while those received later contained extensive comments. Many others said they are using the CONSER single record option (using the print to indicate electronic access). The comments given in this report are selected and not complete.

Question 1: Should CONSER create a single record for titles in aggregations?

Yes: 100

No: 3 (1 of these is questionable)

No response: 1

CONSER response: all said 'yes'

Comments:

The one "no" that seems certain comes from a library in a consortium, saying that mixing libraries' holdings and multiple aggregations would be too confusing. However, others in consortia have written saying that a single record works fine for them. One of the responses called for a single uniform title but multiple records, but cited an in-house practice of using a single record for all electronic versions. The other "no" cited confusion caused by multiple records and perhaps should have been a "yes."

The no response said that it made sense at the national level but wouldn't work at the local level with their system (Innovative). The use of the same OCLC record for multiple sets with the same OCLC number would be a problem.

Others are overwhelmingly in favor of one record, citing the benefits to patrons, lack of confusion, the benefits of Serials Solutions having a good e-version record for use (rather than the print), and the overall clutter in the OCLC database. Many said that this is what they (or their consortia) are already doing. One respondent says there should be a separate record for each format and that the aggregators are not publishers and should not be separately represented. The changing nature of them is also mentioned.

Another library cited the problems with OCLC's service or supplying record sets. They purchased a record set for Kluwer but the records were filled with data for OCLC Firstsearch that had to be deleted.

A number of libraries, though understanding the nature of the proposal, said that they are using a single record for everything: print, electronic, and microform, and cited their catalogs.

Analysis: There seems to be a clear mandate to merge the records in OCLC and use a single record for all online versions of a serial.

Back to Top

Question 2: Is it acceptable that this record be based on the publisher's Web site?

Yes: 66

No: 9

Maybe: 1

CONSER response: 1 no (print)

Those who responded no with comments, said they would rather see the print version be used as the basis of the description or the earliest available issue in any format. One CONSER library suggested that using the aggregation being cataloged when publisher's web site not readily available. The problem of using the publisher's site when there may have been changes in the publisher is that the earliest issues may not be available and it bears no relation to the type of cataloging given to print or other formats. One respondent pointed out the variant titles used among aggregators and the need to provide access to these. The "maybe" referred to potential difficulties in finding the publisher's version on the Web and decided which publisher to use in the case of changes. (The proposal specifically said to use the latest publisher).

Comments from those who voted yes:

"Some kind of unifying approach is needed to make maintenance practical."

"Much preferable to the aggregator."

"It's not ideal, but the best choice."

"Yes, base the record on the electronic version since it is possible that current print titles will disappear."

"Not on the print version"

"Catalog the journal, not the provider."

Cite the source in the description based on, particularly when the publisher's site is not available and an aggregator is used.

"This is a qualified 'yes' as I am not completely comfortable with the concept of "generic" records. As a cataloger I'm trained … to completeness of information and completeness of records. … If we do this, then we really need to be willing to look again at this thing sometime later and study how it's working."

"I think there is a lot of objection to using the publisher's online version because of additional work if the person is cataloging a particular aggregator package for their library, we could say base the description on whatever version is available at the time of cataloging…"

"One thing I can't agree with in [in the proposal] is the comment that "most publishers make access to the "front matter" of their journals available freely on their Web site." To the contrary, I have found that the front matter is usually not available at all. This is one of the biggest challenges in cataloging online resources, and will become significant when different aggregators use varying forms of the title(s)."

Analysis: The use of the publisher's Web site for online serials seems to be acceptable to most. However, we should determine other alternatives and an order of preference and should no doubt cite the source of the description in the record.

Back to Top

Question 3: Which option do you prefer?

Option A (inclusion of aggregator-specific data): 39

Option B (no aggregator-specific data): 65

CONSER response: Option A: 8; Option B: 10

Nature of the responses:

Many of those favoring Option B are using Serials Solutions or another management company. Those favoring Option A site the need for CONSER records to serve smaller libraries that cannot afford a management company. Both arguments are well presented.

Comments concerning the choice of Option A:

"I chose A with the assumption that CONSER would work out something with a Serials Solution and not have to maintain the details. Absent that, I think B allows local control and local negotiation with the serials management companies, but only if the updates can be fully automated." {CONSER library}

"If we implement Option B, we'll need to get into a different mindset regarding record identification and selection. Currently we avoid using aggregator neutral records…because there's usually not enough information about any aggregator used…" (CONSER)

"We do not favor Option B. The records created according to this option would be too "minimal" to be useful without extensive local editing."

"We think it would be a disservice to use stripped down skeletal records that reflect no aggregator information. We think that the majority of institutions would be better served by the continued use of multiple records for aggregated versions rather than Option B proposed here. We believe that Option B would mean about as much local editing and maintenance on a day to day basis as we are doing now using multiple records. This does not sound like an improvement… Wouldn't inputting skeletal records with no aggregator information go against the original purpose of the shared databases…?"

"We would be happy with Option A only if any Enhance library can add, change or delete the aggregator information. If making changes is limited only to CONSER, we would prefer Option B."

"The maintenance of these records seems a daunting role for CONSER, but if available, we would prefer them."

"Option B would work if all records were authenticated."

Selected comments concerning the choice of Option B:

"We believe that a record that lacks URLs can be used by serial management companies to add the aggregators we subscribe to." {CONSER library}

"Our proxy string would need to be added to urls as in Option A and would be virtually useless without that proxy string. Because our ILS vendor does not make it easy to bulk add that string, Option B becomes better than Option A. Perhaps CONSER could work with ILS vendors to make import of such files easier?"

"I've not once found a URL on the utility which I could use as it stood for a paid subscription."

"It is easier to add than to add and delete."

"In customizing record set, it is easier to design a loader program to add data to a record. It is far more difficult to design a loader to delete data, especially if there are multiple pairs of 773 and 856 fields to choose from."

"…FRBR-wise, Option B has the Work and the Expression to be done on a national level, with the Manifestation to be done locally."

"I agree that CONSER catalogers' time is best spent not maintaining obsolete aggregator information."

"Our library is going more toward the use of core records for other items, so Option B fits in quite well with that."

"Please take into account consortium catalogs. Not all libraries in our consortium have access to all ejournals. Everyone sees the URL …but it only works at those libraries that pay for licenses."

"It is acceptable that the national database have minimal information in it for electronic serials. Because the information is always subject to change, it would be better to have less information than to have more but out-dated information."

"An additional factor that makes Option B potentially more attractive is the growing use of SFX software … …. Libraries using SFX may find it more beneficial to store URLs in the SFX server rather than in the bibliographic record. A more general bib record which describes the resource but does not attempt to convey the means to access the resource could be sued as a permanent complement to the access data supplied elsewhere."

Analysis: There is no clear-cut solution here. While the numbers would favor Option B, some of the strongest arguments were made in favor of Option A. The CONSER libraries are basically split down the middle. One of those favoring Option B currently does no maintenance on OCLC. The other split is between those who are using a management company and those who aren't. One of the considerations is the future of the universal holdings record and how this might impact on a decision made now. If aggregator information is retained in the record, might it not migrate into separate universal holdings records in the future? Exploring this might be an important aspect in coming to a conclusion. There has also been confusion among CONSER libraries as to what the application of Option B would mean. Development of a compromise proposal may be the only solution.

Back to Top

Question 4. If Option A is implemented, what information would you want to see include in what fields?

Kinds of information wanted:

Name of aggregator, URL, basic coverage information

Other information included:

ISSN (either the e-version only or both electronic and print)

Variant titles appearing on aggregations

Fields:

The majority respondents suggested a single 856 field that would contain the name of the aggregator, coverage, and URL. Others suggested the 773 as well. There were a number of other suggestions for places to include the aggregator name: 710, 730, 740, 500, 515, a new MARC field.

740 fields for title variations were also suggested.

Additional comments were received from those favoring Option B:

"Do not include because everyone will want some different method of access."

"Include locally only. The 773 field isn't always appropriate and some systems don't display it."

"We suggest using 246 for alternative titles. The additional requirement that 246 $i include the standard text "Also distributed as:" would be useful, in case the proliferation of alternative titles turned out to be a bad idea down the road."

Analysis: If Option A is implemented, we should limit what is included. Having access to the name of the aggregator, whether through a 7XX field or via the 856 seems useful. 246 variant titles also seem a good idea.

Back to Top

Question 5. If Option B is implemented, what mechanisms would your library use to identify the needed record to create access through the catalog?

Nature of responses:

There was some confusion on what was meant by this question. Most who favored Option A did not respond.

Many would use aggregators' lists of titles and ISSN to search for the records in OCLC. Some libraries (3) mentioned using a serials management company to do the work for them, although many more than this cited having signed on with one of these companies.

Comments on the ISSN included the fact that it is not always available and the fact that publishers sometimes use electronic and sometimes print. It was also noted that SFX uses the print ISSN as a linking tool and that the print ISSN is needed in addition to the electronic. This was noted a number of times.

Several libraries indicated that they still prefer use of the single record approach, using the print record for all versions. One library does not give access via the catalog.

Analysis: Supplying correct ISSN in these records seems to be of particular importance. Also finding solutions to the lack of effectiveness of the electronic ISSN alone and the need for the print ISSN in an 022 and not just in 776 needs to be addressed. It is interesting to see how many libraries plan to do the work locally.

Back to Top

Question 6. Further comments

"The serials management companies like Serials Solutions are crucial to this whole enterprise. We should work with them to automate as much of the process as possible.

"Endeavor is contracting with Serials Solutions to provide data to populate LinkFinderPlus. Perhaps CONSER could do likewise as a "multiple versions" ACCESS database converted to a gargantuan new MARC field."

"Desperately need a "work identifier" number for ALL e-journals: too many just don't have ISSNs."

Don't use the coverage note if first issue not in hand; too holdings-like and not practical for multiple aggregators.

"Should we consider the potential impact on the union lists (e.g., OCLC's) or ILL" While I really like this idea, there are administrative types who strongly favor all versions of a serial on one record. It's be nice if this is somehow addressed in any new guidelines."

"I think that the provision of the URL in the record is a mistake when the resource cannot be accessed by "anyone" using that particular URL."

"I think that this proposal is a step in the right direction for CONSER. I have been really frustrated by the overall lack of direction and standards with regard to electronic serials, so I'm glad to see this issue addressed. Thanks!"

"What is needed is a way to provide the patron with access to the resources without overburdening the cataloger with needless procedures and redundancies. The single online record for all version is one small step in the right direction."

"I have always believed in separate records for electronic version of the same (or similar) title. I am sorry it took so long for the standard-setters to catch on."

"I like the proposal. I think it holds great promise, whichever option is finally selected."

"A big issue for us is the mandated use of so many fields to let the patron know that the title is available online. Long records are a definite stumbling block to patron success in connecting to the desired articles. We also find that there is too much variation in how the 506, 516, two 538s, and a 550 are used in the contributed records we find on OCLC. … there should be a MARC field that gathers the online information into a concise and uniform structure …"

"My staff wanted me to remind CONSER to keep your eye on "real" aggregators in the future. Something will eventually need to be done with them too!"

"It's time we think philosophically how we distinguish bibliographic and holdings data for electronic resources. We may finally be able to move all the local notes, specific access restrictions, local URLs, etc. to their proper place--the holdings record. This may also be a good opportunity to test out the approach of cataloging the intellectual content instead of the carrier, albeit only in the electronic resources arena."

"I am so glad that CONSER is considering this thorny issue."

Back to Top