| Records Criteria Work Group | ||
| Checklist of Specific System Requirements | ||
| Criteria Name | Criteria Description | Rating |
| ACQUISITIONS | ||
| Systems & Standards | ||
| Electronic Data Exchange (EDI) | Ability to exchange acquisitions information in electronic form according to the latest standards, ANSI X12 and UN/EDIFACT using industry implementation guides.This includes our ability to send orders and claims to vendors and receive electronic acknowledgments from them; also their ability to send and our ability to receive invoices, claim responses, dispatch data, and reports electronically. | Essential |
| UN/EDIFACT | international standards | Essential |
| X12 | US standards | Essential |
| BISAC | standard for book format | Essential |
| SISAC | standard for serials format | Essential |
| Ability to check in serial issues using SICI barcodes | Desirable | |
| Interfaces with Oracle | Invoices get paid once on both systems; you only have to enter vendor & other information in one system & it appears in both | Essential |
| Ability to load bibliographic records from a variety of sources | from vendors as well as from OCLC, RLIN, MARCIVE, etc. | Essential |
| Interfaces with LARS binding system | Communicates with a commercial binding management software | Desirable |
| Acquisitions | ||
| No size limitations to number of lines in invoice | Essential | |
| Must be able to pay single invoice with > 500 funds | Essential | |
| Can move between parts of the record or different records easily | e.g. between check-in & bib record or order record & invoice record | Essential |
| Security system which limits staff who can work on the order/pay/receipt record | You can only modify acquisitions records from your library (no one else's) | Essential |
| Can order, pay, and claim electronically & record these activities in system for non-EDI compliant vendor | Important | |
| System validates fund and vendor codes | Blocks use of inappropriate (e.g.belonging to another library) or non-existent codes; person with high level security clearance could manually override existing codes (but not non-existent ones!) | Important |
| Detects duplicate invoices | Will block invoices with same vendor & invoice no.; can manually override | Important |
| Keeps statistics | Counts orders, receipts, payments, etc. | Important |
| Offers easy way to flip back & forth between staff & public view | one click or split screen | Important |
| Dynamic currency update | Important | |
| Ability to do keyword searching in staff mode | Important | |
| Acquisitions record is searchable by all data fields; system allows Boolean searching | Searchable fields should include selector, operator id, create date, vendor, vendor invoice no., donor, order status, order type, fund, price, format, etc. | Important |
| Note fields should be at least 2000 characters long | Room for special receipt processing notes (reserve, requestor, etc.). Vendor memos may have to be shorter to accommodate printed purchase orders. | Important |
| Can relink order records | e.g. can relink publisher info and order no. for serial title changes | Important |
| Only have to enter information once; system can reformat data for different purposes | e.g. when you check-in serials issues, system generates MARC holdings record | Important |
| Claiming occurs automatically (unless you stop it) | Feature can be disabled if you don't want it; you should also be able to initiate claims manually | Important |
| Can set up workflow defaults, preferences and save them | Desirable | |
| Ability to do vendor evaluation | Can compute average length of time vendor takes to fill an order, etc. | Desirable |
| System gives alert when it's reaching a space or other limit | Desirable | |
| Ability to show discount for an individual item | Desirable | |
| Ability to call up approved invoice by vendor's invoice number | Desirable | |
| Default exists to set currency for each vendor | Desirable | |
| Can change info after invoice has been approved | e.g.vendor or fund | Desirable |
| Ability to go back one screen in order record | Currently you can't go back to the previous screen; you have to go back to the beginning of the order record & scroll ahead | |
| Serials | ||
| Flexible serials check-in system | Can change patterns easily; can override system when predictive patterns are inappropriate | Essential |
| Customizable ways to sort indexes | Can sort series by volume number | Important |
| Can have the same item records on more than one bib record | for series standing orders, can have item records on serial record AND individual volumes | Important |
| System loads dispatch information into serial record electronically and performs updates | When system is notified of late issues, it automatically updates claiming date | Important |
| System generates pattern predictions | Staff don't have to enter patterns from scratch | Important |
| Can relink serial patterns to new order record or bib record | for title changes | Important |
| Automatic claiming when issue is skipped in check-in | i.e. when there's a gap in checking in issues, claiming happens automatically | |
| Serials check-in automatically generates MARC holdings record | Important | |
| Language code generates crib sheet | for bibliographic terms in that language (vol., issue, part, etc.) | Desirable |
| URL's in check-in record link to electronic journal issues | Desirable | |
| RECORD EXCHANGE, CATALOGING AND AUTHORITY CONTROL | ||
| Record Exchange | ||
| Load bibliographic records | Ability to load MARC bibliographic records from a variety of sources (OCLC, RLIN, MARCIVE, etc.) with ability to add/delete/modify fields | Essential |
| Load authority records | Ability to load new and changed authority records from a variety of sources (OCLC, LC, etc.) without requiring local programming | Essential |
| Load replacement bibliographic records and transaction records | Ability to load both replacement bibliographic records and correction transactions (i.e., field- level updates) | Essential |
| Real-time download of authority and bibliographic records | Ability to download authority and bibliographic records in real time without using third-party software | Essential |
| Extract and reload of bibliographic records | Ability to extract and reload bibliographic records without local programming required. (For authority control or TOC processing) | Essential |
| Access to LC's catalog of bibliographic and authority records | Ability to use LC authority and bibliographic records and to derive or copy them | Essential |
| Test region/database | Existence of test region/database so that new releases or enhancements can be tested without risk to the catalog or its availability | Essential |
| Retain local fields during authority record batch updates | Ability to automatically perform field by field comparison and update of standard authority records in batch mode (i.e., retaining local fields such as 090, and 644, 646) | Essential |
| Import/export of all MARC bibliographic formats | Support import/export of the full MARC suite of formats | Essential |
| Import/export of MARC non-bibliographic formats | Support import/export of MARC non-bibliographic formats (classification and community information) | Important |
| Z39.50 compliant | Support a Z39.50-compliant technical services client, including the ability to search and import bibliographic records | Essential |
| Error reporting on import/export | Support customized error reporting on import and export | Essential |
| Overlay of bibliographic or authority records | Ability to specify the bibliographic or authority record that is to be overlaid upon record import | Essential |
| Large record size | Ability to create/import/export very long records such as those used for Archives or the Fortunoff Video Archive | Essential |
| Backups | Frequent and easily recoverable backups (daily) should be available. | Essential |
| Cataloging | ||
| Full-screen text editor | Ability to enter a complete bibliographic record from a blank screen | Important |
| Optional drop-down help boxes | Presence of drop down boxes for fixed field codes, but also option to type them in if cataloger wants to | Important |
| Constant-data records/templates for bibliographic records | Ability to create multiple constant data records/templates. These should be available at the server level or at the workstation level | Essential |
| Field validation in bibliographic records | Support fixed field and tag validation for local input of bibliographic records | Essential |
| Macros | Ability to create true macros as well as "quick keys". These should be available at the server level and at the workstation level | Essential |
| Copy/Paste | Support copy/paste from one session to another, from one bibliographic record to another, from an authority record to a bibliographic record and vice-versa, and from one application to another. Ability to perform copy and paste multiple fields. | Essential |
| Relink order record | Ability to relink order record from one bibliographic record to another or one copy to another | Important |
| Multiple workflow options | Options regarding where cataloging takes place. For example: cataloged on utility and downloaded to Orbis, or cataloged on Orbis and uploaded to utility | Essential |
| Entering diacritics | Map diacritics to keyboards with minimal keying | Essential |
| UNICODE | Support the full USMARC Character Set and the proposed UNICODE standard, including non-Roman character sets (Chinese and Japanese, among others) | Essential/Important |
| ALA character set | Support the full ALA character set, including diacritics, for input and display | Essential |
| Holdings | ||
| Export of bibliographic and holdings data together+A50 | Ability to upload Yale holdings to RLIN and OCLC using batch process | Essential |
| MARC holdings | Load and store standard MARC21 Holdings Format records from a variety of sources, including update of pattern data only | Essential |
| MARC holdings ease of editing | Support copy/paste and use of macros for record creation, including easy overlay and transfer of pattern data | Essential |
| MARC holdings diacritics input and display | Support diacritics and special characters for holdings input and display | Essential |
| Flexible design of holdings display | Allow for alterable arrangement of copy and location display | Important |
| Authority Control | ||
| Constant-data records/templates for authority records | Allow configurable templates for input of new authority records, with more than one option | Important |
| Global change | Ability to perform global change reliably and with a minimum of quality control required | Essential |
| Global change ability for non-heading fields | Ability to create global change for non-authority controlled headings and fields | Important |
| No blind references. | If there are no headings under a reference, do not display the reference in the OPAC. This must be accomplished without manual interventions (i.e., editing the authority record) | Essential |
| Heading verification | Support real-time validation and verification of headings used in record creation | Essential |
| Field validation in authority records | Support fixed field and tag validation for local input of authority records (just in case we start creating them in Orbis, and uploading them to a utility such as OCLC using a macro) | Important |
| Error reporting | Support regular error reporting of duplicates, cross-reference conflicts, obsolete fields, and other conflicts and errors | Essential |
| Automatic creation of authority records | Support automatic creation of individual authority records via local utility or macro | Important |
| Item Records | ||
| One to many relationships with item records | Ability to link one record to multiple bibliographic records (resolving bound-with problems) | Essential |
| Relink item records | Ability to relink item records from one bibliographic record to another or one copy to another | Essential |
| Search and Display | ||
| Keyword | Ability to do keyword searching in staff mode | Essential |
| Dynamic indexing | Immediate indexing of all fields in bibliographic records so that record is searchable as soon as the record is filed in the catalog | Essential |
| Locally-defined indexes | Ability to locally define indexes and the display of search results. This should be available at the server level or at the workstation level | Essential |
| Uniform title indexing | Uniform title indexing must be correct and/or understandable | Essential |
| Preparations | ||
| Spine labels | Support the automatic creation of spine labels | Essential |
| CIRCULATION | ||
| Patron Records | ||
| Create patron records | Ability to manually create and update patron records with validation and ID duplication check | essential |
| Import/Export of patron data | Ability to customize patron loaders to import and export fixed and delimited patron data | essential |
| Dynamic patron record update | Dynamic update of patron address info from the oracle personnel files; ability to submit updates to same files | desired |
| Multiple ID's | Ability to have multiple check-out ID's attached to or associated with a patron (I.e. proxies) and have notices go to the primary patron or (even better) have the faculty proxy record set up in the student patron record internally w/o the need for a proxy card. Notices would be sent to the patron that checked the items out | essential |
| Multiple ID's - update | Ability to do batch updates, renewals against items attached to all ID's | essential |
| Multiple ID's - display all information | Display only active ID's in index, but display all items attached to patron, regardless of ID status | important |
| ID changes | If ID is changed, transfer all attached transactions and financial info to new ID; retain and index old ID | essential |
| Staff-initiated ID changes | Ability to manually record new ID's and deactivate lost ID's | essential |
| Normalize patron names in searching | Normalize hyphens, spaces, irregular capitalization in patron searches | important |
| Patron self-initiated Address Update | Ability for patrons to update their own address and e-mail information | essential |
| Patron self-initiated Status View | Patron can independently access status of items checked-out, items requested, and bill & fine information via web or telephone | essential |
| Patron self-initiated Circulation | Self-initiated check-out, renewals, recalls, pages, ILL requests, etc. and self initiated cancellation of all these functions. | important |
| Patron self-initiated Authentication / Security | Password-protected access to patron info; no sending of social security information over the internet in display screens, etc. | essential |
| Patron self-initiated One-stop Shopping | A patron request is issued for material; the system determines the action necessary to obtain it - page, ILL request, hold, recall, etc. | desired |
| Fines Information | ||
| Batch update of fines | Ability to pay, forgive, or credit all, or a selected number of fines for a patron | essential |
| Import/Export fine information | Ability to dynamically send fines to Bursar and receive payment updates (Oracle financial system) | essential |
| Import/Export credit information | Ability to import deposit account or credit card information at circulation desk or patron initiated from OPAC. | important |
| Online access to financial information | Access archival financial information in real time | essential |
| Item records | ||
| Create circulation records on the fly | Ability to create unlinked item or temporary item records from within circulation in order to check-out records that are not fully cataloged | essential |
| Attach item record to Bib. Record | Ability to attach an item record to a fully catalogued record at the circulation desk | essential |
| Circulation history | Record last 2 patrons to check-out item | essential |
| Route Item records | At circ desk the Ability to 'flag' or 'route' a book for review by staff w/o placing a hold on it. An easy check system preferred | essential? |
| Serial and multi-volume sets | Ability to easily view summary list and see checked out volumes from staff mode | essential |
| Serial and multi-volume sets | Ability to attach an item record to a fully catalogued record for an individual volume or number at the circulation desk | essential |
| Flexible item codes | Ability to locally define codes describing the item | essential |
| Automatic action dates | Ability to set action date after which unfulfilled pages, recalls, etc. generate a specific action send messages to staff etc. | important |
| ILL Services | ||
| ILL Services - ISO 10160 / IPIG profile | ILL modules must conform to ISO 10160 standards, with conformance to the IPIG Profile for the ISO ILL Protocol (this protocol is used by RLG and OCLC) | essential |
| Interface with ILL management software | Such as ILLIAD and CLIO | desired |
| ILL Services - Z39.63-1989 | Support Z39.63-1989 to facilitate ILL communication | important |
| Inventory | ||
| Remote scanning | Ability to scan items and record browse statistics and shelf list information | important |
| Reserve records | ||
| Faculty notification | Course list electronically emailed to Faculty before each semester | important |
| Faculty generated reserve lists | reserve list generated by faculty and e-mailed to staff | desired |
| Batch reserve list update | Ability to update previous reserve lists all at once when there will be no changes made | important |
| Easy back out of reserve creation | Ability to easily back out and/or delete when processing reserve input | essential |
| Reserve Records in OPAC | Ability to search reserve list in OPAC for linked and unlinked res. Records | essential |
| Activation and deactivation of reserve records | Ability to batch activate and deactivate course reverve list set to start and end dates | essential |
| Automatic purging of Res. Records | Ability to automatically purge course reserves that have been inactive for a designated period of time and the ability to manually delete a course reserve list | important |
| Electronic Reserves | Ability to store digital version of reserve item, along with copyright and use/fee information | important |
| Patron authentication | Ability to associate students with specific classes for electronic reserves copyright purposes | important |
| Course list with multiple faculty | Ability to have one course reserve list w/ multiple faculty | desired |
| Course list w/ URL's and scanned notes | Ability to point to URL's and digitized materials from the OPAC reserve list | desired |
| Media Booking records | ||
| Equipment and Seminar Room | Ability to schedule equipment and seminar rooms on a calendar schedule | desired |
| Access to archival media booking info | Ability to access archival booking schedule via reports | desired |
| Circulation Functions | ||
| Basic Functions | Basic functions the system should have: check-in, check-out, renewal, hold, recall, page, flexible calendaring; ability to set in-transit, missing, billed, claims returned, and other locally defined conditions; ability to print receipts and routing slips | essential |
| Online backup | Back-up circulation function for when on-line system is down | essential |
| Loan rules - item, location, patron matrix | Easily create and maintain complex loan period structure based on item type, item location, circulation location, and patron type, including the ability to create loan periods down to the minute | essential |
| Renewal function | Ability to process a batch or a select renewal. Ability to recognize and not renew certain types of item record (ILL item records) | essential |
| Holds against in-process materials | Ability to place a hold against an in-process or on-order material that does not have an item record | important |
| Over-ride all system circ dates | Ability to manually change dates for check-outs, check-ins, renewals, etc. | essential |
| Easy back-out of processes | Ability to back-out of a check-out, renewal, etc. while in-process | essential |
| Alerts - visual and audio | System should provide visual and audio alerts when the item being processed has an outstanding check-out, hold, recall, fine, block, or note. | important |
| Accept all electronic input | Accept all types of barcodes, magswipe, other input | essential |
| Consecutively numbered lists | Number all lists of items, patrons, fines, etc. in consecutive order for clear scrolling through lists | essential |
| Notices | Create notices for courtesy reminders, overdues, recalls, items available, and bills; ability to output notices via e-mail, voice, fax, and print | essential |
| Access to archival circulation info | Access to archival circulation information via reports | important |
| Macro Editor | Macro editor for creating macros to facilitate circulation activities | essential |
| Statistics | Systematic recording of all circulation activities for later statistical analysis | essential |
| Navigation | ||
| Simple navigation to related records | Ability to see detailed info about related item, patron, circulation history, and fine records from any point in circulation | essential |
| Security | ||
| ID level security | Ability to limit circulation activities by login ID | essential |
| Function level security | Ability to password-protect all circulation activities to allow supervisor over-ride | essential |
| No use of sensitive patron data in system | No use of patron social security numbers and other sensitive information in screen displays, passwords, printed receipts, or other system functions. | essential |
| COLLECTION DEVELOPMENT AND RESEARCH SERVICES | ||
| Collection Information | ||
| Compile statistics by bibliographic criteria | The system should be able to compile and report collection statistics according to a combination of cretiria: classification range (including Yale class), country/date/language of publication, format and/or type of publication (e.g., serial, monograph, monographic series, government document, microform). | Essential |
| Compile statistics by holdings criteria | The system should be able to differentiate among copies, volumes and/or other multi-level holding designations and be able to compile collection statistics according to holding location (branch, departmental, etc.) and/or shelf location (reserve, reference, bindery). | Essential |
| Support cooperative collection development | The system should be capable of generating all necessary information for institutional participation in cooperative collection development programs. | Important |
| Collection Tasks | ||
| Create title lists by cost | The system should be able to compile title lists (both serial and monographic) in specified classification ranges organized in specified cost ranges. (Example: Display the number of acquired monographic titles in the range LE-LF costing more than $100 for fiscal years 1998 - 1999.) | Essential |
| Create continuation orders | The system should be able to consolidate and report a union list of all continuation orders (serials, sets, standing orders, memberships) for the entire library or any subset thereof. | Essential |
| Support individual selector's tasks | The system should provide an indexed field in acquisition and/or other related records for the identification of individual selectors with regards to collection development activities. | Essential |
| Support non-roman tasks | The system should be capable of handling unicode and should allow for searching and displaying of information in non-roman, esp. JACKPHY+ (i.e., Japanese, Arabic, Chinese, Korean, Persian, Hebrew, Yiddish and Cyrillic), scripts. | Important |
| Create recent acquisition lists | The system should be able to create recent acquisition lists as specified by the entire library or any subset thereof. (Example: Create a file of all monographs cataloged between 1/1/99 and 1/31/99 arranged by call number for the Art Library.) | I |
| Use Statistics | ||
| Track usage for remote storage facilities | The system should be able to compile and report use statistics in specified categories for materials housed in remote storage facilities. | Essential |
| Track journal usage | The system should be able to track and report journal usage for both current and bound issues. The vendor should specify whether such a feature requires bar codes on individual issues and/or procedures for key entry of data. | Desirable |
| Link usage with fiscal data | The system should be able to link the journal usage tracking feature and fiscal data reflecting the cost of the title. | Desirable |
| Link usage with patron data | The system should allow the correlation of aggregate patron data with collection and usage data. (Example: Report the number of undergraduates circulating monographs in the call number range ZA-ZB.) | Desirable |
| Generate purchase alerts | The system should be able to generate purchase alerts for titles circulated, renewed, recalled, or borrowed through interlibrary loan more than the number of times specified. | Desirable |
| METADATA | ||
| Search and retrieve across metadata schema & databases | (i.e. ability to communicate and integrate with MARC21 and non-MARC21 tagged data outside the LMS) - LMS can seamlessly search multiple databases that use various metadata schema, retrieve the metadata records, usefully present the results to the reader, and enable the reader to obtain and make use of the materials. | Essential |
| Translation and exchange across metadata schema & databases | (i.e. ability to convert non-MARC21 tagged data into MARC21 within the LMS and the ability to convert MARC21 tagged data into other forms of metadata [e.g. Dublin Core in XML and HTML, TEI-header, etc.]) - LMS supports metadata schema translation and record exchange for staff in single transaction and batch process modes to allow high flexibility for re-purposing metadata in whatever form is best for a given project or need. For example: header in TEI-conformant SGML document is converted by catalog staff to MARC21 format at workstation; 1,000 MARC21 records converted by batch process to Dublin Core XML for inclusion in web-oriented database of e-resources; 50,000 VRA core records converted to MARC21 by loader program for inclusion in online catalog. | Important |
| Catalog integrates multiple metadata schema within the catalog | LMS supports multiple metadata schema internally; must include MARC21 and Dublin Core at minimum. This is a CORC-like catalog, and RDF-XML environment. LMS must also support translation and record exchange (mentioned above in # 1) for metadata schema that are not native to the catalog. | Desirable |
| Catalog supports current hyperlinking protocols | LMS can understand hyperlinks embedded in metadata and parse them. (Including Hytime, MARC21 856, XLINK, LINK, HREF) | Desirable |
| LMS must support open-system design for metadata | LMS should openly share information with external systems needing to access core metadata - i.e. LMS cannot just export to external systems. | Desirable |