1 / 56

Automated Authority Control & the Human Component: How We Do What the Computers Can’t

Automated Authority Control & the Human Component: How We Do What the Computers Can’t. Karla Geerlings Head, Serials & Authorities Unit, MU Libraries. Historically, catalogers were required to verify each and every controlled heading as they cataloged.

tareq
Télécharger la présentation

Automated Authority Control & the Human Component: How We Do What the Computers Can’t

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Automated Authority Control & the Human Component:How We Do What theComputers Can’t Karla Geerlings Head, Serials & Authorities Unit, MU Libraries

  2. Historically, catalogers were required to verify each and every controlled heading as they cataloged.

  3. Authority changes were done directly from the LCSH books …

  4. .. Onto the cards …

  5. … later in the computer …

  6. Heading accuracy & alignment improved through: • Standardization of authority forms • Common cataloging record sources • Global update capabilities • Spell check! • Heading verification • Authority control vendor services • Improvements in authority control programs in the local ILS

  7. Today the authority control process is much more automated through: • ILS (III) Bibliographic control (compares incoming/changed bibliographic record with local authority file) • ILS (III) AACP (Automated Authority Control Process) (compares incoming/changed authority records with local bibliographic records) • Vendor (Backstage/MARS) authority processing

  8. Benefits • More freedom to accept copy cataloging and batch record loads with little or no review • Frees up staff time to address description and analysis, not double-checking headings • Authority control staff receive lists of possible problems and mismatches as identified

  9. Possible Issues • Often flag items which may be perfectly – • Only a match if match is exact • May match an unqualified name with wrong heading • Man hours to review lists • Authority control staff must review access points outside their areas of expertise

  10. What the computer can’t do(but humans can): • Check for unexpected misspellings • Match against bad subfield coding • Choose between conflicting authority records • Match former forms with headings where that exact form is not in a 4XX

  11. Example: Old Form of Name 100 1_ Fishburne, Larry 400 1_ Fishburne, Laurence 400 1_ Fishburne, Lawrence 670 Hallmark hall of fame. Decoration Day [VR] 1990:|bcredits (Larry Fishburne) 670 Higher learning, c1995:|bcontainer (Laurence Fishburne) 670 Internet Movie Database, Feb. 6, 2003|b(b. 30 July 1961 in Augusta, Ga.; sometimes credited as: Laurence Fishburne III, Lawrence Fishburne III; changed his name from Larry to Laurence in his films in 1991)

  12. New Form of NameComputer will NOT change old forms to new form 100 1_ Fishburne, Laurence, ǂd 1961- 400 1_ Fishburne, Larry, ǂd 1961- (was Fishburne, Larry.) 400 1_ Fishburne, Lawrence, ǂd 1961- 670 Hallmark hall of fame. Decoration Day [VR] 1990: ǂb credits (Larry Fishburne) 670 670 Higher learning, c1995: ǂb container (Laurence Fishburne) 670 Internet Movie Database, Feb. 6, 2003 ǂb (b. 30 July 1961 in Augusta, Ga.; sometimes credited as: Laurence Fishburne III, Lawrence Fishburne III; changed his name from Larry to Laurence in his films in 1991) …

  13. Let’s follow a cataloging record through authority control:

  14. Bib record Transaction file Local Authority File Controlled fields checked againstLocal Bibliographic Database

  15. Note: Both new and updated records go through the transaction file and are matched against the local authority file. Changes to older records WILL NOT be sent for vendor processing.

  16. III Headings Reports Generated: • First Time Use -Author, LC Subject, MeSH • Invalid Headings -Author, LC Subject, MeSH, Title • Duplicate OCLC number • Near Match -Author, LC Subject, MeSH, Title

  17. 1. FTU (First Time Use) Bibs with current update dates which contain headings which are were unique within our database when they hit the list. • Authors—Smith, Mary Q. • Subjects—Jargon (Terminology)|vPeriodicals • MeSH—at MU all MeSH headings from reports are sent to MU-HSL for review and processing

  18. 2. Invalid Headings Heading matches authority 4xx field in local authority file • Author—checked carefully • LC Subject—checked carefully, frequently a conflict, so they’re not truly wrong • MeSH—MU sends to MU-HSL to check • Title—largely useless—checks 130, 240, 490 0 830, 730 + 245, 246, 490 1, 505, 730, 740, 970

  19. 3. Duplicate OCLC Numbers Generated by cross-checking 001 and 019 of new or changed records • Duplicate records are merged (by hand), OR • 019/001 is removed from/modified in the brief bib built or OCLC clone record (by hand) • “Duplicate” records appear on the list even if they were immediately resolved.

  20. 4. Near Match Lists bib records that were not updated by the local auth. control as the heading in the bib record did not exactly match a heading or SEE reference (4XX) in an authority record. Possible causes:

  21. Rotational/Cluster Reports The cluster report (called “rotational” report at UM) contains items with multi-site “owners”: • FTU,(first time use) • Invalids • OCLC Duplicates • Near Matches PLUS AACP-generated categories…

  22. AACP (Automated Authority Control Processing) AACP is an automatic process in Millennium which compares new and updated authority records (loaded/ changed locally or through vendor processing) with the local database, making changes when needed. • Includes local authority records

  23. AACP-generated items without “owners” • Blind authority records -Author, MeSH, LC subject, title • Non-unique 4XXs -Author, MeSH, LC subject, title • Updated Bibliographic Records • Duplicate authority records -Author, title, subject • Zzzzzs (unknown locations)

  24. 1. Blind Authorities Authority record heading doesn’t match any bibliographic record heading in MERLIN These are reviewed to deicide: • Is it truly blind? • Is it a heading we need? (Conference Headings tend to be blind by nature) Actions: leave alone (not blind), code for deletion (blind, unneeded), code as intentionally blind (Conference heading, etc.)

  25. 2. Non-Unique 4XXs Indicates there are two authority records with the same see reference (4XX) (in the local authority file), and the computer cannot differentiate for “flipping” existing bibs These are reviewed and corrected, if needed

  26. 3. Updated Bibliographic Records Lists corrections made by the computer during processing (incoming authorities against existing bibs) These are reviewed to be sure the change was appropriate Ex.: IEEE in 4XX in local (3 in OCLC, 1 in local) Incoming record: Instituto Español de Estudios Estratégicos

  27. 4. Duplicate Authorities This happens when someone imports an authority when it already exists in the local authority file We review to find which has the most up-to-date information • If the same, we keep the oldest, • If different, we transfer any local information to the newest record A A

  28. 5. Zzzzzs The bib record has no known location code (rarely happens at UM used to occurred w/record loads) We try to determine who loaded the record and what may have happened If we cannot locate the owner and no records are attached, we delete

  29. Cluster Duplicate Reports Include: • Duplicate Patron IDs • Duplicate OCLC nos. (no clear “owner”) • Duplicate barcodes None of these can be resolved satisfactorily by a computer program; the human error must be untangled by a human

  30. Quarterly Vendor/MARS Reports • Bib and authority records new in local database + authorities coded for deletion are gathered quarterly by MCO • Authorities for deletion are reviewed by authorities personnel • MCO codes BCODE3 in bib records to indicate out for authority processing • MCO sends records to authority vendor for processing

  31. Authority Vendor: • Compares controlled fields in bibs to the national authority file, makes corrections • Notes recent changes to authority records in OCLC on records held locally • “Deletes” coded authority records from their file of our authority holdings • Retrieves and loads authority records needed but not yet present in local database

  32. MCO completes the process: • Loads new authorities into local (cluster) database • Overlays changed authorities • Overlays corrected bibs • Recodes BCODE3 • Sends vendor reports to cluster representative; at UM they are then splits up and distributed using a distribution matrix

  33. Vendor/MARS reports: • Authority Change Reports • Split Headings Reports (LCSH) • Deleted (Cancelled) Authority Records • Partial Match Headings • No Match/Unmatched Headings • Possible Invalid Tags

  34. Backstage/MARS reports (cont.) • Tags Flipped • Partial Match Child Subjects • Partial Match Local Subjects • Unmatched Local Subjects • Suspicious Filing Indicators • Heading Usage Not Authorized

  35. Still More Backstage/MARS (new) • Possible Leading Articles • Unrecognized Z Subfields • Heading Matches Multiple Authorities • Changed Genre/Forms • Unmatched Genre/Forms

  36. 1. Authority Change Reports • Report changes to authority records for: Author, Title, LCSH, Series, Author/Title • Significant changes = changes to 1XX, 4XX and 5XX text • On occasion a new title is ascribed to the author in a 667 and can be taken off an undifferentiated name

  37. Authority Change Reports (cont.) Changes are reviewed and searched in the local database to determine if: • The change was completed to the authority • All changes to applicable bib. record were completed by AACP • There are no floating undifferentiated headings on bibs. in the database which can now be differentiated.

  38. 2. Split Headings Reports LCSH split headings. We have these applied to all bibs. with old heading, but must check for completeness Example: Old 650 0 $aJewels$vCatalogs. New 650 0 $aGems$vCatalogs. New 650 0 $aInsignia$vCatalogs. New 650 0 $aJewelry$vCatalogs. New 650 0 $aPrecious stones$vCatalogs.

  39. 3. Deleted Authority Records We review these to determine: • If the authority record has, indeed been deleted • If there are headings remaining on bibliographic records which may need to be changed • If there is a suggested replacement record, if it’s present in our database and if it has been used appropriately

  40. 4. Partial Match Headings Reports where the ǂa of a Uniform Title, Author or Subject Heading matches an authority record, but the rest does not match an authority. We look for: • Misspellings • Miscoded subfields • Fuller forms • Conference Authorities to be coded intentionally blind This report largely inconsequential

  41. 5. No Match/Unmatched Headings These occur mostly with geographic subjects, names not yet established and name/titles with no matching name/title authority. We look for: • Misspellings • Fuller forms • Proper format • Keyword search hits which might match

  42. 6. Possible Invalid Tags Happens when a heading matches an authority in another index or is coded for a different use: 100 0 $aM. (matches a series authority) We can usually straighten these out, but takes some intuition and knowledge of local practice, especially for series titles.

  43. 7. Tags Flipped Reports MARC tags flipped during processing; we check for appropriateness. Example: • Old 610 10 $aLiberal, Mo. • New 651 0 $aLiberal (Mo.). • Old 61020 $aKansas. • New 6510 $aKansas. … context might say Kansas (Musical Group)

  44. 8. Partial Match Child Subjects Although we are not supposed to receive this report, we do check to be sure something else was not meant. 651 1 $aYukon$vPoetry These are almost always miscoded in the 2nd indicator, and should be LCSH

  45. 9. Partial Match Local Subjects Mostly Canadian local headings (65x _5), which we handle in other ways through LCSH We also review for miscoding here

  46. 10. Unmatched Local Subjects Local subjects with no corresponding Local authority record Again, mostly Canadian (65x _5)

  47. 11. Suspicious Filing Indicators Filing indicators point to an initial article which is not evident to the computer. Example: 740 20 $aWhite dawn is stealing. What was actually meant: 740 02 $aWhite dawn is stealing.

  48. 12. Heading Usage Not Authorized “Headings in this report matched a heading in the authority file, but the usage codes in the authority record indicate that the heading is not appropriate for the use to which it has been applied in the bibliographic record. An example would be when the authority record indicates that the heading is appropriate for use as a main or added entry, but the heading has been used as a series added entry.” Example: 610 10 $aEngland and Wales.$bSovereign (1625-1649 : Charles I)

  49. 13. Possible Leading Articles Flags words which may be initial articles(language-dependent) but which are not coded as such. Correct as needed. Examples: 110 20 $aA & M Telephone Company 246 33 $aA day in the life of Today's Dental 246 3_ $aA la Convention nationale A, An, Los…

  50. 14. Unrecognized Z Subfields Reports headings in subfield z which are unrecognized because: • Heading has no authority record • Subdivision needs a qualifier We look for: • Misspellings • Incorrect use or division • Another form of the heading • Correct formation of heading if not yet established

More Related