1 / 107

ALEPH 500 Versions 17 and 18 Major New Features

ALEPH 500 Versions 17 and 18 Major New Features. Judy Levi Senior Product Analyst. Ex Libris North American 2006 Technical Seminar Knoxville, TN. Session Outline. Authority control enhancements Cross reference sorting Author + Title break Patron Direct Queue Booking Printing

dstacey
Download Presentation

ALEPH 500 Versions 17 and 18 Major New Features

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. ALEPH 500 Versions 17 and 18 Major New Features Judy Levi Senior Product Analyst Ex Libris North American 2006 Technical Seminar Knoxville, TN

  2. Session Outline • Authority control enhancements • Cross reference sorting • Author + Title break • Patron Direct Queue • Booking • Printing • Circulation logger • Inventory control • SDI

  3. Authority Control in V.18

  4. Authority Related Developments in V.18 • Solution for “Conflicting Headings” Problem • The second and third positions of the tag are taken into account to create “groups”, and matching is done only within group • Correction of Field Tag and Indicators • If a BIB field is corrected through cross-reference, the field tag is also corrected • Sorting of Ambiguous Headings • Copy/Break Author + Title heading

  5. What is the “Conflicting Headings” Problem? • Lets start with an example (taken from a presentation given by Sandy Card from Binghamton.

  6. This is a haddock – it’s a fish

  7. This is a spy – Jules Salvador Moch was a spy (we think) and had a code name of Haddock – but he is not a fish!

  8. Until version 18 Aleph did not know the difference between them (Personal subject vs. Topical subject). A library loaded records, started ue_08 – and got:

  9. instead of what they expected to get:

  10. This happened because of the “conflicting headings problem”

  11. Haddock as a Topical Heading, is tagged 150 in the Authority Record

  12. Haddock as a Personal Name Cross Reference, is tagged 400 in the Authority Record

  13. Why did the problem occur? • In the BIB and AUT libraries a new heading is created when the text of the field is unique – the nature of the field is not taken into account. • When BIB and AUT headings are matched, using the “GEN” headings file, the match is on the content of the field – the nature of the field is not taken into account.

  14. What are “Conflicting Headings”? • Conflicting headings are similar to ambiguous headings. In both cases a single heading is linked to more than one Authority record. • Ambiguous headings are headings created from identical non-preferred terms within the same category or family of headings. For example: • A.L.A is a non-preferred term of the following corporate authors: • American Library Association • American Lung Association • Association of Legal Administrators

  15. What are “Conflicting Headings” • ALEPH solves the problem of ambiguous headings by adding the preferred term to the non-preferred term (using fix_doc_aut_duplicate). For example: • A.L.A (American Library Association) • A.L.A (American Lung Association) • A.L.A (Association of Legal Administrators) • In this manner ambiguous headings become unique (until v.18 there was a problem filing such headings…more on this later).

  16. What are “Conflicting Headings” • Conflicting headings are created by identical headings from different heading categories. • While ambiguous headings are legitimate because they are created by the authority records themselves, conflicting headings are not because in principle headings from different categories should never match.

  17. The Haddock Problem • Scenario 1: the AUT library has only “Haddock the spy” (Haddock is 400). • The subject “Haddock” from the BIB matches the personal heading “Haddock” in the AUT “GEN” headings and the AUT record. The BIB record is updated from the AUT record – the record in which “Moch, Jules Salvador” is the preferred heading of Haddock….

  18. The Haddock Problem • Scenario 2: the AUT library (from v.17) uses fix_doc_aut_duplicate, which prevents two AUT records being linked to a single AUT heading • When two AUT records share the same text for 4XX or 1XX, the text of the 1XX is added to the 4XX. 400 |a Haddock becomes 400 |a Haddock |7 Moch, Jules Salvador 1893

  19. The Haddock Problem • fix_doc_aut_duplicate prevents incorrect flipping if there are multiple AUT records with the same x-ref (e.g. A.L.A.) • But fix_doc_aut_duplicate does not solve the problem of mismatch subject and name. • The categories mechanism solves this problem.

  20. The “Categories Mechanism” • Version 18 introduces the “categories mechanism” to solve the problem of conflicting headings. • The categories mechanism takes the category of the heading into account. It does this by using the last two positions of the tag.

  21. How does the tag relate to the category? • 100 field = authorized personal name heading • 150 field = authorized topical subject heading • 400 field = “see from” personal name (meaning don’t use this form, use the 100 form) • 450 field = “see from” topical subject heading (again meaning don’t use this form, use the 150 form)

  22. How does the tag relate to the category? • 1st digit tells you whether the term you have is currently used or not. • 1XX represents the authorized (currently used) version of a heading • 4 XX represents an unused version of the heading • While the other 2 digits represent the type of heading you are dealing with: • X 00 = a personal name • X 50 = a topical subject heading

  23. Bibliographic Record Tags • In most cases (but not all – more on this later) the last two digits of the tag in the bibliographic record matches the last two digits of the tag in the authority record: • 00 = personal name • 10 = corporate author • 11 = meeting • 50 = topical subject • 51 = geographic subject

  24. The Categories Mechanism • The “Category Mechanism” is not mandatory, but it is recommended, especially if your records adhere to MARC21 cataloging standards. • A new field – Z01-CATEGORY – has been added to the headings record. It is part of the record key, and is used to differentiate two headings that have the same text.

  25. The Categories Mechanism • The Z01-CATEGORY field is three characters in length. The first two characters are the second and third positions of the AUT or BIB field tag. The third position is not in use – it may be used in future to enable an additional level of categorization (e.g. subject headings for children’s literature) • If the categories mechanism is not used – the content of the field is ZZZ.

  26. The Categories Mechanism: COR field • When a heading field in the authority library is updated, the system generates a “COR” field. This field contains the original term. • The COR field needs to contain the category of the original field. This is now added in $0. For example: • COR $a Trees INC. $0 01 • If the categories mechanism is not used the $0 will contain ZZZ.

  27. How does this work? AUT Library Haddock - 00 100 $a Moch, Jules Salvador 400 $A Haddock Haddock - 50 150 $a Haddock BIB Library Haddock - 50 650 $aHaddock $xHabitat BIB

  28. Categories Mechanism Setup • A new table – tab_acc_category – has been added to the BIB and AUT tab directory. The table has two columns: • Tag • Indication whether the mechanism used: • 0 – not used • 1 – used • 2 – for future use

  29. AUT library: 100## 1 110## 1 111## 1 148## 1 130## 0 150## 1 151## 1 155## 1 400## 1 410## 1 411## 1 430## 1 450## 1 451## 1 455## 1 BIB library: 100## 1 110## 1 111## 1 130## 0 240## 0 245## 1 246## 1 247## 1 440## 0 600## 1 610## 1 611## 1 630## 1 648## 1 650## 1 651## 1 655## 1 Recommended Setup: • 700##1 • 710##1 • 711##1 • 730## 0 • 740## 1 • 800## 1 • 810## 1 • 811## 1 • 830## 0

  30. Explanation of the Setup • As noted, in MARC the bibliographic and authority tags do not always match. The categories mechanism will prevent mismatches but will not always enable a match. • Title tags do not match – 130 in the AUT and 130, 240, 440, 730 and 830 in the BIB. The solution was to avoid adding the category for these fields – since other fields will have the category, mismatches should not occur while a 240 in the BIB can match a 130 in the AUT.

  31. Explanation of the Setup • Note that uncontrolled titles – 245, 246, 247 and 740 have been defined to include the category. • This was defined in order to prevent a match with identical titles – and possible authority control of these titles – from the authority database. These uncontrolled titles should not be updated from the authority records.

  32. Explanation of the Setup • While the setup above enables matches between varying title tags, it does not provide a solution for possible geographic names, where a 151 authority field can match the bibliographic 110 and 710 fields (“51” will not match “10”).

  33. Implementation of Categories Mechanism • Implementation will require re-building of the headings in the AUT and BIB libraries and then re-creating the links between the AUT and BIB libraries. • Run: • P_manage_02 in all AUT libraries • P_manage_102 in BIB for all AUT libraries (first time with delete=Y) • P_manage_02 in BIB

  34. Correction of Tag and Indicators • Authority control has been enhanced in version 18 so that when a bibliographic record field is updated, in addition to updating the content of the field the system will also correct the field tag and indicators if they are different than those of the authority record.

  35. Example: For example: Authority record: Original bibliographic record: Corrected bibliographic record:

  36. Sorting of Ambiguous Headings • Ambiguous headingsare non-unique or undifferentiated 4XX headings (same 4XX for different 1XX). • ALEPH solves ambiguous headings by adding the preferred term (1XX) to the non-preferred term (4XX). This can be done automatically using the fix_doc_aut_duplicate program. For example: • 410 2 $$aALA $$7African Literature Association • Such headings were not sorted correctly in the headings list.

  37. Sorting of Ambiguous Headings • For example: • 410 2 $$aALA $$7African Literature Association • 410 2 $$aALA $$7American Library Association • 110 2 $$aALA Auto & Travel Club. • 410 2 $$aALA $$7Stiftelsen Anpassning till liv och arbete

  38. New Filing routine: add_prefix_hash • This routine adds a hash (#) sign to the subfield specified in the parameters column of the tab_filing table. The hash (#) sign is added immediately after the subfield code. For example: • $$a [original heading]$$7#[text of added by fix_doc_aut_duplicate].

  39. Correct sorting: • For example: • 410 2 $$aALA $$7#African Literature Association • 410 2 $$aALA $$7#American Library Association • 410 2 $$aALA $$7#Stiftelsen Anpassning till liv och arbete • 110 2 $$aALA Auto & Travel Club. • Note that the addition of the hash sign is only for filing purposes, both the record and the display of the heading are not altered

  40. Implementation • Add the process to the filing routine in tab_filing: 01 N add_prefix_hash 7 • Re-sort headings – run p_manage_16 and p_manage_17

  41. Copy and Break “Author + Title” heading • fix_doc_1xx_240 and fix_doc_1xx_243 • subfield t and all subsequent subfields are copied from field 1XX, to field 240 or 243 .The $$t subfield is copied to $$a subfield in the new tag 240/243, all subsequent subfields are copied as they are, and deleted from the original 1XX field. • AUT • 100 10 $$a Shakespeare, William, $$d 1564-1616. $$t King Richard II • BIB • 100 10 $$a Shakespeare, William, $$d 1564-1616. • 240 10 $$aKing Richard II

  42. Patron Direct Queue

  43. Functionality Objectives • To allow patrons to loan and return in any library, without having to register in each library. • To allow patrons to request any pickup location, regardless of which library fulfills the request. • To consider the pool of all copies of all libraries when fulfilling a patron’s request. • To manage the potential suppliers according to a pre-defined roster. • To enable reporting cross library activity. Note that this functionality is applicable in Multi- or Single ADM sites.

  44. Requirements • Single or Multi-ADM environment, sharing a single library catalog, which is either Union View, or shared Bibliographic records. • Cross-institution agreements on patron statuses that are used in common. • For Multi-ADM: • Participating libraries define their patrons as shared. • Patron ID is unique across the participating institutions. • Barcodes are unique across all participating libraries.

  45. GUI Limitations in Multi-ADM • Circulation GUI is limited to loan (check out) and return (check in) actions for items that belong to a different ADM library. • The items cannot be renewed, recalled, declared lost or claimed returned, nor can their information be displayed. These actions are possible only at the owning institution.

  46. “ALEPH” Local Patron record • The “ALEPH” Z305 Local Patron Record was originally intended as the “default” record for patrons that do not have a Local Patron record that matches the item record. • The “ALEPH” Z305 record is relevant (and present) only in Multi-ADM environments. It is located in the usr_library environment, where it is shared by all ADM libraries.

  47. “ALEPH” Local Patron record • tab31 (col. 22) determines whether or not to generate an ALEPH record. • tab_map_privileges defines the patron status that is assigned in the patron’s ALEPH record (per sublibrary + status).

  48. “ALEPH” Local Patron record - Conversion Upgrade processes handles the change: • Convert existing Z305 records. • If patron has both ADM and "ALEPH“ Local Records, the "ALEPH" record is deleted. • If patron has "ALEPH" Local Record, and no ADM Local Record, it will be changed from "ALEPH" to ADM (e.g. change "ALEPH" to "USM50"). • Update cols. 9, 10, 11 in tab_sub_library table • If cols 9, 10, 11 contain both "ALEPH" and ADM library code, delete "ALEPH". • If cols 9, 10, 11 contain "ALEPH" but not the ADM code, replace "ALEPH" with ADM code.

  49. “ALEPH” Local Patron record - Conversion • Multi-ADM PDQ requires • Manually setting up tab31 col. 22 flag • Manually setting up tab_map_privileges and the tab_sub_library hierarchy. • Running a utility that will create required ALEPH patron records.

More Related