Steering Ctte Links
ILS Implementation Decisions
NOTE: The Implementation Team made an effort to document decisions made along the way so as to be able to provide future custodians of the catalog information about the intent behind our configuration decisions, to inform their evaluation of future adjustments. Despite our best efforts, some of the record keeping on decisions made has been retrospective. In addition, those deeply involved with the project sometimes lacked perspective about what to document. As a result, we are aware that some important decisions are probably missing from this document. We can try to remedy this as they are pointed out to us - email ils_steering@lists if you see a decision not listed here that may be of use to the ILS Steering Committee or to the Library at large in the future. Posted 7/23/10
OPAC - OskiCat
Why? Allow for rapid implementation and support revisions based on use over time.
Why? Design Working Group solicited input from patron community via surveys, interviews, and initial project manager interviews with library units. Allowed for rapid implementation of OPAC design with greatest amount of user input.
Why? To allow for broad input from interested parties, with final selection coming from Library leadership.
Why? To involve students in the final appearance of the public catalog in a way that would would hopefully attract other students.
index tag "a" = author (bib and authority records)
b = barcode (item and patron records)
c = call number, LC normalization (item and holdings records)
d = subject (bib and authority records)
e = other call number (item and holdings records)
f = linked patrons (patron record)
g = government document number (bib records)
h = place of publication (bib records)
i = standard number (bib records)
j = genre/form (bib records)
k = titlekey (bib records)
l = other control number (bib records)
m = subject (resource records)
n = name (patron records)
o = control number (bib records)
p = prof/TA (course records)
q = reserved for author/title searches in the web OPAC
r = course name/number (course records)
t = title (bib and authority records)
u = ID number (patron records)
v = GLADIS number (bib, holdings and authority records) - NOTE this could eventually be used for some other purpose, once need for an indexed Gladis number no longer exists
w = reserved for keyword index
x = currently tied to SISAC checkin product
y = resource name (resource records)
z = control number/ARN (authority records)
Why? A uniform title is assigned to a work that has no title, or has multiple valid titles, potentially in multiple languages or formats. Assigning and displaying a uniform title for these materials makes it easier for users to locate all known copies or versions of a particular item, regardless of variations in title, language, or format. This is especially important for music materials, which frequently have multiple valid titles.
Why? To allow for better user access to specific materials, the various $e relator codes/phrases ("roles") were included in the author index so that each one displays separately on the results screen, e.g.
"Twain, Mark, 1835-1910."
"Twain, Mark, 1835-1910. Associated name"
"Twain, Mark, 1835-1910. Correspondent"
"Twain, Mark, 1835-1910. Dedicatee"
"Twain, Mark, 1835-1910. former owner"
Why? There was no limit to the number of post-search options that could be included on the post-search limits page, multiple post-search limits can be selected by the user, and our data was better suited in some cases to provide reliable results with a post-search limit as opposed to a scope.
Why? To allow for better user access to foreign language materials and to provide the same functionality as Pathfinder.
Why? In recognition of the "continually beta" world in which our current patrons live and their expectations about continuous improvement.
Why? User survey indicated high interest in ability to search for online resources.
Why? Patrons can physically access items with these statuses. In this context, available means "available to view", but not necessarily "available to checkout".
Why? Charge indicated priority should be on services unique to OskiCat.
Why? Charge recommends refering users to other systems that may be better suited to meet their needs.
Why? Timeline didn't permit implementing before go live.
Why? Would require additional purchase.
Why? Requested by Implementation Team but rejected by Admin for cost and competition with Next Gen Melvyl concerns.
Why? Charge indicated design was to focus on casual or novice user. "More searches" provides search options for a more advanced user.
Why? Confusing to patrons; mostly needed by staff.
Why? Focus on casual user, not making it a tab de-emphasizes that option.
Why? Timing constraints and lack of general familiarity with the system made it impossible to create full text before going live. Fits with continuous improvement model.
Why? Part of mandate to serve needs of novice users. Suggestions suppressed if search has results because suggestions not always useful, especially if search is in another language. NOTE: spellcheck functionality limited and not modifyable.
Why? Sigificant collection in languages using non-Roman scripts. The scripts displayed are the ones III offers.
Why? Facilitate access to available, on campus items. Allow note to be added to holdings record when holdings split between campus and NRLF directing users to look below for items at NRLF.
Why? Provides patron with access details.
Why Two Separate Indexes? More than one call number index is needed in Millennium because we use more than one call number scheme. At the minimum, we're able to use two; one for LC call numbers and one for all other call numbers. Each call number scheme is formatted differently using a combination of letters, numbers, and punctuation. In order for searched call numbers to file and display in a way that makes sense to end users, a normalization rule is applied to the call number index. Normalization rules take into account letters, numbers, and punctuation, based on call number scheme attributes. Only one normalization rule can be applied per index, therefore, we require a separate index for LC values in order for them to be "read" and to file in an order which makes sense. "Other" call numbers may be comprised of any number of letters, numbers, and punctuation values, and in any order, so a different normalization scheme must be used.
Separate indexes are also required so that statistical reports based upon call numbers will make sense. Millennium contains something called a SCAT table. This table is comprised of ranges of LC call numbers based upon broad subjects, for example:
RE0000.0000-RE9999.9999 = Ophthalmology
RF0000.0000-RF9999.9999 = Otorhinalaryngology
When a circulation transaction occurs, if the item contains an LC call number (MARC tag 090), the value will be looked up in the SCAT table, and an entry will be logged. Over a period of time, we can then see what is circulating by subject range. In addition, we can also count volumes within general subject ranges. It's understood that these statistics will exclude any materials which have been cataloged using "other" call number schemes (MARC 099).
Each unique call number scheme or call number scheme with a different normalization rule at the library should reside alone in an index dedicated to its use. Storing call numbers that should have different normalization rules in the same index has implications for OPAC and Millennium display as well as statistics. Sorting in OPAC and staff browse displays may fail to work as desired. Interfiling of call numbers may not work as expected.
Why?Berkeley only indexes call numbers from item and holdings records (.i and .c). This is because branch items may use a call number which is unique from another branch. For example, History of California, has been cataloged with the following LC numbers at Berkeley branches:
An indexed call number in an item record applies only to that item, and an indexed call number in a holdings record applies only to that record. However, an indexed call number in a bibliographic record applies to all attached item records (except for those with an indexed call number in the item record.)
At Berkeley, indexing from attached records makes most sense, and was easiest to accomplish given our migration capabilities from GLADIS. Indexing from the bibliographic record makes most sense where all library copies use the same call number value, and where the exception (which could be indexed from an attached record) is an uncommon occurrence.
Why? We are running out of time and this is optional. This data was not available to query before in Gladis. Would not be easily usable, even if it were migrated. Paper trail dates back 10 years for audit.
Why? Facilitates patron access and notification (via patron placed holds) in an automated way. Allows patrons to know what materials have already been ordered, reducing unneeded order suggestions.
Why? We don't expect to receive the item and displaying it would be misleading.
YES PRV --> 561 (in bib record)
YES BIB --> 590 (in bib record)
YES SLF --> 990 (in bib record)
YES SUM/STO/STX --> 866 0$a (in holdings record)
YES INDEX SUM (if time to parse, otherwise, same as above)
YES LAK --> 866 0$z (in holdings record)
YES UPI --> "g"
YES SUF --> 945 $c (in item record)
YES SHL --> 945 $p (in item record)
YES PI (if holdings record is already being output, otherwise, no) --> "t"
NOTE: For decisions on having two separate call number indexes, and on indexing the call number from the attached (item, etc.) records instead of the bib record, see OPAC section.
Why? Because the 856 does not contain data which can be meaningfully indexed for public use. Since searching on field 856 is generally limited to staff, it was decided that create lists would could be used instead.
Why? 999 was reserved by III for migration processing. Therefore, we needed to drop any 999 from GLADIS output.
Why? Since 590 was used by cataloging for internal notes (record level 2 and 3), there was some question as to whether this field should be indexed. After careful analysis, it was determined that 590 had also been used for notes useful to the public. Consequently, we decided that the 590 should be indexed. [NOTE: 590 cataloging notes were subsequently moved to field 900.]
Why? Because 260$b is not entered as controlled vocabulary, a phrase indexing would not retrieve meaningful results; keyword search & post-search limiting provides more meaningful results. Limited number of indexes available.
Why? Included in the title index. Cataloging practices/Marc format do not support a meaningful index for users. (Series is no longer a controlled entry.) Will reduce confusion for the patron. Limited number of indexes available.
Why? Included in the author index. Do not need another index, just need a label. Limited number of indexes available.
Why? Blind authority records cause confusing results/deadlinks. Outsourcing of authority work recommended because of the lack of staff for in house work, and because for a database of our size it would be more effectively done in an automated way. The Advisory Group decided not to pursue outsourcing at time of implementation for budget reasons but could in the future. NOTE: Authority records which were blind on Gladis were not loaded to Millennium.
Why? Deletion of cataloged bibs can affect any or all of the ten cataloging units in the system. Suppression achieves the immediate need of removing the record from public view, allowing review and OCLC synchronization to happen behind the scenes before final delete. Deletion of cataloged bibs not widely distributed for data protection in an integrated system.
Why? To do research on cataloging practices, make recommendations, and get approval from Tech Services Council (TSC). A comprehensive understanding of the migration process was necessary for the task force to function effectively as a clearinghouse for technical processes. It is in the purview of the Implementation Team to charge it:
- Dana, Ginny, and Randy wrote the charge and Charis presented to the Advisory Group for approval;
- The task force was charged as a transitional group for 6 months;
- The task force was added as standing agenda items at Technical Services Council and BTECH meetings;
- Policy decisions were referred to Technical Services Council
Why? Editing a bibligraphic record allows for potential destruction of essential data, and the bib record can not be protected on a field by field basis nor on a location basis as other record types can. Essential information for synchronizing with OCLC can be lost via bib edits.
NOTE: This was tabled because of administrative changes in technical services. No changes have been made yet.
Why? There may be changes in strategy after VSO and reorganization of technical services staff.
Why? There are serials and other needs for duplicate call numbers - you would get a warning popping up for every item added which is not efficient or necessary.
Why? System requirement. The System allows a maximum of 5,000 item records per bibliographic record. Innovative recommends the user stay below the maximum because it makes it easier to add missing items and allows room for expansion. The Migration loaded up to 3,999 item records per bibliographic record. If there were more than 3,999 items on a given Gladis records, a duplicate bibliographic record was created during the load. The result is there can be more than one bibliographic record for a given title.
Why? To reduce disruption to library users and staff. To reduce the risk of a system crash during peak usage periods.
Why? Since we planned to go live at the end of a semester, it would be easier to have reserve staff put summer reserves directly in Millennium. One few thing to try to migrate.
Why? Millennium Reserves are for course reserves only. LSO can transfer permanent reserve items with a "Reserves" SUF note into the unit's reserve location.
Why? To facilitate circulation staff's understanding of the loan periods. To make borrowing rules more consistent and easier for the patron to understand/predict across campus.
Why? To accommodate subject specialty libraries loan periods.
Update These decisions were changed by the Advisory Group from what the Implementation Team initially recommended.
Why? Too difficult to maintain loan rule tables each semester. Approved by the Advisory Group.
Why? Allows for cleaner migration and reduce risk of double billing. Fine and billing data may be lost in the migration.
Why? Millennium can't process credits to patrons. Miminize impact on LBO. Similar to standard business practices outside the Library.
Why? To assist staff and library users with useful return information.
Why? Reduce training needed by general circ staff. Reduce potential for cataloging errors.
Why? Concerns about staffing needs and funding; more information needed before final decision is made.
Why? So patrons won't be billed on day one after migration. Time to return tiems before billing.
Why? To be use in the case of the network being down.
Why? PC clocks have to be synchronized for offline circ to work. Too easy to make mistakes.
Why? There are several situations where a proxy card would have been used in the past, but can now be covered by: status codes, transfer procedure, personal cards, and special projects. Each situation needs to be addressed and sorted by the New Processes Group for new procedures, since these processes involve staff from various departments.
Why? No other option available in Millennium. Advisory Group made aware. Offers the best public service - allows us to get materials back more effectively when other patrons need them.
Why? Certain staff outside of NRLF need to add data to item records belonging to NRLF, for example, binding prep and conservation notes, cleaning up items belonging to branches but at NRLF. In addition, without NRLF item scoping, staff are unable to sort, transfer or link NRLF items.
Why? NRLF Restricted Working Group recommended that all patron requests for NRLF restricted items be staff-mediated.
Why? Restricted materials cannot be used at NRLF or loaned to another library. They can only be used at the owning library. This setup ensures that the patron sees the name of the owning library where they need to go to request the material.
System Set-up and Maintenance
Any location that might want discrete stats needs to be a discrete location or group of locations easily identified.
Why? Takes advantage of built-in functionality.
Why? Takes advantage of built-in functionality.
Why? The purpose of the location code is to tell the patron where to find the item.
Why? For reporting purposes and to support Loan Rule table maintenance using wild-carding.
Why? To keep staff from being confused while working with the codes.
Why? To support maintenance of Hours Open and Days Closed tables, which determine due dates/times and fines assessed (for finable items).
Why? Loan rule determiner table limit of 1499 lines. Overhead is a nightmare.
Why? The lists in hand from the Holdings WG are samples and may be incomplete. Each unit head needs to be sure it is correct and complete.
Why? Location does not exist.
Why? It seemed like the best trade-off at the time. NRLF locations could be grouped by institution, owning location code, and then NRLF circ status. Loan rules could be designed to support NRLF loan rules based on institution and NRLF circ status.
Why? Desire is to have code structure that can be used for a long time into the future.
Positions 1-2: two letter loc code from GLADIS four letter loc.
Position 3: Prefix, from call number prefix. Will need a translation table to convert doubles ("ff") to a single character ("g"?).
Position 4: Suffix, from standardized list of 33 or so, if possible.
Position 5: Save for future use, if possible, or use for suffix overflow if not.
Why? To facilitate wildcarding and standardize the structure of locations.
Why? To make clustering easy. Allows wildcarding.
Why? New Books should be a sublocation, because a charge doesn't indicate to the public that they can come in and view the items, and being a sublocation allows units to vary in their policy about patrons ability to check out/place holds on new books materials. NOTE: This is being changed as of spring 2010 per Sciences Council and circulation services, because the location of New Books had an unacceptable workflow impact.
Why? Allows for labeling - system allows for a call number prefix, but the sublocation is needed if there is a special shelving area.
Why? To accommodate need for list creation.
Distribution of Create Lists review files can be reviewed and revised after gaining some experience with the types of usage and level of demand.
Why? Integrity and security of the system.
Passwords will expire after 360 (the maximum). Users will be warned 25 days prior expiration and be prompted to change their password. After eight (8) failed login attempts the user will be forced to re-launch the client. We will not presently require a password change upon the first login. New passwords must be different from the old ones. The password length is 8 characters (which is campus standard minimum and Millennium maximum) including at least one (1) lower case; two (2) numeric and one (1) upper case character. No non-alpha characters will be required.
Why? To comply with campus security requirements
Why? To work around password formatting issues.
Why? Desire was to make most items that could someday become available requestable for ease of patron notification and potentially to assist replacement decisions based on number of holds.
Why? Initially we set up "Serial other" as "Serial - short term". For most units, the regular serials loan is short term. Changing the label reduces confusion and the need to move serial items from one itype to another. In order to accommodate unit loan policies, only the Loan Determiner table entries would need to be changed.
Update Penny now handling hours tables.
Why? Easier for maintenance to be centralized in Systems, in part because troubleshooting of problems done in Systems.
Why? Distributed model to allow for most efficient routing of record maintenance tasks along with appropriate oversight.
Why? Most accessible room. Also, to have a dedicated space for training.
Why? Recommended by Innovative as the best size group.
Why? To make certain staff have basic understanding of how to use the modules to perform their tasks.
Why? Pareto Principle. Economy of staff and trainer time. More complex issues will be revealed with usage and can be addressed by trainers as they arise.
Why? To ensure quality and consistency of training without overly taxing staff. Also a requirement, since III follows a "train the trainer" policy. re: documentation. Trainers are in the best position to write documentation. They know what staff need to know and also whether or not documentation is accurate/an effective learning tool. Trainers should have training as part of their job description to ensure supervisor approval and release time needed.
Why? To involve all levels of staff in the process of determining how modules should be set up.
Organize a Library wide process to evaluate how bibliographic, authority, and item sample data loaded into the Millennium test database. Coordinate evaluation of how the information mapped over from Gladis, how the data is indexed, how field group tags are assigned, involving a wide range of Library staff. Organize a process for submitting and responding to input from the Library community and make recommendations on feedback to the Implementation Team for possible referral to III. Coordinate Profile Evaluation training for the Library community with support from the Training Working Group. NOTE: This group is not working on OPAC display.
Why? The more staff involved in evaluation, the better our finished product. Need to call on a wide range of expertise.
Why? To simplify administrative tasks and to reduce the time needed to do them while capturing what is important in our meetings (action items and decisions).
Why? It seems important to give III the range of complexity, so they/we can make good decisions about implementation.
Why? Agreement with III.
Why? Minimize risks, control who is doing what activity, ensuring that there is adequate training, and ensuring accountability.
Why Provide historical perspective of reasons for decisions made. Allows the implementation team to be able to evaluate the process and the project. It is important doing implementation to know what decisions were made and why.
Why? To bring staff up to speed on the project.
Why? Staff currently using Gladis and/or Innopac will need the Millennium client to do their work.
Why? To allow circulation of newly cataloged items without having to create Q-level records on Gladis.
Why? This is a large project that will require staff participation throughout the library.
Why? Convenience for those who want it.
Why? Not possible
Why? Did not have a choice. III's policy
Why? - See details of what the Implementation Team recommended and WHY for each module here: http://sunsite3.berkeley.edu/wikis//ILS/index.php?n=Links.MillenniumModules
Essential: Patron API, Materials Booking, Deposit Collection, url Checker, Encore
Desired: All the rest, with Telephone Renewals first.
InnReach marked for future consideration.
UPDATE October 16, 2008: The Advisory Group has limited the number of additional modules to be purchased that have ongoing expenses due to budget concerns.
Why? - Imp Team prioritized them because budget concerns and implementation timeline would not allow implementing all available modules. Imp Team in best position to evaluate and recommend each module because of familiarity with Millennium and with overall Library needs and operations.
Why? Phil's expertise could be helpful for duration of the project. Could use his help for the following:
1. Review and coordinate system and workflow documentation. Comment: Providing those who need to write this a template to make it easy and an incentive (someone caling to ask about it) could help them actually do it. Phil won't have local expertise to create such documentation.
2. Be present each week of going live, on site.
3. Help operations unit get scripts set up, canned reports, etc.
4. Help working groups focus their work, be a quick way to answer questions.
5. Be "on call" to answer our Millennium expertise questions quickly.
Why? Allowed to keep separate OCLC holdings symbols so these libraries can keep their ILL revenue and maintain separate OCLC identities. Included during the project instead of after so that our III implementation team would be available to help guide us in the complex process of incorporating this new record source, and so that training for Affiliated library staff can be part of general Millennium implementation training.
Why? Already supported in house.
Why? Overlap of both systems running circulation at the same time not possible, because of synchronization problems. Also not desirable to offer OPAC view of "stale" data - hence a full cutover required on Go Live date.
Why? Freeing busy records is necessary but potentially dangerous and should be limited to a small group of people.
A few people from each module will be authorized to free busy records. This will be publicised so staff know who to contact.
Draft Policy (for Acq/Ser): At minimum, wait overnight before freeing a record. OK for LSO to free busy records after waiting overnight if tickets come in via the OskiCat HelpDesk.
Policy for Circ could be different than Acq/Ser/Cat.
Free Busy records will remained controlled but some staff should have that ability to assist patrons with checkout.
No new staff accounts will be given Free Busy authorization.
Why? Danger is that freeing a record that is really in use will wipe out someone.s work. It may also create broken links and broken patron holds. Records are busy when they are in a payfile.
Why? Need a way to manage the system resources needed to run create lists. Also need to manage use of a limited number of lists.
Why? The ILS team has the best overview of the entire project.
Almost anyone who can edit an item record will be given permission to delete item records
All other records will be marked for review then gathered into a file to be reviewed. Once reviewed, the records will be marked for deletion. LSO will gather these records into a file and delete them. Reviews will be done by the following people:
Bib records and monographic holdings records will be reviewed by Database Maintenance
Order records will reviewed and deleted by orders head.
Order records can also be deleted if not attached to a full bib or are duplicates.
Vendor records can be deleted by the payments unit.
Serials holdings will be reviewed by Serials Head
Self cataloging units will review their own records
Why? To balance accountability with ease of work flows.
Why? Templates are powerful tools. We want oversight to help reduce changes of creating bad data. Sending an example record should make it easier to create accurate templates.
Why? When we batchload records for UCB faculty, staff, and students, we will use campus' email of record for the person. The message warns UCB patrons to update their desired email with campus. To avoid pressure on the Privileges Desk, patrons who can't update their email address with campus must be able to change it for themselves.
Why? Defaults are sufficient; no need to customize.
Why? Need a group to handle continuous improvements once the Implementation Team concluded its charge.
Why? Rapid update is an extremely powerful tool subject to massive errors, which consumes significant amounts of system resources. Limiting not only who has access but defining rules for when and how it can be used is intended to protect our data.
Why? All needed data for operations will be migrated at that time.
Why? Decision made by Chuck Eckman.
Why? Desirable not to run backups while units are open because backups queue up record updates.
Why? Easy and safe - there is little that can be harmed in web management reports.
Why? Authorization to edit items is a matter of training and need, not tied to specific modules.
Why? Still need access for a handful of people at a time on the training server, but most licences needed on production after going live.