This quarter has been a busy one for us at Backstage in the Authority Control / Automation service dept. We always get together and discuss upcoming goals and apply priorities to those goals throughout the year, just as everyone on this list participates in their own goals-oriented meetings. And, just like everyone else, sometimes our goals are changed around or new goals come into play that causes us to drop everything and focus on those instead.
It is great to work with the group of people in our dept. Each of us brings us something different to the table, but we share a common desire to excel in what we provide. We’re still learning and trying and tinkering to improve aspects of the product and service. We very much value the relationships we have developed with all of you and look forward to meeting and hopefully exceeding your expectations in every interaction you have with us.
Here are a list of our updates, you can click on each one for more information.
- Reinstate Authority Deletes
- Deletes that you have sent in used to be final, meaning you wouldn’t see them again even if you had a new bib heading to reinstate them. Well that’s all been fixed now, right in time with what we hoped. You should see reinstated authorities this week.
- Streamline Change Reports
- We still have the bold in place, but now each changed field is highlighted in the background too. Also, there’s another option for displaying specific fields, read more to find out.
- Title (245), First Indicators
- In hindsight, an obvious addition to our BARE rules, about what the first indicator value should be based on the 1XX field. BARE rules? Read the blog to understand more.
- RDA Property in BARE
- You’ve read about our 6 options for RDA, so what does this one mean? This is a simple fix on our side but has far-reaching effects. No matter what direction you decide to go with RDA, we want to make sure you have that option with our processing.
- Russian Ligatures
- Whether you’re a single- or double-half ligature kind of institution, we’ve got you covered! Just let us know what kind you would prefer.
- E-Book Promotion
- No time like the present to send us your e-book collection that you might have been holding off for authority control processing. More details inside the blog post.
When a client sends us their deleted authority record (either in MARC format or by LCCN list), we apply the delete within our system. Our system does not actually physically remove the authority in question, but instead flips a switch / flag on the record, according to the usage(s), and then logs what happened on what date.
We keep a tally of the particular history of each authority because we need to be able to tell our clients when certain actions happened for their authority records. Our Lead Programmer, Chad Cluff, created a program that lets us easily find out all of the changes, additions, deletes, replacements, etc for any authority record.
We can do a search on “Smith, John” and find [n 86851637]. Then when we view its history, we will know that LC added this 670 note on December 1, 2010:
670 $a [Author of The register of death]
Using the same program, we can also look at each client’s authority record history. So we can look at all of the authorities that a client has marked in our system as “delete”. For instance, one of our clients has an entry [n 2001030712]:
100 1 $a Conradie, Jac
Our history shows that this authority was added for this client on January 10, 2007. But then it was deleted on August 3, 2010.
Since we have those logs in place, we were able to quickly write code to ferret out all those authorities from our clients that should have been reinstated due to a newly processed bib heading. We also created a report to go along with those reinstated authorities. And we fixed the area in our system that was causing this in the first place.
Our original hope and intent was to have this fix in place by the end of March. I’m happy to say that this is now in place and we will be sending out the updates later today for those affected. About 1/3 of our clients send us in deletes, so the majority of our clients will not be receiving reinstated authorities to load into the system today. This is considered a retroactive correction, so there is no need on your part to resend bibs that have already been processed in order to receive these reinstated authorities.
Streamline Change Reports
We have made a couple modifications to our Authority Change Reports. In the past, if there was a field that had been updated by LC, we would bold that change. While this helped a little for those going through the reports, it didn’t really stand out as well as we had hoped.
Back in late 2009, we decided to combine two depts within our company: Authority Control and Machine Services. Many of us who had been in the Authority Control dept actually previously worked in Machine Services so it seemed like a natural fit.
As part of Machine Services, we have two other products which some of you may have used over the years: 1) Deduplication, and 2) Machine upgrade. Deduplication is where we take all of your (bib) records and dedupe them according to the settings you put forth. Machine upgrade is where we usually take your brief records and search for better or fuller matches in Library of Congress or WorldCat. Both services have their own very involved profiles to complete, just so we can be sure we have your expectations in place.
Both of these services also have different ways that we report the results. Similar to how Authority Control presents the changed authorities in a side-by-side comparison, the Machine Services reports also does side-by-side comparisons (original vs match).
The difference is in how we highlight what happened between the records. For Machine Services, we color-code specific fields that were matched (hit), verified, retained, etc. For Authority Control, we had just the bold highlighting what changed. Now, we have the entire field background-highlighted in the Authority Control Change Reports. This helps those that comb through the reports immediately have their eye oriented to what changed, rather than fishing through bolded and non-bolded tags.
Another change we have made to the change reports is that we can now have it display specific fields only. Say you are interested in only seeing the 001, 1XX, 4XX, 5XX in the change reports. We can now instruct the system to generate change reports that list only those fields, which greatly reduces the size of these reports. Think of when LC adds in great heaps of 670 notes fields or when you don’t necessarily want to see the 00X fields listed for example.
The highlighting change is already in place. If you would like the change reports to display specific fields instead of what it does currently (per your online profile settings), let your project manager know.
Title (245), First Indicators
This was an easy fix and one we didn’t realize wasn’t already in place. We needed to create a BARE rule to fix the first indicators of the 245 based on the presence / absence of a 1XX field in the bib record.
Let’s back up real quick. BARE rule? BARE stands for BAckstage Rules Engine. It’s what we use to keep track of each client’s individual profile (and other) settings. As part of our rewrite back in 2008, we realized we needed a much better method for keeping track of each client’s profile and settings. We wanted the new method to be very user-friendly on our side so we could turn on or off particular options immediately.
Our older method, before the rewrite, was to create swathes of coding changes which would take weeks to implement. While those were separate (as they are now), it still meant an immense investment of time to get anything remotely considered custom into the client’s profile.
Since then, our BARE rules allow us to tweak options according to each client’s preference on the fly. From the client’s point of view, the only thing that changes is that we can usually easily build into the process whatever the client needs—and we can do so very quickly.
If there is a 100, 110, 111, or 130 in the bib record, it will change the 245 first indicator to ‘1’. Otherwise the 245 first indicator will be ‘0’. As with any rule created in BARE, we can easily turn these off or on, depending on the preference of the client. In this case, this is the default option for all clients.
RDA Property in BARE
If you haven’t read up on the brief history of what BARE is, I suggest looking at the above entry for the Title (245), First Indicators. Now that we have a rudimentary understanding of BARE, this change will make more sense.
As you may know, we currently have 6 options in place for handling your RDA bib records. LC is planning on revealing their direction for RDA towards the end of June, but we wanted to make sure our clients had options in place when it comes to their RDA bib processing. We anticipate that these options will likely need revision depending on LC’s decision this summer.
In the meantime, we have added an RDA record property to our BARE rules. This means that we can create separate or modify existing rules based on AACR2 or RDA. Regardless of what LC decides concerning RDA, we realize that not all of our clients will either move away from RDA or move away from AACR2.
This added property ensures that we can handle clients that choose to process exclusively in AACR2, RDA, or both. Our aim was to give you more options and not take sides in this debate. Our motto continues to be: Whatever you think is best for your library is what we want to help you do with our processing.
Russian Ligatures
Oh this was an interesting one to figure out. Back in September 2010, we wrote a blog post about this issue.
An example of a heading with two half ligatures:
Zhilʹt͡sova, Li͡ubov
An example of the same heading (LC: n 2005008396) with the single ligature:
Zhilʹt͡sova, Li͡ubovʹ
Library of Congress uses the single combining ligature. But OCLC (likely) uses the two separate left- and right-half ligatures. And if it’s not OCLC, some of the libraries that contribute to OCLC use the two separate ligatures.
Originally we had planned on using only what LC delivered to us. So if it came in as two separate ligatures from the client, yet LC’s authority had the single ligature, our system would make that flip based on LC’s version. This was not a good solution.
Eventually we were able to write our coding fix so that all instances of either the single or two half Russian ligatures could be changed to one or the other in both bibs and authorities, depending on the preference of the client.
Regardless of how it comes in or how OCLC / LC handle this, we now have an option in place that will return either the two half ligatures or the single combining ligature. Just let your project manager know which one you prefer and we will have that in place for both your bibs and returned authorities.
E-book Promotion
If you’ve made it this far, we are ending on a good note for all of you! We realize that with acquisitions of e-book collections, it is not always easy to send these off for authority control processing. Due to their size, these e-book collections, if priced at the same point for your current ongoing maintenance, can become prohibitive.
We have a special e-book discount in place based on the volume of e-books you have in your collection that have not yet gone through our authority control processing. Depending on the size of your collection, this may be the best time to take advantage of this offer. If you are interested in more details, please contact your project managers (Jeremy Myntti jmyntti@bslw.com or Judy Archer jarcher@bslw.com).
Tags: Announcements, Authority Control, RDA, UTF-8