- BSLWAC - mailman.xmission.com

Project to remove RDA 7XX fields from AACR2 records
by Karen Anderson 18 Dec '12

18 Dec '12

As part of the conversion of the LC NAF, the 7XX fields on AACR2 records that have RDA forms (7XX _ 4) need to be removed and/or evaluated. There have been about 14,700 records identified that can be dealt with programmatically. These changes will be done in the LC database and distributed through the regular LC distributions. The project to do this will start January 7, 2013. They will change about 4000 records per day until done. This means there will be a few weekly update files from LC that will be significanly larger than usual. We want to make sure everyone is aware of these upcoming changes. If you have questions or concerns about how this will affect you and what your options are, please contact your project manager. Since it looks like the announcement was only sent to the PCC list, I'm including it in it's entirety below: "The PCC Acceptable Headings Implementation Task Group (PCCAHITG) designed plan for changes to the LC/NACO Authority File in the context of the adoption of RDA, including the phased changes to the authority file. As you are aware, the Phase 1 changes were completed in August 2012, and Phase 2 changes are scheduled for 2013. The Task Group has also identified a small subset of records that have 7XX fields with RDA forms that need to be dealt with before the Phase 2 changes begins. After reviewing options for manually changing the records, the Task Group developed plans to adjust most of the records automatically by program and issued that plan for comment on September 27th, 2012 (http://files.library.northwestern.edu/public/pccahitg/RDA_conversion.Rd a7xxFields.Automated.doc). In moving forward with this plan, a program was developed by Gary Strawn at Northwestern University. Over 17,000 records were identified, although some of these records will be reserved for manual treatment. After extensive testing by LC and Northwestern University, the number of records to be programmatically changed will be about 14,700. Categories of records that won't be adjusted programmaticaly include pre-AACR2 records (008/10= a,b, or d), records that contain a 7XX with an element that is a candidate for a change in Phase 2 regardless of the field in which it appears (e.g., abbreviations such as fl., ca., arr., O.T., Dept. ), records containing "Jr." in the 700 field, and others where the 7XX and 1XX were significantly different so as to warrant manual review. Like the Phase 1 changes, these records will be adjusted in the LC database and distributed to the NACO nodes and other CDS customers. The changes will begin January 7, 2013, with about 4,000 records adjusted per day until it is completed. These records will be issued in addition to the regular distribution of LC/NACO transactions. Once this small project related to RDA 7XX fields is completed, testing of the logic for the Phase 2 changes must begin-- we are now recruiting volunteers to help with this testing. If you are interested in helping, please send a note to the PCCAHITG member Karen Anderson kanderson(a)bslw.com by January 4, 2013. The timing of the Phase 2 changes will be dependent on successful testing, so any help is greatly appreciated." As you can see, I'm on the PCCAHITG, so if you have any questions about the RDA/NAF conversion, feel free to contact me. Karen Anderson Authority Control Librarian Backstage Library Works Provo, Ut 801-356-1852 ext. 231 800-288-1265 kanderson(a)bslw.com

1 0

Backstage - AACR2 vs RDA Stratification
by Nate Cothran 05 Dec '12

05 Dec '12

In geology, stratification can refer to the different layers of rocks that have formed over a given number of years. When it concerns AACR2 and RDA bib records, the word 'stratification' has started to gradually build up significant meaning for us here at Backstage. During my time spent as a member for the recent PCC Post-Implementation Task Group on Hybrid Bibliographic Records <http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja& ved=0CEAQFjAC&url=http%3A%2F%2Fwww.loc.gov%2Faba%2Fpcc%2Frda%2FRDA%2520T ask%2520groups%2520and%2520charges%2FPCC-Hybrid-Bib-Rec-Guidelines-TG-Re port.docx&ei=Zce_UI67JKq5igKw04AI&usg=AFQ> (June - Oct 2012), we discussed whether it was a good idea to suggest the creation of a new ID (040 subfield) for hybridized AACR2 bib records. The consensus was against this idea. So we are left with bibs that are either RDA or non-RDA. This is an oversimplification, but I'm hoping more explanation below might help illustrate some of our concerns. Our task group also could not definitively establish what the 'tipping-point' would be for determining when a bib record has crossed the threshold from AACR2 bib to clearly an RDA bib. We seemed to settle on the actual designation (i.e., adding 040 $e rda) only when the cataloger has the item in-hand and is re-describing the record to RDA format. Lacking the item in-hand means that the AACR2 bib could have any number of RDA-type elements (33X, etc) added to it, but the sum of these added fields still is not enough to confidently re-describe the bib as RDA. I think one of the main reasons was that, technically, most or all of these RDA-element fields are also fine being in AACR2 bibs. This brings us back to the stratification issue. Even though there may be many layers of fields added which would surely tip it over into being an RDA bib record, we cannot with confidence call it RDA unless there is an 040 $e rda field present. As there is no definitive ID present in a bib that has had RDA-type fields added to it-assuming absence of 040 $e rda-then our conclusion is that the record must be in AACR2 format. This doesn't seem right, but it is the case today. Consequences of this way of thinking means that, for some libraries that have us remove relationship designators (X00 $e) in AACR2 bibs but retain them in RDA bibs might run the risk of having us remove those from AACR2 bibs that have been hybridized with RDA elements. This is probably not desirable? And there might be other types of updates or validation (e.g., 250, 260, 300 field expanding abbreviations) performed on AACR2 or RDA records that would be preferable to also apply to those special hybrid AACR2 records. We welcome your thoughts on these types of matters as we inch ever closer to March 31, 2013. Nate Cothran Vice President, Automation Services 533 East 1860 South Provo, Utah 84606 Phone: +1.800.288.1265, ext. 697 Direct: +1.801.342.5697 nate(a)bslw.com <mailto:nate@bslw.com?subject=Automation%20Services%20-%20Inquiry> * www.bslw.com

1 0

Backstage - HTM to XLS Reports (ready)
by Nate Cothran 06 Nov '12

06 Nov '12

Almost exactly a month after we first brought up that we were working on a report conversion from HTM to XLS for our clients, it looks like we are ready to roll this out. We ran into a couple snags with getting the Python scripts to point to the correct version (2.7.3) on our system. We've also made a few updates (mainly cosmetic) to the scripts in how the XLS reports will display for you, though we welcome your feedback on how to potentially make them better. As an update, this conversion will handle nearly all of our standard and optional reports. The reports come pre-formatted so there should be little re-sizing, etc that you might feel the need to do. Since our initial offer a month ago, we've received quite a few requests for this, but if you've forgotten or wanted to wait until it was ready, please just let us know. These XLS reports will be automatically generated from this point onward for any client that has or will request them. Thanks, Nate Nate Cothran Vice President, Automation Services 533 East 1860 South Provo, Utah 84606 Phone: +1.800.288.1265, ext. 697 Direct: +1.801.342.5697 nate(a)bslw.com <mailto:nate@bslw.com?subject=Automation%20Services%20-%20Inquiry> * www.bslw.com

1 0

near matches after quarterly updates
by Ted Waller 25 Oct '12

25 Oct '12

In our III system, after we load quarterly authority updates we end up with a file of "near matches." This is supposed to be bib records that were near matches to authority headings. In reality, most of the bib records match the authority records exactly, not nearly. How have libraries dealt with this file. It's something happening on the local side, not Backstage, and best solution would be to not even have these records in the near match file but I don't know if that's possible. The next best solution would be an efficient way of handling the file. Ted Waller Carlyle Campbell Library Meredith College 919 760 8381

1 0

Backstage - HTM to XLS Reports
by Nate Cothran 08 Oct '12

08 Oct '12

Several of our clients have requested whether it was possible to deliver our reports in Excel format (XLS) instead of HTM like we do currently. While HTM allows for prettier displays than plain text, its two main detriments are the ability to re-sort the data or make any edits to it. Also, it is difficult to parcel the HTM reports out to colleagues or staff to tackle specific sections of the reports. In the past, we tended to think just copying the files to excel (copy *.htm *.xls) was the panacea we were looking for. But this introduces formatting errors and it never seems to be a clean one-to-one solution. We investigated changing our native code, which collates the headings, then generates them into respective HTM formatted reports. But this has proven to be far more difficult than we had hoped. Ultimately, we decided to convert the existing HTM files to XLS using the powerful scripting language, Python. Python has access to XML/HTML libraries which helped us to glean the information we needed from the HTM tables. Then, we used an XLS library to shunt that data into an XLS spreadsheet, formatting the cells & data on the fly as we went along. Because of the control we have addressing the conversion in this manner, we can also add in line numbers for each heading, as well as counts for entire reports. Some reports may or may not make that trek from HTM to XLS, however: reports such as R00 for Near Matches would take some serious work since it is very different from our other standard reports; also, R06 for Name headings has proven to be especially difficult, mainly due to the 1XX/240 combinations that are listed. With that said, we have most of the 'single-line' reports in good shape for a conversion between HTM and XLS. So, reports like: R06 (excluding Names), R07, R09, R10, R11, R13, R14, R25. We're currently working on reports with 'double-lines' like R30, R31, and R32 where the report lists an 'old' heading with a 'new' heading underneath. As a sample of what's possible so far, I've attached R25 - Unrecognized $z Subfields.xls to this email. This represents a straight conversion using our script, with no post-formatting done (all of that was handled via the script). It took about 1 second to convert this HTM report to XLS format. Out of the 96 headings in this report, there were 8 which our conversion had some issues with; even with those, we still list out the full heading for further review. Hopefully, as we make further progress on these conversions we can iron most of those issues. If this is something that you would be interested in having us start doing for your reports, please let us know. We don't think we are very far off from being able to do this, but we did want to let you know one of the things we have been working on. Thanks, Nate Nate Cothran Vice President, Automation Services 533 East 1860 South Provo, Utah 84606 Phone: +1.800.288.1265, ext. 697 Direct: +1.801.342.5697 nate(a)bslw.com <mailto:nate@bslw.com?subject=Automation%20Services%20-%20Inquiry> * www.bslw.com

4 5

Backstage - AACR2 Authorities Updated to RDA
by Nate Cothran 20 Sep '12

20 Sep '12

As catalogers begin making changes to existing AACR2 authorities and recode them as RDA (040 $e rda), it has consequences for our clients that are following any of our first 3 RDA options. A quick refresher (RDA options <http://ac.bslw.com/community/wiki/index.php5/RDA_2.4> ): 1. AACR2 & RDA against AACR2 only 2. AACR2 against AACR2; ignore RDA bibs 3. AACR2 against AACR2; RDA against RDA 4. AACR2 & RDA against AACR2 (1st), RDA (2nd) 5. AACR2 against AACR2 (1st), RDA (2nd); RDA against RDA (1st), AACR2 (2nd) The authority record for "Aristotle" (AACR2) was updated on July 18, 2012 with 040 $e rda as well as a few other changes [n 79004182]. Due to the 040 $e rda being added, however, that suddenly placed that authority (and others like it) out of the grasp of our clients that do not have us checking RDA authorities during matching. So if you have an AACR2 heading with "Aristotle" it will be listed as unmatched in our system, assuming we're using one of the 3 options listed above. In order to catch these scenarios, our recommendation is to change any client currently on Options 1-3 to Option 5 instead. We plan to enact these changes to your settings over the next several days. If you would prefer that we do not change your RDA option from 1,2, or 3 to 5 instead, please just let us know. Nate Cothran Vice President, Automation Services 533 East 1860 South Provo, Utah 84606 Phone: +1.800.288.1265, ext. 697 Direct: +1.801.342.5697 nate(a)bslw.com <mailto:nate@bslw.com?subject=Automation%20Services%20-%20Inquiry> * www.bslw.com

2 1

LC/NACO Authority File and RDA
by Karen Anderson 12 Sep '12

12 Sep '12

We thought it might be helpful for those of you who do NACO and/or want to keep up with what's going on with the LC Name Authority file to pass along this message from the PCC about interim NACO policies. If you have questions or would like more information, feel free to contact me. The copied message is below. Karen Anderson Authority Control Librarian 801-356-1852 ext. 231 800-288-1265 kanderson(a)bslw.com ------------------ The following message was sent out on the PCCLIST: There have been a lot of questions on PCC RDA NACO issues lately - thanks for being so careful in your NACO work. Your conscientious approach helps to facilitate the RDA transition of the LC/NACO Authority File. But along with so many changes - and with all of them taking place simultaneously -- it is very easy to become confused about what can and cannot be done in the LC/NACO Authority File. I hope this message helps to eliminate some of that confusion. I am not a policeman and I am not the reassuring voice of reason (alas), but I do receive a lot of questions and comments about what is going on in the NACO Authority File, and it makes me think that perhaps some sort of clarification on multiple topics is needed. 1) Approved PCC NACO Policies--Interim Documentation In March 2012, the PCC Task Group to Formulate or Recommend PCC/NACO RDA Policy on Authority Issues recommended NACO policies and best practices on authority issues in the RDA environment. These policies and best practice recommendations were reviewed by the PCC Policy Committee and either approved as submitted, or approved with revisions. All the approved policies are in force right now. The RDA Toolkit, the LC-PCC Policy Statements, and the Descriptive Cataloging Manual (DCM) Z1 are on track to be updated in October to reflect the final PCC-approved decisions on the recommended NACO policies and best practices. Until official NACO documentation is updated, PCC NACO catalogers should consult the Post RDA Test Guidelines <http://www.loc.gov/aba/pcc/rda/PCC%20Post%20RDA%20Test%20Guidelines.htm l> and consider the information on this page official PCC NACO documentation in the interim period. 2) Changes in the LC/NACO Authority File All PCC NACO catalogers should be aware of -- and read -- the document Changes to the LC/NACO Authority File: What LC-PCC RDA Catalogers need to know <http://www.loc.gov/aba/rda/pdf/lcnaf_rdaphase.pdf> . This document describes in detail the changes taking place in the LC/NACO Authority File and gives guidance on what you can, cannot, or should do with records in the file. This document impacts all NACO catalogers, not just those who have taken the RDA in NACO training. Everyone should be familiar with what is happening in the LC/NACO Authority File during the RDA transition. Please read and study p. 2-3 of the document. The following is directed to RDA-trained NACO catalogers: those of you who participated in the US RDA Test, or who have taken the RDA in NACO training modules and have participated in the two mandatory post-training webinars. * You may re-code an AACR2 authority record to RDA if the NAR does NOT contain a 667 note reading: "THIS 1XX FIELD CANNOT BE USED UNDER RDA UNTIL THIS RECORD HAS BEEN REVIEWED AND/OR UPDATED" and if the 1XX is already acceptable under RDA instructions and current PCC policy (see Post RDA Test Guidelines <http://www.loc.gov/aba/pcc/rda/PCC%20Post%20RDA%20Test%20Guidelines.htm l> ). At the time of the re-coding, you may optionally add additional fields (046, 37X, etc.) or 670 citations to the authority record. * You may reevaluate and re-code an AACR2 authority record to RDA if the NAR DOES contain a 667 note reading: "THIS 1XX FIELD CANNOT BE USED UNDER RDA UNTIL THIS RECORD HAS BEEN REVIEWED AND/OR UPDATED" The 1XX may need to be adjusted to conform to RDA instructions and current PCC policy (see Post RDA Test Guidelines <http://www.loc.gov/aba/pcc/rda/PCC%20Post%20RDA%20Test%20Guidelines.htm l> ). At the time of the reevaluation and the re-coding, please remember that many of the records with 667 notes are coded pre-AACR2 or AACR2 compatible, or are coded AACR2 but the RDA preferred form of name may be different. These 1xx's should be analyzed to determine the RDA preferred form of name before re-coding the authority record to RDA. This means that you may need to search in your database of entry, and/or you may need to evaluate the existing 670 citations to determine the preferred name. It is not enough to take a quick glance at the 1xx, accept what you see, and then re-code to RDA. At the time of the re-coding, you may optionally add additional fields (046, 37X, etc.) or 670 citations to the authority record. * Some AACR2 authority records whose 1XX is NOT suitable for use under RDA will NOT include a 667 field reading "THIS 1XX FIELD CANNOT BE USED UNDER RDA UNTIL THIS RECORD HAS BEEN REVIEWED AND/OR UPDATED" These records will be mechanically reevaluated and re-coded to RDA in 2013. Please exercise restraint in reevaluating and re-coding these records to RDA now. Many of these records reside in large hierarchies that will need to be re-coded together- let's let the machine take care of these and save us all some time. Thanks everyone, Paul Frank PCC Secretariat

1 0

X00 $e Relationship Designators - Controlled Vocabulary?
by Nate Cothran 06 Sep '12

06 Sep '12

With Day One of RDA Authorities coming up soon (March 31, 2013), we are exploring enhanced functionality for certain fields. http://metadataregistry.org/schemaprop/list/schema_id/4.html The Open Metadata Registry lists around 250 entries for RDA Roles. We distilled this 250-member group down to 126 distinct relator terms [abridger, actor, addressee, animator, annotator, appellant, appellee, architect, etc]. A lot of the terms had WEMI (Work, Element, Manifestation, Item) duplication, so we screened those out, which is how we ended up with 126 unique terms. However, we also looked at several of our clients that currently retain X00 $e (excluding 300 $e of course) within their bib records, whether those bibs are AACR2 or RDA. One client had 8 different types of X00 $e terms, though two of the terms [ill., illus.] appear to be the same type (illustrator vs illuminator). Another client had roughly 364 different types of X00 $e terms. But we noticed different spellings of the same type [aftist, aritst, arrist, artsit] which are most likely supposed to be (artist). So we wondered whether it would make sense to devise two separate lists for attempting to control relationship designators (X00 $e) in bib records: 1. One list of 126 (and growing) unique roles/designators as put forth by the Open Metadata Registry 2. One union list that is grown from different variations amongst our clients where some terms may or may not be part of the OMR list An example with #2 is that we found "attributed writer" in one of our client's records, though this is not present in the OMR list. It could be that this particular client prefers to retain this relationship designator rather than choose one of the current 126 designators from OMR instead. With either option, clients that wish to have some form of control applied to their X00 $e would have alternate spellings corrected to preferred terms for their ongoing current cataloging. List #2 would have more entries due to the sometimes subjective cataloging practice of RDA compared with AACR2. However, either list seems like it would be useful. We anticipate that we could employ this functionality in our current system very quickly, but we wanted to send this out and gather any comments (for or against) first. Please feel free to let us know what you think about this potential enhancement. Nate Cothran Vice President, Automation Services 533 East 1860 South Provo, Utah 84606 Phone: +1.800.288.1265, ext. 697 Direct: +1.801.342.5697 nate(a)bslw.com <mailto:nate@bslw.com?subject=Automation%20Services%20-%20Inquiry> * www.bslw.com

2 1

Phase 1 of RDA has Completed
by Nate Cothran 22 Aug '12

22 Aug '12

Karen Anderson, our Authorities Librarian and member of the PCC Acceptable Headings Implementation Task Group, has informed us that Phase 1 of the conversion of the NAF to RDA is now completed. This week's LC updates should be somewhat smaller than the previous few weeks, and after this should go back to normal size until Phase 2 (which is set to take place on or as near to Day One as possible-March 31, 2013). There may be a slight increase in the weekly updates as people review and update the records that got the 667 note during Phase 1, but Karen doesn't think it will be enough to impact most libraries adversely. We are grateful to Karen for this update and wanted to pass it along to all of you as well. Nate Cothran Vice President, Automation Services 533 East 1860 South Provo, Utah 84606 Phone: +1.800.288.1265, ext. 697 Direct: +1.801.342.5697 nate(a)bslw.com <mailto:nate@bslw.com?subject=Automation%20Services%20-%20Inquiry> * www.bslw.com

1 0

AACR2 & RDA Authority Control - 5 Options
by Nate Cothran 08 Aug '12

08 Aug '12

As promised, we are now ready to change over from our previous 7 options to our new 5 options for handling your AACR2 & RDA headings in authority control. The older 7 options included the possibility to match against 7XX-4 headings in AACR2 authorities and potentially flip to those same headings. The revised 5 options completely ignore the 7XX-4 headings in AACR2 authorities entirely. PCC will eventually expunge these fields from existing AACR2 authorities, so we wanted to be ready for that eventuality now. Although the majority of our clients have chosen / been assigned Option #1 (which did not change), this change from 7 to 5 will affect those clients that have chosen some of the later options. http://ac.bslw.com/community/wiki/index.php5/RDA_2.4 1. AACR2 & RDA against AACR2 only 2. AACR2 against AACR2; ignore RDA 3. AACR2 against AACR2; RDA against RDA 4. AACR2 & RDA against AACR2 (1st), RDA (2nd) 5. AACR2 against AACR2 (1st), RDA (2nd); RDA against RDA (1st), AACR2 (2nd) In each of the cases above, we are matching against the 1XX and 4XX in the respective authority file (AACR2 or RDA) and flipping to the 1XX version of the heading. Options #1 & #2 remain as they have always been. Options #3 & #5 are similar to the older version counterparts, except now the 7XX-4 is taken out of consideration. Option #4 has added RDA as a second step for matching on RDA records as that seemed to make more sense in this context. The above link goes into more details about each of these options. We have also put together a detailed table listing what is matched against for each controlled access point within your bib record: http://ac.bslw.com/community/wiki/index.php5/RDA_Matching_Options No further action is required on your part. If you had chosen one of the prior 7 options before, we have moved those of you from the obsolete options over to the new options. As always, we welcome your feedback so please let us know any questions or concerns you may have. Nate Cothran Vice President, Automation Services 533 East 1860 South Provo, Utah 84606 Phone: +1.800.288.1265, ext. 697 Direct: +1.801.342.5697 nate(a)bslw.com <mailto:nate@bslw.com?subject=Automation%20Services%20-%20Inquiry> * www.bslw.com

1 0