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:

10. instead of what they expected to get:

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

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

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

14. 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.

15. 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

16. 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).

17. 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.

18. 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….

19. 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

20. 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.

21. 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.

22. 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)

23. 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

24. 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

25. 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.

26. 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.

27. 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.

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

29. 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

30. Recommended Setup: AUT library: BIB library: 100## 1 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
700## 1
710## 1
711## 1
730## 0
740## 1
800## 1
810## 1
811## 1
830## 0

31. 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.

32. 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.

33. 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”).

34. 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

35. 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.

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

37. Sorting of Ambiguous Headings
Ambiguous headings are 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:
$$aALA $$7African Literature Association
Such headings were not sorted correctly in the headings list.

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

39. 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].

40. Correct sorting: For example:
$$aALA $$7#African Literature Association
$$aALA $$7#American Library Association
$$aALA $$7#Stiftelsen Anpassning till liv och arbete
$$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

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

42. 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
$$a Shakespeare, William, $$d $$t King Richard II
BIB
$$a Shakespeare, William, $$d
$$aKing Richard II

43. Patron Direct Queue

44. 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.

45. 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.

46. 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.

47. “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.

48. “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).

49. “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.

50. “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.

51. ALEPH and ADM Patron records - Summary
When a new patron registration occurs:
A local Z305 record is created in the ADM library.
An ADM level Z305 record is created in the ADM library.
An “ALEPH” Z305 record might be created in the usr_library, depending on tab31 policy.

52. Loan and Return Anywhere Multi-ADM
The general ALEPH record will be used whenever the patron is active in an institution in which he is not explicitly registered.
Since the ALEPH statuses are agreed on, each institution can use its configuration tables (tab16) to enforce local policies regarding loan and request privileges for ‘external’ patrons.

53. The Title Request – Patron and OPAC
“Request” button on FULL record display; if the title has items of more than a single material type, or differing enumeration/chronology, a list displays for the patron to choose from.
The Request Form
displays libraries that have available copies
displays list of possible pickup locations, filtered to include relevant locations only

54. The Title Request – Pickup Locations
The default pickup location (first location in the list) is
patron dispatch library; if blank then,
patron home library; if blank then,
item sublibrary or first library in tab37
If there is only a single possible pickup location, naturally it is the default.

55. The Title Request – Patron and OPAC
A global limit of active title requests is set on the patron’s Global Record.
The patron views his title requests in the Web OPAC “My Library Card.”
The title requests are displayed on a separate line, below the patron activity table, similar to ILL requests display.

56. The Title Request – The Roster
tab_roster sets which libraries are potential suppliers for each pickup location.
The potential suppliers are arranged in groups, each with an internal order that is either pre-set or random.

57. The Title Request – The Request Records
The Title Request creates a queue (Z370), using representative items, one per Supplier.
A hold request (Z37) is placed on the single potential supplier that is currently active.

58. The Title Request – The Roster Batch
A batch process moves the active request (Z37) to the next stop in the roster (Z370). The batch’s duty is:
Determine whether the request should be moved on.
Determine who the next potential supplier is.
The next potential supplier will be:
The next potential supplier in the roster that has an available item, or,
If no available item is found, the next potential supplier, regardless of item availability.

59. The Title Request – Pickup Locations
The patron’s selection of a pickup location might narrow the list of potential suppliers for the request.
Title
Pickup Locations : A B C D E
ADM Record
Item
Item
Item
Item
Item
Item
Item
Item

60. The Title Request – Pickup Locations
Each institution can define (by item status) which of its items can be transferred to pickup locations that are outside the institution.
Each institution can define which patron statuses can request a pickup location that is outside the institution.

61. The Title Request – Pickup Locations
Each institution can define which of its sublibraries may serve as pickup locations for items of other institutions.
Each institution can define paging rules – i.e. sublibraries which will not be allowed pickup locations if there is a loanable on-the-shelf item in the sublibrary.

62. The Title Request – Life Cycle
OPAC
Request is placed
Request Management
Owning Inst. Fulfillment
GUI
Roster
Patron
CIRC policy
Pickup Inst. Fulfillment
Return to Owning Library
Patron Return
Patron Loan

63. The Title Request – Owning Inst. Fulfillment
If the request if fulfilled (item is returned or call slip was printed for an available item) and the pickup location is not the owning library, then the item will be placed ‘In Transit’ to the pickup location.
A configurable option enables notifying the patron at this stage.

64. The Title Request – Pickup Inst. Fulfillment
When the item arrives at the pickup location:
The ‘In Transit’ status is cancelled.
The item is put ‘On Hold’.
A configurable option enables notifying the patron at this stage.

65. The Title Request – Patron Loan
When the patron checks out the item, and the checkout is not at the owning institution:
Staff must have ‘Cross Institution’ privileges.
The ‘On Hold’ status is cancelled.
The loan procedures (loan checks, due date, cash transactions, patron local privileges) are performed at the owning institution, using the owning institution’s values.
The Loan Session will be updated with the item’s and the loan’s values, but will not include the option to change the due date.
Loan Receipt will be printed (subject to station configuration).

66. The Title Request – Patron Return
When the check-in is not performed at the owning institution:
The performing staff must have special ‘Cross Inst.’ privileges.
The patron is discharged
The item is put ‘In Transit’

67. The Title Request – Staff Management
The CIRC GUI Patron tree has a ‘Title Request’ node.
Staff members in all of the institutions that manage the patron are able to :
Delete the title request (notifying the patron).
Change the request’s expiry date.

68. The Title Request – Staff Management
The Item tree lists the requests that are currently active for a library of the institution.
Request fields can be updated, but apart from the expiry date, changes are relevant only for the current supplying institution.
Deletion of the request at the active institution will cause deletion of the title request, subject to staff approval.

69. The Title Request – Staff Management
Call slips printing (cir-12 and ue_06) is handled in the active institution.
Expired request deletion (cir-17) is handled in the active institution. The title request will also be deleted.
Item recall (cir-13) is activated only in the active institution.

70. Reports
Title Request Report (cir-81) reports how many requests were handled by partners.
How many times the library fulfilled requests of patrons from other libraries (based on home library); based on the ‘Other Inst. Fulfillment’ event.
How many times a library served as a pickup location for items of other libraries; based on the ‘Pickup for Another Inst.’ event.
How many times the library’s items were transferred to another library.

71. Reports
Institute Time Report (cir-82) reports the average time duration for different stages in the fulfillment of the title request.
How long (average) it took for an institution’s patrons’ requests to be fulfilled, from the time the request was placed.
How long (average) it took for a fulfilling institution to put the item on the hold shelf or send it to the pickup location.
How long (average) it took for a pickup location to loan the item after it arrived at the pickup location.

72. Booking

73. What is Item Booking ?
A booking request is a request on a specific item for a specific patron at a specific time.
Booking requests differ from standard ALEPH hold requests in two ways:
Booking requests have specific start and end dates.
Booking requests have priority over all other requests.
Booking is suitable for “Reserves” and for “Equipment”.

74. Item Booking Concepts
Effective request time span is made up of three parts:
Request can be fulfilled by any “like” item.
Request can not be longer than the loan period.
Delivery Time
Head Time
Request Time
Tail Time
Delivery Time

75. Item Booking Concepts Requested item must be available, meaning:
Not on loan
Not on hold shelf
Not booked by other patrons
Not being reshelved
Preview Time
Release Time
Re-allocate

76. OPAC Booking Request
Booking on Full view
Booking on Items view

77. OPAC Booking Request
Booking on free form

78. OPAC Booking Request
Booking on pre-set schedule

79. GUI Booking Request
Booking on pre-set schedule

80. OPAC Booking Request
Patron’s booking requests

81. GUI Booking Request
Patron’s booking requests

82. Handling – Staff Workflow
Fetch the requested material
Services : cir-12 (ue_06)
CIRC GUI: Administration tab
Deliver a requested item
Loan a requested item

83. Handling – Staff Workflow
CIRC GUI: Administration tab
Filter list by locations, dates, patron, start time, end time, …

84. Handling – Staff Workflow
CIRC GUI: Administration tab
F11 – Print

85. Booking Request handling in the Circulation Module
Loan tab
Shortening a loan
Merging and extending a loan
Renewals
Slot restricted advance bookings
Risk Analysis Report

86. Booking Configuration
Local Patron (tab31) – booking permission; release period ignored (item always held)
tab15 – re-loaning / re-booking time wait; booking for closed / open / both
tab16 – limit of number of bookings
tab100 – like items
tab_hold_request – BK section
tab_booking – times for head, tail, release, patron delete, how far into future

87. Booking Configuration
tab37_booking_delivery – non-library locations for delivery/pickup (per item location, item status, patron status)
tab37_booking_pickup – sublibrary locations for delivery/pickup
tab27 – loan to patron, or to pickup location
tab18 – booking charges
tab43 – advance booking slots

88. Booking Services Call slips – cir-12 Reminders – cir-33
Risk analysis – cir-35
Report/Delete expired – cir-34

89. Printing

90. PC Client Printing Control
Optional in v16 and v17, default in v18
Printing now runs under third party software, instead of directly under MS Windows.
The software has been added to the PC client. It is placed under \alephcom\bin, and is called HtmlPrint.
This software was added in order to solve problems of re-direction for printing. However, it also provides some additional features, such as the ability to set margins, and to add header and/or footer.
Some entries in the configuration file should NOT be changed, such as a registration number and settings which are automatically updated when you configure your client.

91. PC Client Printing Control

92. PC Client Printing Control

93. Circulation Logger

94. Circulation Logger
The objective of this functionality is to achieve patron oriented tracking of circulation actions such as loans, renewals, recalls and cash transactions.
The logger gives the staff user concentrated information on patron circulation activities, to enable providing better service to the patron, and information when handling disputes.

95. Circulation Logger Configuration
ADM table (tab_circ_log.eng) defines which actions create a log entry, whether system-generated or manual, and the name of the action
00 Y Y LLog loan note
01 Y N LRegular loan
09 Y N LSelf check loan
02 Y N LOffline circulation loan
Display can be filtered by action

96. Log Display

97. Log clean-up
Circulation Logger Clean Up (cir-78) – deletes log entries when -
The transaction type fits the input parameter (cash or loan)
The action date is not later than the input parameter
The transaction is closed (returned or paid)
Patron Scrubbing and deleting removes log records

98. Inventory – Shelf Reading

99. Inventory Step 1: define the range – item-01
boundaries of the inventory range are defined; items can be included/excluded depending on sublibrary, collection, item status, item processing status, material type
Step 2: input barcode of items on shelf – online or item-08
Barcode of the shelved item is input using GUI Items client; immediate warning for mistakenly shelved and lost-but-now-found items; or
File of barcodes is submitted batch (item-08); optional update to “no longer lost”.

100. Inventory

101. Inventory Step 3: reports – item-09
Creates file of barcodes for items that were not found and not accounted for (can be used to delete items from the database)
Creates report (author, title, call number, etc.) of unaccounted-for items
optional update process status to lost
Step 4 (optional): reports – item-10
Output of item-01; i.e. the shelf range
Step 5 (optional): delete items – item-11
First, change barcode to item key using manage-70

102. SDI

103. Enhanced SDI Functionality
SDI is now based on an “SDI ready” mechanism, that builds or does not build an SDI record. This mechanism allows :
Sending SDI notification only when an item has no item process status, i.e. is available for the patron.
Allowing patron to define his SDI profile for a specific campus/sublibrary.

104. SDI Ready – Technical aspects
Configuration
/xxx50/tab/tab_z105
UPDATE-SDI USM01
Z324
stored in the BIB library
Processes running
xxx01: ue-01
usr_lib: ue-11
Record creation depends on:
Item process status check (must be blank)
Sublibrary/location check (must be new)
Enumeration check (must be new)

105. SDI Ready – Technical aspects
First-time record is created for
ALL
ADM library
Sublibrary
Each sublibrary triggers additional records, and possibly an ADM library record
A record is not created/deleted when
Item is moved from one sublibrary to another
Item without item process status is assigned one

106. SDI Profile – New Options
Additional fields in profile (Z325):
Patron can set an expiry date for his profile.
Alternative address.
Patron can define request to receive (or not receive) SDI search that retrieves zero results.
Patron can suspend SDI searches for a certain period (for example, vacations).
Additional options for profile:
Patron can select the character set encoding of the SDI results list.
Patron can receive SDI as an RSS alert [v18].

107. Enhanced SDI Functionality