For those of you who utilize URI Enrichment services, we now have another set of fields that will benefit: 34X.
The 34X URIs come from the RDA registry and will be maintained in various list sets within our processing. Since these are maintained by lists instead of authority records, there are separate rules that your Project Manager will need to turn on in order to incorporate this addition. Please let her know if you'd like to add the 34X URIs.
Because previous practice for 34X has been to include a generic $2 rda and has allowed for multiple subfields to be in a single 34x field, our URI processing will split pre-existing 34X into a single term/subfield per field based on specific term lists, add the URI, and will then change $2 rda to the appropriate code.
Example:
Before:
344 __ ▼adigital▼boptical▼gsurround▼hDolby Digital 5.1▼2rda
344 __ ▼adigital▼boptical▼gsurround▼hDolby Digital 2.0▼2rda
345 __ ▼awidescreen (2.40:1)▼b24 fps▼2rda
346 __ ▼bNTSC▼2rda
347 __ ▼avideo file▼bDVD video▼eRegion 1▼2rda
After:
340 __ ▼b4 3/4 in.▼2rda
344 __ ▼hDolby Digital 5.1▼2rda
344 __ ▼hDolby Digital 2.0▼2rda
344 __ ▼adigital▼2rdatr▼0http://rdaregistry.info/termList/typeRec/1002
344 __ ▼boptical▼2rdarm▼0http://rdaregistry.info/termList/recMedium/1001
344 __ ▼gsurround▼2rdacpc▼0http://rdaregistry.info/termList/configPlayback/1004
345 __ ▼awidescreen (2.40:1)▼b24 fps▼2rda
346 __ ▼bNTSC▼2rdabs▼0http://rdaregistry.info/termList/broadcastStand/1002
347 __ ▼bDVD video▼2rda
347 __ ▼avideo file▼2rdaft▼0http://rdaregistry.info/termList/fileType/1006
347 __ ▼eRegion 1▼2rdare▼0http://rdaregistry.info/termList/RDARegionalEncoding/1002
NOTE: Any term that does not currently fit an RDA Registry vocabulary will not receive a $0 nor will the $2 be corrected. As terms & URIs are added, we’ll update our lists accordingly
Just as a reminder, the following fields are currently available for URI enrichment:
* 043
* 050
* 33X
* 34X
* Access points
Do let us know if you have any questions!
Ms. Casey Cheney, PMP | Vice President, Automation Services
Backstage Library Works | Provo, Utah & Bethlehem, Pennsylvania
Phone: 801.356.1852 x692 | Fax: 801.356.8220 | ccheney(a)bslw.com<mailto:ccheney@bslw.com> | www.bslw.com<http://www.bslw.com/>
How am I doing?<http://ac.bslw.com/customer_satisfaction/review.php?email=ccheney@bslw.com&…>
I have many exciting announcements for you today so I apologize in advance for the length of this post. I've tried to separate them into the following categories so you can easily navigate yourself to what is of most interest to you.
1. Spanish Subject vocabularies
2. Split heading limitations
3. Illegal aliens & Indigenous peoples
4. Series updates
* Series-like phrases
* $v options
* $s change
* Publication matching
______________________________________________________________________________________________________
1. Spanish Subject vocabularies: We have now added Queen's Library Spanish language subject headings (qlsp) and the Biblioteca Nacional de España (embne) vocabularies as options to our Subject Matching. If you would like to match either vocabulary, please let your Project Manager know.
There have been questions in the past regarding BILINDEX subject matching. Unfortunately, at this time we do not have the ability to match against BILINDEX as it is not available in MARC or in a dataset that we can easily convert.
2. Split Headings: AC profile 3-4 currently will split any heading as directed by the authority record. We have added a new option where you can dictate which 6XX fields you would like to limit this to. If you decide to limit which fields this rule runs on, any fields that would have previously been split that we are now omitting will now appear on the R17 Split Headings - Headings Left Unchanged report. Any split headings that do change will still appear on the R31 Split Headings report. For instance, if you determine to only allow 650 fields to split, any 600, 611, 610, 651 that would have previously been split will be left alone and appear on R17. Only the 650 will appear on R31 as its splits are made
3. Illegal aliens & Indigenous peoples: For the last few years there has been much conversation about how to handle certain terminology within the LC Authority file that cannot be changed by LC at this time, most specifically subject headings related to Illegal aliens. Our clients are approaching these terms in various different ways. Some are using local authority records to change existing headings while some are just adding their preferred term to a local subject heading (69X or 65X _4) themselves, others are having us change terms based on a finite list. Whatever your preferred process, we can certainly help you make these changes so please do reach out to discuss your options.
In a related vein, there are institutions that are also thinking about changing some terms for various Indigenous peoples to something more acceptable. If you have been working with a list of terms that you'd like to change in your subject fields, let us know and we can incorporate that into your existing processing!
The question has arisen why we don't have an overall policy for handling these types of terms. The simple answer is that each of our institutions is going to vary a little differently for their desired approach and desired terms. We don't want to offer a rigid service, we prefer to cater to your specific needs!
4. Series updates: We've undertaken a number of updates to our series matching processing that we hope will be of benefit to you!
* Series-like phrases: There are a number of Series authority records in the LC file that state that the heading should be a Quoted Note instead of a typical series statement. Up until now, the only option was to keep these statements in the 490 field. However, you now have a new option to have these statements moved to a quoted 500 note. If this new option is turned on the original 490 (and paired 8XX) will be removed, the quoted 500 field will be added, and the authority record will be added to your authmaster as normal.
Because we like options, you have a couple other options available if you elect to have the quoted note added. You may opt to retain the original 4xx/8xx while still adding the quoted 500 note. You may also opt to OMIT the authority record from your authority file.
* $v options: When an authority record determines that a series should be traced in a paired 8XX field, our system defaults to copying the $v from the 490. However, you now have the option to omit the $v if the authority record does not contain a 642 field. The 490 will retain the $v but the derived 8XX will omit the $v.
* $s change: There have been a few instances in which someone has noticed that a series matched a 4XX of an authorized series of a different format. After some exploration of the different format types that generally appear in the $s, we have adjusted our default matching process to search for specific terms in the $s and then check the "Type of Record" to determine if that series should be added. For example, if a series in a bib record does not contain a $s but matches a 4XX in an authority record that has a 1XX $s Spoken word, the series will not match/change unless the bibliographic record is also coded as a Spoken word record.
* Publication matching: This is probably one of the more significant changes to speak of today. In order to improve our matching capabilities for Series titles, we've now incorporated a validation check of publishers within the bib record as well as the authority record. So, let's look at how this changes your existing processing ...
One major area you'll see this coming into play is when we have 2 identical series titles. We now use the Publisher from the Bib and the Authority to make the determination as to which Authority record is the correct one. Previously, this series title would appear on the R10 Heading Matches Multiple Authority Records report. Now, when we can, we will break the tie and accept the correct authority record.
You may be asking yourself, well, what about the vast majority of series that match just a single authority record? Will I be seeing fewer matches because publishers don't match? Well, this is up to you! By default, we will continue accepting matches where the publisher does not match, because we do know that sometimes publishers change. However, you now have the option to reject authority records where the publisher does not match and accept only those that do match. Please let your Project Manager know if you would like to accept only those with matching publishers. *NOTE: if your bib record is missing a publisher, the system will accept the authority record it finds.
To make this improved matching work as best we can we've taken a few things into consideration. First, sometimes publishers don't use their full names and use only a single word; we've included a protocol to catch some of these these. Second, many publishers vary with whether they are using words such as "Inc", Pub", "Books", "Press"; we are removing these terms from the matching parameters. Third, we normalize "&" and "Dept" to catch forms of publisher that may use "and" or "Department".
It must be said, however, that sometimes the publishers vary too much in the way that they're transcribed that we cannot determine from an automatic algorithm if the publisher is indeed the same. So, if you choose to only accept authority records where publisher must match, there may be some that are considered non-matches but with manual review could be identified as matches. They will appear on the R07 Unmatched Primary Headings Report and may also appear on the R00 Near Match Headings report depending on how close they are to matching.
This is a lot to digest! Please feel free to reach out with any questions or clarification needs! I will be updating the Wiki this week, so please be patient as I'm getting these changes incorporated.
Ms. Casey Cheney, PMP | Vice President, Automation Services
Backstage Library Works | Provo, Utah & Bethlehem, Pennsylvania
Phone: 801.356.1852 x692 | Fax: 801.356.8220 | ccheney(a)bslw.com<mailto:ccheney@bslw.com> | www.bslw.com<http://www.bslw.com/>
How am I doing?<http://ac.bslw.com/customer_satisfaction/review.php?email=ccheney@bslw.com&…>
Policy Updates
Hello everyone!
We hope you've had a wonderful holiday season! As we are getting back to the "norm" I wanted to announce an update to our URI Enrichment process.
On September 12, 2019 a final report from the "PCC Task Group on Linked Data Best Practices" was submitted to the PCC Policy Committee. The best practice recommendations only change how we have been adding URIs to our 1XX/240 fields (if both appear in the Bibliographic record).
Until now, our policy was to add the URI for the full name/title match to the 1XX field, leaving the 240 with no URI. Based on the Best Practices document and requests from multiple clients this fall, we have altered our policy: the 240 will now receive the URI for the full name/title match and the 1XX field will receive the URI for the full name match.
As with all our processing rules, there are options available for you:
1. You may opt to have ONLY the name URI added to the 1XX and not have a URI added to the 240 at all.
2. You may opt to follow our old policy and have the full name/title match URI added to the 1XX only.
As of today, the new policy is live in the system, so if you'd like to revert back to the old policy (option number 2 above), please reach out to your Project Manager so she can make the change.
Casey Cheney, PMP | Vice President, Authority Control
Backstage Library works | Provo, Utah & Bethlehem, Pennsylvania
801-342-5692 | ccheney(a)bslw.com<mailto:ccheney@bslw.com> | ac.bslw.com/mars<http://ac.bslw.com/mars> | How am I doing?<http://ac.bslw.com/customer_satisfaction/review.php?token=338>
