We’ve taken a similar approach on Aleph, to avoid typos and encourage consistency. We have macros that insert complete 377 fields containing the most commonly used language codes, and 375 fields for the most popular genders. For example, ##fre inserts:
377 $s fre
For 368 and 374 we have drop down menus, from which a cataloguer can select the LCSH terms that data mining indicates we used most often in the first two years after NACO RDA implementation. The 374 menu also inserts appropriate corresponding 372 fields. For example, a cataloguer keys ##374 to invoke the menu, and selects “Librarians”. Aleph inserts:
372 $a Library science $2 lcsh
374 $a Librarians $2 lcsh
Data mining suggested that “College teachers” was the 374 term we had used the most, so we created a separate menu for that, invoked by the macro ##tea (and rejoicing in the name of “tea menu”). This provides options for discipline. For example, selecting “Computer science” will cause Aleph to insert:
372 $a College teaching $a Computer science $2 lcsh
374 $a College teachers $2 lcsh
A similar menu for 370 lists the most commonly used associated countries from LC/NAF.
We have local copies of both LC/NAF and LCSH sitting on Aleph. If a cataloguer needs to insert a term that is not in one of the menus, they can jump from a field in their new authority record to browse either file, and insert the term directly into the record.
This was initially a way to speed up the extra work involved in creating a good RDA authority record.
Authority Control Team Manager
The British Library
Tel.: +44 (0)1937 546104
E-mail: [log in to unmask]
Thanks for these appropriately curmudgeonly exhortations. I especially commend your advocacy of copy-and-paste, and looking at the actual authority instead of acting on a list of search results alone.
At the Folger, we have created in Connexion a number of local constant data records for the 3xx fields, focusing on recurring individual attributes and clusters of attributes. For example, if I am creating a NAR for a printer, I invoke the CD "printer" which inserts appropriate fields. I don't need to remember which field contains gender or language: typing ctrl-b and 'male' or 'eng' inserts the fields properly tagged and formatted. It's taken a long time to set up, but we believe it will easily pay off.
General question about the form of calendar dates in the 046. I do not have direct access to ISO 8601, but everything I read about formulating calendar dates--with the exception of LC-PCC PS 126.96.36.199--states that year-month-day is to be represented yyyy-mm-dd, that is, with the hyphens (http://www.iso.org/iso/home/standards/iso8601.htm); some sources also give the alternative as yyyymmdd (https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates). If these sources are correct, why did LC-PCC choose to require the alternative formulation? It's harder to read, and therefore proofread. By clashing with the required yyyy-mm formulation, it's non-intuitive, a cataloger's shibboleth.
Can anyone involved with that decision speak to this?
Deborah J. Leslie | Folger Shakespeare Library | [log in to unmask] | 202.675-0369 | 201 East Capitol St., SE, Washington, DC 20003 | www. folger.edu
From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Gary L Strawn
Sent: Monday, 13 April 2015 09:35
To: [log in to unmask]
Subject: Re: [PCCLIST] Best practices in updating authority records
[DJL: ] <...>
2) If you're going to use the 046 field, read the documentation; you aren't free to guess or make something up. Common errors:
If you only have a month and a year, a hyphen is required (this does not mean you necessarily have "$2 edtf")
If you have "$2 edtf" then hyphens are *required* between year and month, and month and day
The order of date elements is year-month-day. Not year-day-month; not month-day-year; not day-month-year. Largest to smallest in scope; it's actually quite simple.