Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Scope: This page outlines the authority control process for DUL, including separate pages for extract and loading documentation.
Contact: Jacquie Samples
Unit: Metadata & Discovery Strategy Department
Date last reviewed: 4/16/2020
Date of next review: 4/16/2021

Although we have several technical services teams across Duke University (DUL, Rubenstein, Ford Business Library, Medical Center Library, and Goodson Law Library) administration of the authority service management is done centrally, in the DUL Technical Services Division.  Functional owner for the authority services is Rich Murray; Technical owner for the authority service is Jacquie Samples.

History
The Technical Services staff members who create original bibliographic descriptions utilize the Connexion client and control headings there rather than working in our ILS, Aleph.  While the Aleph system does have an authority module, Duke’s authority control was outsourced to the company, LTI at least by 2004 when Aleph was implemented.

In 2018, a review of LTI’s service came under scrutiny at Duke due to changes in staffing and retirements. As we began to investigate other authority services, LTI coincidentally announced that they were going out of business in 2019.   After a thorough analysis of alternate services, Duke decided to implement MARCIVE’s offering. 

In January 2019, we decided to use MARCIVE’s services to embed $0 data from several thesauri, and to update pre-RDA records to hybrid records by adding the 33X fields to records without those data.

Process timeline

  1. A copy of our bibliographic database is saved at MARCIVE, called the basefile.

  2. Files of updates are sent to MARCIVE weekly (OAS file),
    1. Extracts are run Thursday nights; file should be sent to MARCIVE on Friday mornings.
    2. File is located on L:\Departments\Aleph\authority_control
    3. File name = auth_wkly_ext_yyyymmdd.mrc
    4. Open with MarcEdit to retrieve number of records (the count is emailed to MARCIVE along with notification of file posting).
    5. Change file name to DUKU[MMDD]BIB.mrc
    6. Open a second File Explorer window, and enter MARCIVE URL (ftp://ftp.marcive.com)
    7. Copy the OAS file into the input/athority folder.
    8. Send a notification email to production@marcive.com with the file name and the record count.

  3. For the parameters of the weekly OAS extract, see Criteria for ACVS Bibliographic Extracts

  4. Weekly, Load ACVS-Processed Bibliographic Records (see Loading ACVS-Processed Bibliographic Records)

  5. Quarterly, the comprehensive notification service (CNS) requires that a list of deleted record numbers is sent to MARCIVE
    1. Extract a list of record numbers deleted since the last CNS
    2. Load records as for OAS process
    3. The CNS process includes a report of new authority headings.

  6. Annually, update the basefile at MARCIVE by sending a new complete extract from Aleph.
    1. Exclude selected records: 
      • Exclude if Tag is STA and Field is (SUPPRESSED, DELETED, CRASH, or CIRC-CREATED)
      • Exclude if Tag is DEL
      • Exclude if Tag is (245, 590 or 500) and Field is TEMPORARY RECORD
      • Exclude if Tag is 904 AND Field is:
        • Serials Solutions supplemental brief
        • Serials Solutions original
        • Bowker Global Books in Print
        • Vendor-generated brief
        • Temporary record
    2. Load updated bibliographic records
    3. Load new and updated authority records (for terms used in Duke bibliographic records)
    4. In addition to updated bibliographic and authority records, the annual basefile replacement process produces several reports
      1. Changed Headings, which shows both the old and new forms of the terms (X00, X10, X11, 240/X30, 490, 800,811,830, 650, 651, split terms, and modified Genre/Form)
      2. Multiple Matches or High Probability Matches (these have not been updated automatically)
      3. Unrecognized or Invalid Terms (this report is also split by the categories list for the changed headings report)
      4. Undifferentiated Terms (this report shows terms that matched to an undifferentiated record during authorities processing)
      5. Pre-processing Changes (this report shows data modifications that occur prior to authorities processing, not including changes to the leader, 040, or 9XX fields. Types of changes include subfield code fixes, addition of 33X and 34X data, punctuation error fixes, etc.)
      6. Statistical summary of records processed, actions taken, and/or reports generated


  • No labels