Helen, I'm interested to know why you have decided to change them back to AACR2. Have you found problems with having both sorts of records, or are you trying to avoid confusion to staff and students? Or something else I'm missing?
Nicky Ransom
Data Quality Manager & Cataloguer
The Library
University for the Creative Arts
Falkner Road
Farnham
Surrey GU9 7DS
Tel: 01252 892739
[log in to unmask]
www.ucreative.ac.uk
One of Europe's leading arts and design institutions, the University for the Creative Arts builds on a proud tradition of creative arts education spanning 150 years. Our campuses at Canterbury, Epsom, Farnham, Maidstone and Rochester are home to more than 7,000 students from more than 70 countries studying on courses in art, design, architecture, media and communications.
-----Original Message-----
From: CIG E-Forum [mailto:[log in to unmask]] On Behalf Of Helen Williams
Sent: 18 April 2011 12:18
To: [log in to unmask]
Subject: Re: CIG E-forum: incoming RDA records
Thanks Celine
That's all really helpful. Just to say what we're doing here - I've got
a guidance document on our wiki, which I've spoken to all the team
about. It identifies, how to spot an RDA record, how to change it to an
AACR2 record (we are not contributing to OCLC so we're not causing any
exchange problems by doing this!) and suggests when to ask for help.
I ran the test Celine talked about last week (on the 040 $e) and was
relieved to find that we only had 12 RDA records which had slipped
through the net. Like Celine I've gone through the history, and in our
case all of those were downloaded from OCLC and the need to make
amendments not spotted. The history tab is useful sometimes as I've now
been able to ask the relevant people to make the necessary amendments,
which I hope will make it easier for them to spot another time.
Helen
-----Original Message-----
From: CIG E-Forum [mailto:[log in to unmask]] On Behalf Of C.J.
Carty
Sent: 18 April 2011 11:58
To: [log in to unmask]
Subject: CIG E-forum: incoming RDA records
To follow on what Rosemary & Hugh have said, I did talk a bit at the
Exec Briefing about what we've found in Cambridge in our tracking of
incoming RDA records.
We set up a specific search (that allowed us to search regularly for
records containing 040 $e rda) and have been tracking incoming records
since the start of the US Test in October 2010. There were very few
records at first but a small but increasing number since January.
Rosemary is right, there are issues of what we've been terming "hybrid"
records that identify themselves as RDA (usually in the 040 $e and also
often by using i
(ISBD) or blank (non-ISBD) in the Leader but which contain non-RDA
features and lack other core RDA elements: eg. lacking 336-338
content/media/carrier terms
containing AACR2 abbreviations in 300, 504, etc (or a mix of fully
spelled-out forms and AACR2 abbreviations)
lacking the copyright symbol for copyright date in 260 $c (using
the
AACR2 "c" instead) and various other combinations.
I've been tracking these back to source. In one case, they were vendor
records and were coming from the vendor (who shall remain nameless as
I'm not sure they're here to explain their policy) in this form, with
most of the identifiable RDA characteristics stripped out but not the
040 $e and Leader codes.
In other cases, we were able to diagnose local editing where a member of
staff (say at the point of ordering, so not a cataloguer) has seen
strange fields and decided to remove them.
In a number of other cases, the records (usually imported from OCLC)
looked hybrid in OCLC but could be tracked back to the creating library
(often Chicago or Stanford) and their own OPAC was fully RDA. We suspect
in these cases issues with OCLC record merging or some kind of other
editing happening once the records are in OCLC. I have reported a couple
such examples to OCLC but haven't yet heard back anything specific. I
think it's important to report them if you do identify a case such as
this. At the Exec Briefing, Glenn Patton of OCLC mentioned that they may
need to refine their record merging processes and their validation of
RDA records so this information would be useful to them.
We have dealt with this internally by regular monitoring of records
which self-identify as RDA and also by issuing guidelines on how to deal
with incoming RDA records (at acquisitions/ordering stage or in copy
cataloguing workflows). Our decision has been to say people should not
edit RDA records
*at* *all* (since they have not yet been training in RDA cataloguing) if
those records are coded Full or Core level in the Leader. That way, we
can easily identify them and deal with them collectively once decisions
have been made about implementation. However, for any RDA record less
than Full/Core level, we suggest that an alternative AACR2 record is
sought (first preference) or the record is converted to AACR2 (with
detailed guidelines on how to do this to try to ensure no RDA elements
are missed in this conversion). We have a large number of people
involved in cataloguing compared to many institutions and have also
recommended that staff report RDA records to their head of department
who will in turn report any anomalies/problems/questions to the RDA
working group.
Sorry for hte lenghty email, I just thought this might be of interest to
those libraries already encountering RDA records and a warning to
everyone that this will start to happen very soon in almost all
databases.
Celine
On Apr 18 2011, Rosemary Stenson wrote:
> We certainly have encountered an increasing number of RDA records from
> al of the sources mentioned by Hugh ; OCLC, LC & RLUK. We have given
> our cataloguers an overview in RDA in order to identify these records
> and they are instructed to convert them to AACR2. It's been
> interesting to note however the number of error in these records, e.g.
> records coded as RDA but with abbreviations still being used in
physical description, etc.
>
>Rosemary Stenson
>Head of Cataloguing
Please access the attached hyperlink for an important electronic communications disclaimer: http://lse.ac.uk/emailDisclaimer
|
