I also have limits on the number of authority records that I load each day. With a linked system it is hard to estimate how a given load will affect the system since a change to one authority record, linked to many bibliographic records, can and did bring the whole system down.
On another note, it appears that authority records that are not AACR2 or compatible are being deleted. I notified LC about one last year and was told it wasn't current cataloging, so the authority record was deleted. I have just 'reinstated' locally some authority records for pre-AACR2 headings... things that would not be established now. I cannot re-catalog to AACR2 all those titles and think it is counter-productive for these authority records, which represent standard cataloging of the time, to be deleted. The 'unsuitable note' should be added to these instead. A 'pure' RDA authority file is probably an inappropriate goal.
Mary Charles Lasater
From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Moore, Richard
Sent: Monday, April 23, 2012 2:32 AM
To: [log in to unmask]
Subject: Re: [PCCLIST] Alternates for the RDA conversion
I'd like to add some further comments to this.
Concerning the coding of records, if records coded 008/10=c are defined, at a given stage in the conversion, to be valid for use under RDA, then their remaining coded "c" need be no more problematic to man or machine, than the current status of 008/10=d as valid for use under AACR2.
Under both the original proposal, and the improved Option 3, all authorised access points needing manual review will be flagged with a
667 note. Mention is made below of "AACR2 headings not suitable for RDA that need to be marked for review, e.g. headings qualified by degree (Ph.D.)". As I understand it these fall under Phase 1 of Option 3:
"Records whose 1XX is not suitable for use under RDA without review (pre-AACR2, AACR2-compatible and certain AACR2 records)". The scope of "certain AACR2 records" is one of the things the Task Group is reviewing, with particular reference to the content of $c subfields, and subject to the next round of RDA change proposals to be considered by JSC, which may or may not broaden the scope of what is allowed in RDA.
Our main issue with the "NACO distribution pipeline" is the ability of our own system to digest changes on the scale that was originally proposed. From the point of view of this large, national library, it's not the case that "changes to large numbers of records are not a problem as long as the heading (1XX) itself stays the same". Any change to an authority record in our system automatically reindexes all our bibliographic records that use that authority, regardless of whether the authorised access point has changed. This function can not be switched off or circumvented. Given the other processes that need to be run constantly on the system, redistribution on the scale that was originally envisaged would cause a major headache, to say the least, which is why we greet the Implementation Task Group's revised scenarios with some relief.
Authority Control Team Manager
The British Library
Tel.: +44 (0)1937 546806
E-mail: [log in to unmask]
From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Joseph Kiegel
Sent: 21 April 2012 00:18
To: [log in to unmask]
Subject: Re: [PCCLIST] Alternates for the RDA conversion
Comments from the Univ. of Washington, after discussion here:
The original proposal from the task group has many strengths, as outlined in the alternate scenarios: headings not suitable under RDA are clearly identified, all records that may receive 046s and 378s get them, and all records suitable for use under RDA are coded as such.
These are goals worth achieving.
It is important to acknowledge that the authority file is not only for human use but also for machine use. The presumption voiced on this listserv that catalogers can tell which headings are usable is not true in a machine
environment: the computer will not know which headings are usable.
As PCC plans to use the authority file in a linked-data environment, it will be very important to populate the file with needed data elements, and the
046 is one of them. It would be unfortunate to fall back on partial and manual addition of this field, when it can be done programmatically by machine.
The authority file also needs clear coding on the status of records.
That is, AACR2 headings suitable for use under RDA need to be coded as RDA. A situation where machines need to ignore coding and make assumptions about what it "really" means is fragile and does not provide a sound basis for the authority file. The library world may be able to limp along with this, but when these data are exposed on the Web, records need accurate and current coding.
We support the task group's original proposal and do not find any of the alternate scenarios acceptable for the long term. If an alternate scenario such as Alternate 3 is required in the short-term, it has to be packaged with a specific plan to remedy its shortcomings. The "Left for the future"
section of the scenarios document does not provide that plan.
In our view, the real problem is the capacity of the NACO distribution pipeline. It was adequate in the past, but not in today's environment.
Rather than discussing inadequate alternate scenarios, we would rather see the discussion shift to how the pipeline can be brought up to a capacity that meets current demands. This seems like a better solution to the problem, and will allow the authority file to migrate to the form it needs.
In our view, a minimum capacity for the pipeline is 10% of the file per day, which would be about 800,000 records/day. This would allow a complete reload in 10 days, which is still a long time, but acceptable.
Surely future plans to "pour it into a new data structure" will require this kind of capacity, so we may as well start now.
From the point of view of a local library, changes to large numbers of records are not a problem as long as the heading (1XX) itself stays the same. We can load hundreds of thousands of records quickly if the only changes are added note fields or changes to coded values.
Comments on specific alternates:
Alternate 3: it does not seem to cover AACR2 headings not suitable for RDA that need to be marked for review, e.g. headings qualified by degree (Ph.
Alternate 5: this looks acceptable if it can be carried out in the week described. However, if pipeline capacity is an issue, we do not understand how this is possible.
> -----Original Message-----
> From: Program for Cooperative Cataloging
> [mailto:[log in to unmask]] On Behalf Of Gary L Strawn
> Sent: Friday, April 13, 2012 3:20 PM
> To: [log in to unmask]
> Subject: [PCCLIST] Alternates for the RDA conversion
> The PCC Acceptable Headings Implementation Task Group has received a
> number of comments suggesting that the work plan devised by the
> earlier PCC Task Group on AACR2 & RDA Acceptable Headings for
> manipulating the LC/NACO Authority File for use under RDA involves the
> unnecessary re-issuance of too many records over too great a span of
> time. The present task group has devised a number of alternate
> scenarios, described in the attached document. (This document is also
> available from the Task Group's download site:
> http://files.library.northwestern.edu/public/pccahitg) All these
> scenarios involve the performance of RDA-related mechanical changes
> described in documents previously distributed by the task group
> becomes "Department", for example), but differ in other changes to be
> made, and the schedule on which the changes are performed.
> The task group invites public discussion of the merits of the original
> plan and the proposed alternates, and is happy to entertain
> suggestions for yet other possibilities. Even if you've expressed an
> opinion on this matter before, please do so again, as the audience may
> now be a bit broader.
> Gary L. Strawn, Authorities Librarian, etc.
> Northwestern University Library, 1970 Campus Drive, Evanston IL
> e-mail: [log in to unmask] voice: 847/491-2788 fax:
> Forsan et haec olim meminisse iuvabit. BatchCat version: