Pricing Proposal Software Licenses - PDF by fll58227

VIEWS: 30 PAGES: 163

More Info
									                             Request for Proposal (RFP)

                                        No. 1JLJ505

                                Digital Library Products

                       PROPOSAL MAILING DATE: February 13, 2004

                            PROPOSAL DUE DATE: April 1, 2004

                       PROPOSAL DUE TIME: 2:00 P.M. , Local Time

NOTE: Proposer must complete the enclosed, Appendix VIII, Vendor Disclosure of Financial
Interests. Failure to complete and return this form with Proposer’s response will result in its
being considered non-responsive to this solicitation.


Technical questions regarding this RFP’s specifications should be directed to:

                                         Bernie Sloan
                                     bernies@uilllinois.edu


              Frequently asked questions will be posted at the following location:

                     http://office.ilcso.illinois.edu/Reports/dlpc/rfpfaq.html


Questions regarding general                Send or deliver Proposal to:
proposal procedures should be
directed to:                                    University of Illinois at Urbana-Champaign
                                                Purchasing Division
    Judy Johnson                                616 East Green Street
    Purchasing Division                         Suite 212
    Phone (217) 333-1225                        Champaign, IL. 61820
    FAX (217) 244-7941
    judyjohn@uiuc.edu
                                                          RFP No.1JLJ505


Table of Contents

1. INTRODUCTION ………………………………………………………………………………1
   1.1 DESCRIPTION OF PROPOSAL ………………………………………………………1
   1.2 ILCSO BACKGROUND ………………………………………………………………...1
   1.3 OVERVIEW ……………………………………………………………………………...1
   1.4 ILCSO TECHNICAL ENVIRONMENT ………………………………………………...3
   1.5 POTENTIAL SCOPE OF PROJECT ………………………………………………….4
   1.6 IMPLEMENTATION ……………………………………………………………………..4
   1.7 TIMETABLE OF ACTIVITIES …………………………………………………………..5

2. INSTRUCTIONS TO PROPOSERS………………………………………………………….5
   2.1 INSTRUCTIONS ……………………………………………………………………….. 5
   2.2 PROPOSERS PACKAGE ……………………………………………………………...5
        2.2.1 TECHNICAL PROPOSAL………………………………………………………5
        2.2.2 PRICING PROPOSAL ………………………………………………………….6
        2.2.3 CONTRACT ……………………………………………………………………..6
        2.2.4 EXCEPTIONS AND RESTRICTIONS ………………………………………..6
   2.3 DELIVERY OF PROPOSAL PACKAGE ………………………………………….... 7
   2.4 UNIFORMITY …………………………………………………………………………....7
   2.5 PROPOSED MATERIALS ……………………………………………………………..7
   2.6 AMENDMENT ……………………………………………………………………….…..7
   2.7 PROPOSAL MODIFICATION ………………………………………………………....8
   2.8 PERIOD OF FIRM PROPOSAL ………………………………………………….……8
   2.9 PROPOSER’S RESPONSIBILITY TO READ RFP …………………………………8
   2.10 ERRORS AND OMISSIONS …………………………………………………………..8
   2.11 RFP INTERPRETATIONS ……………………………………………………………..9
   2.12 CONFIDENTIALITY AND RESPONSE COST AND OWNERSHIP …………….…9
   2.13 USE OF SUBCONTRACTORS …………………………………………………….….9
   2.14 PROPOSER’S RESPONSIBILITY FOR SERVICES PROVIDED ……………..…..9
   2.15 ILLINOIS DEPARTMENT OF HUMAN RIGHTS NUMBER …………………………9
   2.16 TAXPAYER IDENTIFICATION NUMBER ……………………………………………..9

3. PROPOSAL EVALUATION PROCEDURE AND CRITERIA ………………………….…10
   3.1 ACCEPTANCE OF PROPOSALS ………………………………………………….…10
   3.2 PROPOSER QUALIFICATIONS ………………………………………………………10
   3.3 PROPOSER PRESENTATIONS ………………………………………………….…..10
   3.4 RIGHT TO INSPECT …………………………………………………………….……..11
   3.5 PAYMENT TERMS ……………………………………………………………………..11
   3.6 BEST AND FINAL OFFER ……………………………………………………………..11
   3.7 EVALUATION OF PROPOSALS ………………………………………………….…..11

4. AWARD OF CONTRACT ……………………………………………………………………..12

5. TERMINATION BASED ON FUNDING ………………………………………………….…..12




                                                                       i
                                                             RFP No.1JLJ505



APPENDIX I     PROPOSER INFORMATION AND FUNCTIONAL SPECIFICATIONS
               DIGITAL OBJECT MANAGEMENT SYSTEM

APPENDIX II    PROPOSER INFORMATION AND FUNCTIONAL SPECIFICATIONS
               FEDERATED SEARCH SOFTWARE

APPENDIX III   PROPOSER INFORMATION AND FUNCTIONAL SPECIFICATIONS
               LINK RESOLVER SOFTWARE

APPENDIX IV    PRICING INTRODUCTION

INDIVIDUAL COMPONENT PRICING PROPOSAL ATTACHMENTS

DIGITAL OBJECT MANAGEMENT SOFTWARE
ATTACHMENT 1: ACQUISITION MODEL – UNLIMITED SITE LICENSES
ATTACHMENT 2: ACQUISITION MODEL – PER LIBRARY
ATTACHMENT 3: ACQUISITION MODEL – COST FOR EACH ILCSO LIBRARY
ATTACHMENT 4: SUBSCRIPTION MODEL – UNLIMITED SITE LICENSE
ATTACHMENT 5: SUBSCRIPTION MODEL – PER LIBRARY
ATTACHMENT 6: SUBSCRIPTION MODEL – COST FOR EACH ILCSO LIBRARY


FEDERATED SEARCH SOFTWARE
ATTACHMENT 7: ACQUISITION MODEL – UNLIMITED SITE LICENSES
ATTACHMENT 8: ACQUISITION MODEL – PER LIBRARY
ATTACHMENT 9: ACQUISITION MODEL – COST FOR EACH ILCSO LIBRARY
ATTACHMENT 10: SUBSCRIPTION MODEL – UNLIMITED SITE LICENSE
ATTACHMENT 11: SUBSCRIPTION MODEL – PER LIBRARY
ATTACHMENT 12: SUBSCRIPTION MODEL – COST FOR EACH ILCSO LIBRARY

LINK RESOLVER SOFTWARE
ATTACHMENT13: ACQUISITION MODEL – UNLIMITED SITE LICENSE
ATTACHMENT 14: ACQUISITION MODEL – PER LIBRARY
ATTACHMENT 15: ACQUISITION MODEL – COST FOR EACH LIBRARY
ATTACHMENT 16: SUBSCRIPTION MODEL – UNLIMITED SITE LICENSE
ATTACHMENT 17: SUBSCRIPTION MODEL – PER LIBRARY
ATTACHMENT 18: SUBSCRIPTION MODEL – COST FOR EACHY ILCSO LIBRARY




                                                                      ii
                                                                RFP No.1JLJ505


APPENDIX V      PRICING INTRODUCTION

BUNDLED PRICING PROPOSAL ATTACHMENTS

ATTACHMENT 1: PROPOSER HOSTED SYSTEM
ATTACHMENT 2: CUSTOMER HOSTED SYSTEM
ATTACHMENT 3

APPENDIX VI      PRICING INTRODUCTION

ALTERNATIVE PRICING PROPOSAL ATTACHMENTS

ATTACHMENT 1: ALTERNATIVE METHOD - ACQUISITION
ATTACHMENT 2: ALTERNATIVE METHOD - SUBSCRIPTION

APPENDIX VII     ILCSO TECHNICAL ENVIRONMENT
ATTACHMENT 1: ILCSO SERVER MAP
ATTACHMENT 2: ILCSO NETWORK MAP

APPENDIX VIII    VENDOR DISCLOSURE OF FINANCIAL INTERESTS

APPENDIX IX      BIDDERS APPLICATION FORM

APPENDIX X       INDEMNITY AGREEMENTS AND LIABILITY INSURANCE

APPENDIX XI      SAMPLE CONTRACT TERMS AND CONDITIONS

APPENDIX XII     CERTIFICATIONS AND PREFERENCES




                                                                         iii
                                                                                     RFP No.1JLJ505


1.   INTRODUCTION
     1.1   DESCRIPTION OF PROPOSAL
The Board of Trustees of the University of Illinois (the University) on behalf of the Illinois Library
Computer Systems Organization (ILCSO) seeks sealed proposals from qualified vendors
(“Proposers”) to provide some or all of the products and services listed below for the benefit of
the students and faculty in ILCSO member institutions of higher education. Awards will be
made for the period (effective date of contract through June 2006) with the option to renew for
four additional annual renewal periods at the same terms and conditions based on satisfactory
performance, continuing need and availability of funds.

           ILCSO is interested in licensing some or all of the following digital library software
           products:

           a. Digital Object Management Software (DOMS) to be used to store and
              manipulate the digital objects in member library collections, whether locally
              produced or acquired. The digital objects to be managed include, but are not
              limited to, photographs, maps, digitized historical documents, artwork, movie
              clips, engineering drawings and distance learning information. Appendix I of this
              RFP provides the technical requirements for this component.

           b. Federated Search Engine capable of simultaneously searching multiple
              electronic resources and providing consolidated, de-duplicated, and organized
              sets of results. Such systems are also known as cross-domain search engines,
              one-search systems, or metasearch systems. Appendix II of this RFP provides
              the technical requirements for the Federated Search Engine.

           c. Link Resolver capable of linking citations from electronic abstracting and
              indexing databases, an integrated library system, or other searching tool to a
              library’s licensed, full text electronic resources, regardless of the provider of
              either the citation or full text resource. Appendix III of this RFP provides the
              technical requirements for the Link Resolver.

     1.2   ILCSO BACKGROUND
           The mission of ILCSO is to enhance and expand access to and effectively utilize
           information resources through collaborative partnerships among ILCSO members
           and with the Illinois Library community.

           ILCSO is a consortium of 65 Illinois member institutions that cooperatively share
           access to their resources, and operate a shared online integrated library system.
           ILCSO’s online union catalog, ILLINET Online, currently contains over 8 million
           bibliographic records, nearly 30 million item holding records, and over 600,000
           patron information records. A list of the 65 ILCSO member institutions can be found
           on the ILCSO web site at http://office.ilcso.illinois.edu/About/ilcsolibs.html.

           More information about ILCSO is available at http://office.ilcso.illinois.edu.




                                                                                                    1
                                                                              RFP No.1JLJ505


1.3   OVERVIEW
      This RFP seeks to expand and enhance the ability to effectively utilize electronic
      information resources to support the teaching, learning and research missions in its
      member institutions. Proposers should be fully aware that the products and services
      they offer must function in a very diverse and complex technological environment.
      Components of that environment include:

      •   An integrated library system shared by all members.         The current system is
          Voyager from Endeavor Information Systems.

      •   A variety of full text and other information resources common to all participants
          including a selection of EBSCOhost databases and a selection of OCLC First
          Search databases.

      •   Information resources acquired and maintained by each member library. Many of
          these are typical academic library databases (e.g., MLA International
          Bibliography or MEDLINE), while others may be unique to a single member
          library.

      •   Locally implemented tools for the management of electronic resources (e.g., A to
          Z journal manager products, citation managers).

      •   Locally created and maintained databases of documents and images.

      1.3.1   The overall licensed solution will be a competitive bidding process and may
              include awards to multiple proposer’s product(s). ILCSO has charged the
              Digital Library Products Committee (DLPC) with evaluating and
              recommending the best mix of components for the ILCSO community,
              regardless of Proposer.         For example, it is possible that the final
              recommendation might include the Digital Object Management Software from
              one Proposer, the Federated Search Software from another Proposer, and
              the Link Resolver Software from yet another Proposer. A Proposer may
              respond to any or all of the three software components of the RFP.

      1.3.2   While this RFP is being issued on behalf of a consortium (ILCSO), any
              proposed configuration must be able to function as a local digital library
              system, in addition to any consortial integration. For example, a library must
              be able to use the digital object management software to manage and
              present its own digital library collection, and a library must be able to use the
              federated searching and link resolver software to search its own resources
              and link to these resources. While ILCSO libraries do have a number of
              electronic resources in common, these libraries also subscribe to a number of
              resources at the local level, with electronic resource subscription packages
              varying from library to library.

      1.3.3   The Proposer may offer more than one configuration for its products and
              services, however, each configuration must be submitted as a separate
              Response. Different configurations of a product must individually and
              completely address all of the technical specifications listed and must provide
              a clearly labeled price quotation for each specific configuration. Care should


                                                                                         2
                                                                              RFP No.1JLJ505


              be taken to address all questions related to the integration of the Proposer’s
              products with the existing elements of the ILCSO environment (ILS,
              information resources, etc.) and the other components sought in the RFP
              (DOMS, Federated Search, and Link Resolver).

              Awards will be made for proposals that will interface and are compatible with
              all the other selected product proposals submitted as responses to this RFP.

              ILCSO is taking a flexible approach towards software configuration to allow
              solutions that work best for individual libraries. One library might have its
              own separate instance of one of the software modules, where a subset of
              ILCSO libraries might conceivably share another instance. A library might
              maintain its own instance of a module on its own server, or choose to have
              ILCSO maintain it on an ILCSO server.

      1.3.4   Proposers are encouraged to review all of the requirements and propose
              their product as a solution in the best-suited individual section of the RFP. In
              addition, Proposers may offer collaborative responses to address the
              comprehensive needs of ILCSO. If such a collaborative response is
              proposed, a single organization should be identified as the proposed
              contractor, with other parties acting as subcontractors.

      1.3.5   ILCSO possesses a centralized consortial computing infrastructure.
              Additionally, each member library also has a library and/or campus
              computing infrastructure. The Proposer should identify the minimum required
              and preferred computing environment for its products and provide a detailed
              description of the optimum configuration of its products and services as part
              of the Response. Software may reside on local campus servers, centrally on
              ILCSO-maintained servers (customer hosted) or on Proposer servers
              (proposer hosted). The Proposer should note that the products and services
              offered will have to function with other products and services residing in all of
              these computing environments.

1.4   ILCSO TECHNICAL ENVIRONMENT
      Following is a brief summary of the current ILCSO technical environment running
      Endeavor Voyager 2001.1. Appendix VII provides schematic diagrams of this
      environment. Proposers are not required to submit responses that are compatible
      with ILCSO’s current hardware and software environment (e.g., Sun, Oracle).
      However, any additional costs of supporting a proposed solution that is outside of the
      existing environment will be considered as part of the Total Cost of Ownership during
      the evaluation and award of proposals.

      1.4.1   ILCSO maintains centralized servers for the entire consortium. These
              servers are housed at the University of Illinois at Chicago (UIC) campus in
              the Administrative Information Technology Services (AITS) department's data
              center. All current production, test, and training servers are using the Sun
              Solaris operating system and are running on Sun Microsystems hardware.
              The main production server is a Sun Fire 15K and has additional capacity for
              more production server domains.




                                                                                         3
                                                                             RFP No.1JLJ505


      1.4.2   ILCSO has a Class C network subnet on a Foundry switch with 10/100Mbps
              copper and gigabit fiber ports. Web servers are load-balanced using Cisco
              LocalDirector hardware. Internet access is provided by the UIC campus
              backbone with a majority of library traffic routed through the Illinois Century
              Network (ICN). The ICN is a state-run network providing high speed network
              access to K-12 schools, colleges, universities, public libraries, museums, and
              local and state government agencies.

      1.4.3   Disk storage is about 12TB of raw disk mainly composed of external Sun T3
              disk arrays. To provide 24x7 production availability, daily disk level snapshots
              are created using Sun's Instant Image software. The snapshot or "shadow
              volume" is then backed up to tape. An additional Sun Fire 15K and support
              equipment are being purchased for disaster recovery purposes and will be
              housed at the University of Illinois at Urbana-Champaign (UIUC) campus.

      1.4.4   ILCSO consortium servers are covered by a University of Illinois site license
              for Oracle database and support software. Proposer should indicate in the
              technical response what Oracle licenses are necessary for implementing the
              proposed solution.

1.5   POTENTIAL SCOPE OF PROJECT
      ILCSO conducted a preliminary survey among its member libraries to gather
      information regarding the potential interest in implementing some or all of the
      products being sought in this RFP. A summary of the non-binding survey results
      shows:

      •   Seven of the 58 respondents have digital object management software. Two use
          this software only for limited specific purposes and do not plan to use it on
          broader level, and two are actively looking for software to replace what they
          presently have. Forty of the 58 respondents would consider implementing digital
          object management software via ILCSO.

      •   Two of the 58 respondents have implemented federated search engines. Forty-
          eight of the 58 respondents stated that they would consider implementing an
          ILCSO federated search engine.

      •   Eleven of the 58 respondents have link resolvers. Forty-eight of the 58
          respondents indicated that they would consider implementing an ILCSO link
          resolver.

      1.5.1   The ultimate number of member libraries implementing any or all of the
              products selected in this RFP will depend on a variety of factors, including
              cost to the member library, immediate vs. long-term need for the functionality
              offered, technical capacity and expertise available within the member library,
              and the extent to which the products add value to the library’s support of
              teaching, learning and research.




1.6   IMPLEMENTATION


                                                                                         4
                                                                                 RFP No.1JLJ505


           ILCSO anticipates a phased implementation of the products and services selected.
           A representative number of member libraries will be selected in Fall 2004 to
           participate in the first phase of implementation. In consultation with the successful
           Proposer(s), an implementation plan will be developed that targets July 2005 as the
           anticipated time for making products and services available to the students and
           faculty of participating libraries.

     1.7   TIMETABLE OF ACTIVITIES
           •   RFP document available for electronic download by prospective respondents:
                                                           February 13, 2004
           •   Proposal submission deadline:               April 1, 2004, 2 PM Local time
           •   Finalist vendor(s) presentations            Late May/Early June 2004

2.   INSTRUCTIONS TO PROPOSERS
     2.1   INSTRUCTIONS
           This RFP provides potential Proposers with sufficient information to enable them to
           prepare and submit proposals. This RFP also contains the instructions governing
           the submittal of a proposal and the materials to be included therein, including
           mandatory requirements, which must be met to be eligible for consideration, and
           other requirements to be met by each proposal. All proposals must be complete as
           to the information request in this RFP in order to be considered responsive.
     2.2   PROPOSERS PACKAGE
           To facilitate evaluation, submit the Proposal in two (2) parts as described below. The
           parts may be submitted in the same package provided the parts are clearly
           separated and identified as outlined in Sections 2.2.1 and 2.2.2 below. Contact Judy
           Johnson, Purchasing Division, by email, judyjohn@uiuc.edu for electronic copies of
           Appendices I – VI.
           2.2.1   TECHNICAL PROPOSAL
                   Submit one (1) original (clearly marked as “Original”) and fifteen (15) copies
                   of the Technical Proposal in a sealed package clearly marked with the RFP
                   number and “Technical Proposal”.
                   The following documents comprise the Technical Proposal:

           •   Responses to Proposer Information and Functional Specifications, Appendix I, II,
               III.
           •   Completed and signed Forms A and B of Vendor Disclosure of Financial Interest,
               Appendix VIII.
           •   Completed and signed Bidder Application Form, Appendix IX, if the University
               doesn't already have one on file.
           •   Examples of Contracts and Exceptions to terms and conditions in Appendix XI.
           •   Completed information and signed Requirements and Certifications, Appendix
               XII.

                   The response to the Functional Specifications (Appendix I, II, III) must be
                   submitted in electronic version as an electronic document submitted via
                   email, email attachment, diskette, or CD-Rom in MS Word. This is in addition


                                                                                            5
                                                                       RFP No.1JLJ505


        to the hard-copy requirement defined above. Receipt of an electronic copy
        alone does not meet the requirements established by the State of Illinois
        Procurement Code.

2.2.2   PRICING PROPOSAL
        Submit one (1) original (clearly marked as “Original”) and fifteen (15) copies
        of the completed and signed (Appendix IV, V, VI) in a separate and sealed
        envelope that is clearly marked with the RFP number and “Pricing Proposal.”
        The responses should include any supplemental or renewal option period
        pricing schedules (Appendix IV, V, VI).

        The following documents comprise the Pricing Proposal.

        •   Signed response to the Appendix IV, Attachments 1-17
        •   Signed response to the Appendix V, Attachments 1-3
        •   Signed response to the Appendix VI, Attachments 1-2

        Proposers must submit a response for each attachment of Pricing Documents
        (Appendix IV, V and VI). If you do not wish to propose a solution for a
        particular model, indicate “no” to the first question listed on each attachment
        form, “Are you offering pricing for this model?” and sign the attachment.

        The responses to the Pricing Documents (Appendix IV, V, VI) must also be
        made available on diskette or CD-Rom using MS Excel. This is in addition to
        the hard-copy requirement defined above. Receipt of an electronic copy
        alone does not meet the requirements established by the State of Illinois
        Procurement Code.

2.2.3   CONTRACT
        Provide a copy of your established standard company contract with the
        proposal. A listing of the University’s standard terms and conditions
        applicable to Software and Professional Services contracts can be found in
        the Contract Language in Appendix XI of this Request for Proposal (RFP).
        This language will be incorporated into any contract resulting from an award
        of this RFP. Specific additional contract details will be added to the contract
        based on substantive information provided in any successful Respondent’s
        response.
        Any exceptions to the University’s standard terms and conditions shown in
        Appendix XI must be made explicit and clearly indicated in the Respondent’s
        response. Additionally, any alternate language and/or terms and conditions
        to an exception must be provided by the Respondent in the response
        submitted to the RFP.

        The University reserves the right to negotiate all terms and conditions.

2.2.4   EXCEPTIONS AND RESTRICTIONS
        Any exceptions to any of the terms, conditions, specifications, protocols,
        and/or other requirements listed in this RFP must be clearly noted by
        reference to the page number, section, or other identifying reference in this


                                                                                   6
                                                                           RFP No.1JLJ505


             RFP. All information regarding such exceptions to content or requirements
             must be noted in the same sequence as its appearance in this RFP.

             Any restrictions on the use of data contained within a proposal or resulting
             from the services to be provided under contract resulting from this RFP must
             be explicitly noted in the Proposer's response. If proprietary information is
             submitted, such information must be clearly marked as “Proprietary” or
             “Confidential” and the University will be protected to the extent permitted by
             State of Illinois Statutes (see also 2.12).

2.3   DELIVERY OF PROPOSAL PACKAGE
      The Technical Proposal, including the signed Contract, and the Pricing Proposal,
      may be either delivered by hand or sent to the Purchasing Division through U.S. Mail
      or other available courier services to the address shown on the cover sheet of this
      RFP. Include the RFP number on any package delivered or sent to the University
      Purchasing Division and on any correspondence related to the Proposal. The
      Proposer remains solely responsible for insuring that its Proposal is received at the
      time, date, place, and office specified. The University assumes no responsibility for
      any Proposal not so received, regardless of whether the delay is caused by the U.S.
      Postal Service, the University Postal Delivery System, or some other act or
      circumstance. Proposals received after the time specified in the RFP will not be
      considered. All Proposals received after the specified time will be returned
      unopened.

      If using an express delivery service, the University recommends that the package be
      delivered to the designated building and office and not to the University Postal
      Delivery System or Central Receiving facilities. Packages delivered by express mail
      services to other locations might not be re-delivered in time to be considered.

2.4   UNIFORMITY
      To provide uniformity and to facilitate comparison of Proposals, all information
      submitted must clearly refer to the page number, section, or other identifying
      reference in this RFP. All information submitted must be noted in the same sequence
      as its appearance in this RFP. The University reserves the right to waive minor
      variances or irregularities.

2.5   PROPOSED MATERIALS
      The Proposal material submitted in response to the RFP becomes the property of
      the University upon delivery to the Purchasing Division and is to be appended to any
      formal document which would further define or expand the Contractual relationship
      between the University and the Proposer. All of the material will be considered as
      part of this RFP.


2.6   AMENDMENT
      In the event it becomes necessary to revise any part of this RFP, an Amendment to
      this RFP will be provided by the University, to each potential Proposer who received
      the original RFP. Proposers shall not rely on any other interpretations, changes, or
      corrections. An Amendment issued to Proposers prior to the proposal opening date


                                                                                      7
                                                                              RFP No.1JLJ505


      may include an acknowledgment section. Since all Amendments become a part of
      the Proposal, any amendment requiring signature must be signed by an authorized
      Proposer representative and returned with the proposal on or before the proposal
      opening date. Failure to sign and return any Amendment requiring signature
      acknowledgement shall be grounds for rejection of the Proposal response.

2.7   PROPOSAL MODIFICATION
      Proposals submitted prior to the Proposal opening date may be modified or
      withdrawn only by written notice to the University. Such notice must be received by
      the Purchasing Division prior to the time designated for opening of the Proposal.
      Proposer may change or withdraw the Proposal at any time prior to Proposal
      opening; however, no oral modifications will be allowed. Only letters or other formal
      written requests for modifications or corrections of a previously submitted Proposal
      that are addressed in the same manner as the Proposal and that are received prior
      to the scheduled Proposal opening time will be accepted. The Proposal, when
      opened, will then be corrected in accordance with such written requests, provided
      that the written request is contained in a sealed envelope that is clearly marked with
      the RFP number and “Modification of Proposal”. No modifications of the Proposal will
      be accepted at any time after the Proposal opening date and time.

      A withdrawn Proposal may be resubmitted up to the time designated for the receipt
      of Proposal provided that it is then fully in conformance with the requirements of the
      RFP.

2.8   PERIOD OF FIRM PROPOSAL
      Prices for the proposed service must be kept firm for at least three hundred and sixty
      (360) days after the last time specified for submission of Proposals. Firm Proposals
      for periods of less than this number of days may be considered non-responsive. The
      Proposer may specify a longer period of firm price than indicated here. If no period is
      indicated by the Proposer in the Proposal, the price will be firm until written notice to
      the contrary is received from the Proposer, unless otherwise specified in this RFP.

2.9   PROPOSER’S RESPONSIBILITY TO READ RFP
      It is the Proposer's responsibility to thoroughly examine and read the entire RFP
      document. Failure of Proposers fully to acquaint themselves with existing conditions
      or the amount of goods and work involved will not be a basis for requesting extra
      compensation after the award of a Contract.

2.10 ERRORS AND OMISSIONS
      The Proposer is expected to comply with the true intent of this RFP taken as a whole
      and shall not avail itself of any errors or omissions to the detriment of the services.
      Should the Proposer suspect any error, omission, or discrepancy in the
      specifications or instructions, the Proposer shall immediately notify the University, in
      writing, and the University shall issue written instructions to be followed. The
      Proposer is responsible for the contents of its Proposal and for satisfying the
      requirements set forth in the RFP.

2.11 RFP INTERPRETATIONS



                                                                                         8
                                                                             RFP No.1JLJ505


    Interpretation of the wording of this document shall be the responsibility of the
    University and that interpretation shall be final.

2.12 CONFIDENTIALITY AND RESPONSE COST AND OWNERSHIP
    From the date of issuance of the RFP until the opening date, the Proposer must not
    make available or discuss its Proposal, or any part thereof, with any employee or
    agent of the University. The Proposer is hereby warned that any part of its Proposal
    or any other material marked as confidential, proprietary, or trade secret, can only be
    protected to the extent permitted by Illinois Statutes. The University is not liable for
    any cost incurred by Proposers in developing and submitting a proposal. All material
    submitted in response to this RFP becomes the property of the University of Illinois.

2.13 USE OF SUBCONTRACTORS
    If the Proposer intends to use Subcontractors to provide product or perform any
    portion of the proposal described in this RFP, the Proposal must clearly state so. The
    Proposer’s response must include a description of which portion(s) of the product or
    work will be Subcontracted out, the names and addresses of potential
    Subcontractors and the expected amount of money each will receive under the
    Contract.

2.14 PROPOSER’S RESPONSIBILITY FOR SERVICES PROVIDED
    It is understood and the Proposer hereby agrees that it shall be solely responsible for
    all services they propose, not withstanding the detail present in the RFP.

2.15 ILLINOIS DEPARTMENT OF HUMAN RIGHTS NUMBER
    All responses require an Illinois Department of Human Rights (IDHR) number or a
    statement by the Proposer that a PC-1 Employer Report Form has been submitted to
    the Department.

    Note: If a Proposer received an IDHR number prior to July 1, 1998, the Proposer
    may be required to apply for a new number.

    For more information, contact the IDHR, Public Contracts Unit, Suite 10-100, 100
    West Randolph Street, Chicago, Illinois 60601, (312) 814-2431, or see the following
    Web Sites: http://www.state.il.us/dhr/index or http://www.state.il.us/cms.

2.16 TAXPAYER IDENTIFICATION NUMBER
    The Proposer is required to provide its Taxpayer Identification Number (TIN) in the
    Contract. The following instructions pertain to the TIN:

    •   Enter the Proposer’s taxpayer identification number in the appropriate space in
        the Contract (). For individuals and sole proprietors, this is the individual’s social
        security number. For other entities, it is the employer identification number.
        Federal Employer Identification Numbers (FEINs) must not be used for sole
        proprietorships.
    •   If the Proposer does not have a TIN, apply for one immediately. Individuals must
        complete Form SS-5, Application for a Social Security Number, which can be
        obtained from a local office of the Social Security Administration. All other entities



                                                                                        9
                                                                                  RFP No.1JLJ505


              must complete Form SS-4, Application for Employer Identification Number, which
              can be obtained from a local office of the Internal Revenue Service.

3.   PROPOSAL EVALUATION PROCEDURE AND CRITERIA
     The University, acting on behalf of the member institutions in ILCSO, will award a contract
     to one or more responsible Proposer(s) whose proposals are determined to be the most
     advantageous to the University and to the ILCSO consortium. Consideration will be given
     to the evaluation factors, requirements and purchase conditions, and the costs set forth in
     this RFP.

     This RFP seeks proposals for three separate and distinct, though functionally related
     components (Digital Object Management Software, Federated Search Software, and Link
     Resolver Software). Responses for each specific component will be evaluated on its own
     merits, and in competition with all other Responses for that specific component.

     Proposers are not required to submit proposals for all three desired components. While
     the ability of a Proposer to offer all three components as a well-integrated solution will be
     given full consideration in the evaluation process, no Proposer will be disadvantaged for
     submitting a proposal for a single component. However, that component must have the
     capability to be integrated with the products and services of other Proposers and existing
     ILCSO vendors, so that an integrated solution can be produced meeting the needs of
     ILCSO members.

     All proposals will be reviewed by an evaluation team, comprising designated staff from the
     University Office for Planning and Budgeting and ILCSO member libraries. Evaluation
     team members have experience in working with digital library management products and
     in evaluating vendor responses for library service RFPs.

     3.1   ACCEPTANCE OF PROPOSALS
           The University, acting on behalf of the member institutions in ILCSO, reserves the
           right to reject any or all Proposals or any part thereof, to waive informalities, and to
           accept the Proposal deemed most favorable to the University.

     3.2   PROPOSER QUALIFICATIONS
           The Proposer must demonstrate that it has the management and operational
           experience, financial resources and personnel necessary to successfully perform the
           services specified in this RFP. A Proposer must be financially solvent.      These
           matters must be addressed in the responses to the questions in Appendix I,
           Appendix II, and Appendix III.



     3.3   PROPOSER PRESENTATIONS
           The University, acting on behalf of the member institutions in ILCSO, reserves the
           right to, but is not obligated to, request and require that each Proposer provide a
           formal presentation of its Proposal at a date and time to be determined. If required
           by the University, it is anticipated that such presentation will occur in late May or
           early June. No Proposer will be entitled to be present during, or otherwise receive
           any information regarding, any presentation of any other Proposer.


                                                                                            10
                                                                             RFP No.1JLJ505



3.4   RIGHT TO INSPECT
      The University, acting on behalf of the member institutions in ILCSO, reserves right
      to inspect and investigate thoroughly the establishment, facilities, equipment,
      business reputation, and other qualifications of the Proposer and any proposed
      Subcontractors and to reject any Proposal irrespective of price if it shall be
      administratively determined that the Proposer is deficient in any of the essentials
      necessary to assure acceptable standards of performance. The University reserves
      the right to continue this inspection procedure throughout the life of the Contract that
      may arise from this RFP.

3.5   PAYMENT TERMS
      Payment terms of less than thirty (30) days will not be considered in making the
      Contract award. However, any applicable discount offer will be taken if payment is
      processed within the stated time.

3.6   BEST AND FINAL OFFER
      ILCSO reserves the right to request a Best and Final Offer from finalist Proposer(s),
      if it deems such an approach necessary. In general, the Best and Final Offer would
      consist of updated costs as well as answers to specific questions that were identified
      during the evaluation of Proposals.

      If ILCSO chooses to invoke this option, proposals would be re-evaluated by
      incorporating the information requested in the Best and Final Offer document,
      including costs, and answers to specific questions presented in the document. The
      specific format for the Best and Final Offer would be determined during evaluation
      discussions. Turnaround time for responding to a Best and Final Offers document is
      usually brief (e.g., ten (10) business days).

3.7   EVALUATION OF PROPOSALS
      All Proposals will be reviewed by an evaluation team. Based on this evaluation the
      University will determine the award of the Contract.

      The University, acting on behalf of the member institutions in ILCSO, will award the
      Contract to the responsible Proposer whose offer is determined to be the most
      advantageous to the University, taking into consideration price and the evaluation
      factors set forth in this RFP.      It is the intent of the University to enter into
      negotiations with the firm(s) whose proposal(s) are deemed most advantageous.
      The University will award the contract(s) to the respondent(s) whose proposal best
      serves the interest of the University. The University reserves the right to award a
      contract to a respondent selected on a basis other than least cost.
      This RFP seeks proposals for three separate and distinct, though functionally
      related, components (Digital Object Management Software, Federated Search
      Software, and Link Resolver Software). Responses for each specific component will
      be evaluated on its own merits, and in competition with all other Responses for that
      specific component.

      Proposers are not required to submit proposals for all three desired components.
      While the ability of a Proposer to offer all three components as a well-integrated


                                                                                       11
                                                                                 RFP No.1JLJ505


          solution will be given full consideration in the evaluation process, no Proposer will be
          disadvantaged for submitting a proposal for a single component. However, that
          component must have the capability to be integrated with the products and services
          of other proposed solutions and existing ILCSO vendors, so that an integrated
          solution can be produced meeting the needs of ILCSO members.

          All proposals will be reviewed by an evaluation team, comprising designated staff
          from the University Office for Planning and Budgeting and ILCSO member libraries.
          Evaluation team members have experience in working with digital library
          management products and in evaluating vendor responses for library service RFP’s.

          The University reserves the right to contact Proposer references or other libraries,
          request Proposer to provide written responses to questions, and/or ask the Proposer
          to travel to ILCSO for clarification of RPF responses.

          Failure of the Proposer to provide in his/her proposal any information requested in
          this RFP may result in disqualification of his/her proposal and shall be the
          responsibility of the responding individual or firm.

          The following evaluation factors, grouped by relative order of importance, will be
          used in determining the best-qualified offers:
          • Functionality and viability of proposed solution
          • Total cost of ownership
          • Implementation plan to meet ILCSO staged project plan
          • Vendor viability

4.   AWARD OF CONTRACT
     The University, acting on behalf of the member institutions in ILCSO, will award a contract
     to one or more responsible Proposer(s) whose proposals are determined to be the most
     advantageous to the University and to the ILCSO consortium.

5.   TERMINATION BASED ON FUNDING
     Since the Contract resulting from this RFP may be funded from both State of Illinois and
     Federal appropriated funds, the Proposer understands that this Contract is subject to
     termination and cancellation without any penalty, accelerated payment, or other
     recoupment mechanism as provided herein in any fiscal year for which the Illinois General
     Assembly or U.S. Government fails to make an appropriation to make payments under the
     terms of this Contract. In the event of termination for lack of appropriation, the Proposer
     shall be paid for services performed under this Contract up to the effective date of
     termination and notice of such termination will be submitted to the Proposer in writing not
     less than sixty (60) days prior to the effective date.




                                                                                           12
                                            RFP No.1JLJ505




                    RFP # JLJ505


                Digital Library Products




                    APPENDIX I



Proposer Information and Functional Specifications

       Digital Object Management Software
                                                                                    RFP No.1JLJ505

                 ILLINOIS LIBRARY COMPUTER SYSTEMS ORGANIZATION
                        DIGITAL LIBRARY PRODUCTS COMMITTEE

     APPENDIX I – PROPOSER INFORMATION AND FUNCTIONAL SPECIFICATIONS

                        DIGITAL OBJECT MANAGEMENT SOFTWARE

GENERAL OVERVIEW

The Board of Trustees of the University of Illinois (University) on behalf of the Illinois Library
Computer Systems Organization (ILCSO) seeks to license Digital Object Management Software
(DOMS) to be used to store and manipulate the digital objects in member library collections,
whether locally produced or acquired. The digital objects to be managed include, but are not
limited to, photographs, maps, digitized historical documents, artwork, movie clips, engineering
drawings and distance learning information.

ILCSO is a consortium of 65 Illinois academic libraries, serving over 600,000 students and
faculty. ILCSO members freely share access to their resources, and operate a shared online
integrated library system. ILCSO’s online union catalog, ILLINET Online, currently contains
over 8 million bibliographic records for nearly 30 million holdings.

Both commercially acquired and locally produced digital objects are becoming an increasingly
important component of many ILCSO member libraries collections. Member libraries have a
need to efficiently and effectively store, organize, and make accessible digital objects in
furthering their institutional missions to support study, teaching and research. They especially
seek to integrate the use of digital objects with existing print and electronic textual resources. In
addition, ILCSO desires to make the delivery of digital objects a component of its consortial
resource sharing mission.

Care should be taken to address all questions related to the integration of the Proposer’s
products with the existing elements of the ILCSO environment (integrated library system,
information resources, etc.) and the other components sought in this RFP (Federated Search,
and Link Resolver). The Proposer must clearly state and describe how the DOMS product will
accomplish this integration.

The ILCSO Consortium is seeking a system that will enable the capture, storage, searching and
presentation of digital objects. Responses to this Request for Proposal must clearly outline the
use and scope of any third-party applications included as part of the overall system. Additional
costs and/or licensing agreements associated with the use of any third-party applications must
be provided in the appropriate sections of this RFP. Further, responses must detail known
incompatibilities with operating systems, browser versions, and any other hardware or software.
Any functionality that requires custom, fee-based configuration should be clearly described and
fully disclosed.

ILCSO TECHNICAL ENVIRONMENT

See Section 1.4 of the Introduction section for a complete description of ILCSO’s technical
infrastructure and capacities. Appendix VII of this RFP provides schematic diagrams of the
ILCSO environment.




IMPLEMENTATION
                                                                                         Appendix I.1
                                                                                RFP No.1JLJ505


ILCSO anticipates a phased implementation of the selected DOMS products. Representative
ILCSO member libraries will be selected in the Fall of 2004 to participate in a Phase I
implementation of the DOMS. In consultation with the successful Proposer, an implementation
plan will be developed, with July 2005 as the anticipated target to make the DOMS available to
the students and faculty of participating libraries (see Section 1.6 of this RFP for more
information).

PRICING

Proposers must submit a response for each attachment of Appendix IV, V and VI. If you do not
wish to propose a solution for a particular model, indicate “no” to the first question listed on
each attachment form, “Are you offering pricing for this model?” and sign the attachment.

Where applicable, ILCSO prefers that the license or subscription allow ILCSO to use as many
instances of the software as might be needed to properly serve authorized ILCSO libraries.
This could enable ILCSO libraries to explore various alternative configurations. One library
might have its own separate instance of one of the software modules, where a group of libraries
might conceivably share another instance. A library might maintain its own instance of a
module on its own server, or choose to have ILCSO maintain it on an ILCSO server, or have the
software run on a Proposer’s server. ILCSO will consider all proposed configuration models.
Appendix IV, V, VI of this RFP contains additional information on submitting pricing models.

EVALUATION PROCESS

Evaluation of the Responses this RFP for digital object management software (DOMS) will be
conducted by a team comprising staff of the University of Illinois Office for Planning and
Budgeting and ILCSO member libraries. See Section 3.7 of the Introduction for additional
information.




                                                                                    Appendix I.2
                                                                                  RFP No.1JLJ505

                        DIGITAL OBJECT MANAGEMENT SOFTWARE

This Appendix I and Proposer’s response to it will be incorporated into the final Contract.

Note: Proposer shall state the name of the product being bid in this section, and describe the
most current version in use by customers. Proposer shall state whether this service will be
Proposer hosted or Customer hosted. If more than one version of the same software
component is offered by the Proposer, a separate set of functional specifications must be
submitted for each software version.

Proposer may recommend various configurations, either operated by the Proposer, by ILCSO,
or by individual libraries. Different configurations of a product must individually and completely
address all of the technical specifications listed and must provide a clearly labeled price
quotation for each specific configuration (see Section 2.2.2 of the Introduction section for
additional information on submitting pricing).
Responses must be provided in both hard copy and as an electronic document submitted via
email, email attachment, diskette, or CD-Rom in MS Word. To provide uniformity and to
facilitate comparison of Proposals, all information submitted must clearly refer to the page
number, section, or other identifying reference in this RFP. All information submitted must be
noted in the same sequence as its appearance in this RFP. Only graphical figures may appear
at the end of the responses and they must be clearly numbered and referenced in the text of the
response. It is not the responsibility of the University to search through the RFP response or
long appendices to locate relevant information that may answer the questions listed below.
Such responses may be considered “Non-responsive”.


1.      Respondent Corporate Information
1.1     Contact Personnel
Fill in the requested information for the following personnel:

            Primary Contact Person (if different     Person Authorized to Negotiate and
            from Respondent)                         Make Commitment for Respondent
Name
Title
Address
Address
Phone
800
Fax
Email
Signature


1.2     Organization Chart of Key Personnel
Provide a current organization chart for your company



                                                                                       Appendix I.3
                                                                                    RFP No.1JLJ505

1.3     Respondent Demographics

Year of incorporation/business registration


Human Resource Distribution by Function             Total Corporation
Total number of employees
Number of employees in sales & marketing
Number of employees in client support
Number of employees in consulting services
Number of employees in research and
development
Number of employees in quality assurance
Number of employees in admin./operations
Number of employees in other roles
Number of field offices


1.4     Respondent’s Statement of Contractual Disputes, Mergers and Acquisitions, and
        Legal Risks
If any answer is affirmative, Respondent must describe the reasons, its current status and its
outlook for the future.
Yes       No
                  Has the Respondent been declared in default of any contract?
                  Has the Respondent forfeited any payment of performance bond issued
                  by a surety company on any contract?
                  Has an uncompleted contract been assigned by the Respondent's surety
                  company on any payment or performance bond issued to the
                  Respondent arising from the Respondent's failure to fully discharge all
                  contractual obligations thereunder for that contract?
                  Within the past three years, has the Respondent filed for reorganization,
                  protection from creditors or dissolution under bankruptcy statues?
                  Is the Respondent now the subject of any litigation in which an adverse
                  decision might result in a material change in the firm's financial position
                  or future viability?
                  Is the Respondent currently involved in any stage of fact-finding,
                  negotiations or resistance to a merger, friendly acquisition or hostile take-
                  over, either as a target or as a pursuer?


1.5     Corporate Viability and Financial Status
All information provided will be used solely by ILCSO for the purpose of evaluating the financial
viability of the Respondent and will be held in the strictest confidence.
I.5.2   Annual Reports and Financial Statements
                                                                                        Appendix I.4
                                                                                     RFP No.1JLJ505

Provide the two most recent annual reports and two complete sets of audited financial
statements.

1.6       Respondent References

1.6.1     Customer References
Respondent must provide a reference list of at least three installations currently implemented. If
possible, at least one of these should be an academic consortium that has an installation
similar to that required by ILCSO. The respondent certifies that it is empowered to use the
names of references it provides and agrees that ILCSO may contact these references. For each
reference, provide the following information:
      •   Client name
      •   Contact person
      •   Address
      •   Telephone number
      •   E-mail
      •   Services provided
      •   Installation configuration model (e.g., locally hosted, remotely hosted)
      •   Average number of concurrent users
      •   Maximum number of concurrent users
      •   Transaction volume
1.6.2     References of Customers That Cancelled Services or Stopped Implementation
Respondent shall provide information on any clients who have dropped service and/or stopped
implementation of the vendor's product in the last 3 years. The respondent certifies that it is
empowered to use the names of references it provides and agrees that ILCSO may contact
these references. For each reference, please provide the following information:
      •   Client name
      •   Contact person
      •   Address
      •   Telephone number
      •   E-mail address
      •   Reason(s) for service cancellation and/or stopping implementation




                                                                                        Appendix I.5
                                                                                  RFP No.1JLJ505

2       Technical Specifications for Digital Object Management Software

Provide details of how your proposed solution will address each of the following criteria listed
below. If modifications/enhancements must be made to your product to make the proposed
solution meet our requirements, that must be indicated in this technical response, and also
reflected in the appropriate pricing appendix.

2.1     Capturing Objects

2.1.1 Describe system support and typical workflow for capturing and/or describing objects
using qualified and unqualified Dublin Core and/or other standard or locally-defined metadata
schemas. Address all available media types (e.g., discrete objects, a series of related objects, a
structured manuscript containing images and text, bibliographic citations) and any other
multimedia objects. Describe how the system supports relationships between MARC and
individual metadata schemas.

2.1.2 Describe the process by which the capture of objects and corresponding administrative,
descriptive or structural metadata can be automated. Address batch processing, Internet
standards employed for the transfer of objects and metadata across systems, data
communications error reporting, data integrity checking, compression routines, virus checking,
time/date stamping, and other related issues.

2.1.3 Specify any other information the System can automatically record from the capture
process.

2.1.4 Describe the System’s capabilities for importing and manipulating existing metadata
generated by other data capture/storage desktop software programs (e.g., spreadsheet
programs, scanning utilities, database applications). List any known incompatibilities with
existing metadata formats.

2.1.5 Describe the System’s ability to incorporate Optical Character Recognition (OCR) into
the capture process. Indicate what, if any, third party software are used in this process.

2.1.6 Describe the System’s image capture and editing features (e.g., rotate, flip, crop)
including the production and management of derivative files.

2.1.7 Describe the derivative file types that can be produced by your system.            List any
proprietary file types created upon image capture.

2.1.8   Describe the way that the System associates digital object files with metadata records.

2.1.9 Describe the System’s support for digital object watermarking (visible or invisible). Note
any specific standards or schemes used in providing this functionality.

2.2     Metadata

The following section requests information which will describe the System support for metadata
creation, editing and delivery. In the response to sections 6.2.1 – 6.2.4 below, include: 1) how
the specific types of metadata are supported within the System in general; 2) which data are
automatically generated by the System; 3) which data can be automatically generated OR
manually generated; and, 4) which data can ONLY be manually generated. In each case, be
specific as to which metadata standards or schemas are supported by the System.

2.2.1   General
                                                                                      Appendix I.6
                                                                                     RFP No.1JLJ505


1. Describe any templates or other tools that can be used to insure consistency and validity of
   data elements and make data entry processes more efficient. Describe the extent to which
   it is possible to build on these templates to include locally defined fields.

2. Describe any System provisions for staff to edit data from within a table-level view and any
   limits that would be placed on staff with regard to the editing of data (e.g., data must be
   entered using vendor-supplied forms only).

3. Describe the support for performing global updates to the data at the field level (e.g., text
   find/replace functions).

4. Does this System provide for cross-walks or transformations between metadata formats
   (e.g., MARC to Dublin Core)? Describe all schemes for which such mapping is available.

5.   Describe the formats or schemas in which the System stores, searches, and displays
     metadata.

6. Describe any support for the creation and delivery of databases that do not include digital
   objects (e.g., citation-only databases).

2.2.2   Administrative Technical Metadata

1. Describe the System’s abilities to automatically generate, explore and/or record technical
   metadata relating to the characteristics of digital objects. Discuss support for capturing and
   providing metadata about technical characteristics such as file formats and attributes,
   character sets, software requirements for accessing objects, software requirements for
   delivering objects and the System’s process or support for capturing, editing and storing
   technical metadata.

2. Describe any specific technical metadata schemes employed or supported by the System
   that relate to media asset management (e.g., Z39.87-2002 NISO Data Dictionary - Technical
   Metadata for Digital Still Images).

3. Describe the System’s ability to allow for customizing the input of data.

4. Describe the System’s ability to support statistical and auditing requirements.

5. Describe the System’s support for digital rights management languages (e.g., Digital
   Property Rights Language (DPRL), extensible rights Markup Language (XRML).

6. Describe the System’s support for preservation metadata, addressing such issues as the
   control of different versions and/or locations of objects and the storage and/or display of
   derivative and master files (e.g., explain whether the System uses the Open Archives
   Information System Reference Model).

2.2.3   Descriptive Metadata

1. List all descriptive/bibliographic metadata schemas supported by the system ((e.g., MARC,
   Metadata Object Description Schema (MODS), IMS (instructional objects), Content
   Standard for Digital Geospatial Metadata (CSDGM), EAD (Encoded Archival Description),
   Dublin Core (qualified and unqualified)). List known metadata schemas that are not
   supported by the system.

                                                                                        Appendix I.7
                                                                                   RFP No.1JLJ505

2. Describe any support the System has for mapping locally defined descriptive metadata to
   qualified Dublin Core for the purpose of Open Archives Initiative Protocol for Metadata
   Harvesting (OAI-PMH).

3. Describe System support for existing controlled vocabulary tools (e.g., Library of Congress
   Thesaurus for Graphic Materials, The Getty Art and Architecture Thesaurus). Must such
   tools be stored on the System server, or can they be accessed from a remote server?

4. Describe how the System supports the use of locally-defined metadata schemas.

2.2.4   Structural Metadata

Describe all structural metadata (to support complex object presentation and navigation)
supported by the System. List support for any schemes ((e.g., Encoded Archival Description
(EAD), Metadata Encoding and Transcription Standard (METS)).

2.3     Collections and Object Management

2.3.1   Describe how the System handles the definition, creation, storage and retrieval of data
        in:

        1. Logically distinct collections and sub-collections

        2. Logical hierarchies of collections

        3. Virtual collections

2.3.2   Describe System support (storage, retrieval, display) for the following:

        1. Single object in more than one collection (and cross-referencing between records in
        both/all collections)

        2. Sub-collection in more than one collection (and cross-referencing between records in
        both/all collections)

        3. Maintenance of sub-collection as distinct entity within a collection

        4. Describe any restrictions on the number of objects in a single collection

2.3.3   Describe how the System supports, expresses, and controls relationships between
        versions of the same digital object. Describe the control records that are used to
        manage links between different versions and the content of these records.

2.3.4   Object Management

1. Describe how links are maintained between metadata records and digital objects.

2. Describe how the System maintains a reference to copies of content held as offline protection
    copies (e.g., references to a DAT tape).

3. Describe in detail any directory and file-naming conventions required by the System.

2.3.5   Describe how the system handles access to restricted collections.

                                                                                       Appendix I.8
                                                                                    RFP No.1JLJ505

2.4     Long-Term Preservation

2.4.1 Describe the System’s capabilities to migrate/convert digital objects and metadata to
new formats and technologies as hardware and/or software become obsolete. Address such
matters as long-term storage, data integrity and usability of data housed within the System.

2.4.2 Describe how the System provides for the retrieval and delivery of the archived objects,
their associated metadata and any references to the software required to view the said
objects/files.

2.4.3 Describe the System’s use and/or support of the Open Archival Information System
reference model.

2.5     Staff Interface

Describe the staff interface(s) and any required clients or hardware. Provide screen views that
show record layouts, navigation features, search features, creation of objects, and
creation/updating of metadata.

2.6     Patron Interface

2.6.1 Describe all patron interface customization options, including basic and advanced
search screens. Detail all customization options available, including, but not restricted to, field
labels, field choices, sort order, limits, search types, and browsable indexes.

2.6.2 End user training must not be required for successful use of any interface intended for
public use. Provide screen views that show introductory screen(s), search screens, display
screens, help screens, and navigation features.

2.6.3   Describe any System-level functionality that will aid in conducting usability studies.

2.6.4 Explain the System’s help system for users, including context sensitive help. Describe
the degree to which the help system can be customized for local and/or consortial use.

2.6.5 Describe personal services featured in the System. Clearly identify how this functionality
is supported as a component of the DOMS System (e.g., book-shelf, profile, saved searches).

2.7     Indexing

Responses to the following sections will explain the indexing capabilities and options of the
System.

2.7.1 Describe the System’s ability to perform all indexing in real-time as well as staff initiated
index regeneration. Describe the System’s support for reversed inheritance-indexing.

2.7.2 Describe the degree to which the System enables the creation and/or definition of local
indexes. Discuss the degree to which libraries can merge fields into a combined index.
Discuss the degree to which libraries can define which fields are merged in creating the index.

2.7.3 Describe the System’s ability to index full-text data derived from Optical Character
Recognition (OCR).

2.7.4 Describe the System’s support for indexing all non-textual data types (e.g., numerical
and/or date searching, geo-spatial coordinates).
                                                                                        Appendix I.9
                                                                                  RFP No.1JLJ505


2.7.5 Describe the System’s support for the use of stop-words. Describe the extent to which
libraries can edit the list of default terms.

2.7.6 Describe System support for the indexing and retrieval of Unicode metadata by both
staff and public.

2.7.7 Describe the rules used by the System for the normalization of data (e.g., punctuation,
capitalization, stop-words). Describe any specific standards or rules used by the System for
these purposes ((e.g., Anglo-American Cataloguing Rules, 2nd ed (AACR2), Library of
Congress Subject Headings (LCSH), Name Authority Cooperative (NACO)). Explain the extent
to which the libraries can edit these rules.

2.8    Searching

Explain the search and navigation capabilities for both users and staff mode access. If they are
different, clearly define and distinguish each. Discuss the System’s search features for every
type of object supported by the System (e.g., TEI, EAD, audio, video, static images, structured
text documents, multiple images in a series). In addition, attach screen captures of all relevant
search screens.

2.8.1 Describe the System’s support for searching on all non-textual data types (e.g.,
numerical and/or date searching, geo-spatial coordinates).

2.8.2 Describe how the System accommodates the simultaneous searching of disparate
media types and/or metadata schemes in the same or in different collections (e.g., does the
System allow for the simultaneous searching of an EAD finding aid and a set of Dublin Core
records?).

2.8.3 Describe any search features (and their rules) provided for by the System (e.g., phrase
vs. word searching, truncation, adjacency, etc.).

2.8.4 Describe any numeric or non-textual search features (and their rules) provided for in the
System (e.g., numeric, data, geo-spatial).

2.8.5 Describe how search limits are handled by the System. Are limits applied as additional
search criteria or as filters on result sets?

2.8.6 Describe in detail how the System handles search results. Indicate, when applicable,
which options can be modified or customized by individual libraries, or for individual collections:

1. Display options for metadata records, whether as single records or in results sets

2. Sort order options. Describe the degree to which the library can define sort orders and the
    degree to which users can override these default settings

3. Saving and manipulating search histories of retrieved sets

4. Merging and de-duplication of records when searching across multiple collections

5. Explain how records from a results set can be marked/stored for later retrieval or export.
    What formats are available to facilitate the exporting of digital objects and their associated
    metadata to other software programs (e.g., course management tools, citation tools)?

                                                                                        Appendix I.10
                                                                                  RFP No.1JLJ505

2.9       Digital Object Behaviors

Describe System support for behaviors of all digital objects supported by the System. Describe,
for each object type, the level to which it is supported in the System, addressing such issues as:
storage only, display and play controls, version, size limits, number of simultaneous users,
behaviors for viewing, navigating and exporting objects along with their associated metadata.

2.9.1 At a minimum, address the support (or lack thereof) for the following types of digital
objects:

1.    Still images
2.    Encoded Archival Description (EAD)
3.    Encoded text (TEI)
4.    Facsimiles of text (e.g., page images)
5.    Audio
6.    Video
7.    Citations

2.9.2 Explain how users can export retrieved digital objects with their associated metadata.
Describe how the library can specify what levels or types of metadata are exported. Discuss any
capabilities provided for in the System to enable users to export, download or otherwise
incorporate objects and their associated metadata into other systems (e.g., course management
tools or metadata schemes).

2.9.3 Describe any limits (e.g., small, medium, large) on the number of derivatives that can be
displayed for any given object within the System and the manner in which users will navigate
between these relatively-sized objects.

2.10      Linking

Describe how the DOMS supports Open URL linking from citations in the DOMS. Discuss the
System’s ability to allow OpenURL linking to objects stored in the DOMS and cited elsewhere.

2.11      E-Commerce Capabilities

Describe how the System can support e-commerce functionality, or how it can be interfaced to
use external e-commerce software. Identify specific software products that have been
successfully implemented with this System.

2.12      Technical Requirements

Note: When responding to questions about sessions or simultaneous users, please define what
you mean by “session” or “user”.

2.12.1 Architecture and Platforms

1. Describe the architecture of the System in specific terms, including hardware and software
   (including versions) required, and recommended, but optional, add-on software products.
   Include capacity for test and training environments. Descriptions should include a high level
   diagram. Where applicable, provide information on current customers running your software
   in environments similar to the ILCSO technical environment (see 1.4 of the Introduction
   section).


                                                                                     Appendix I.11
                                                                                  RFP No.1JLJ505

2. Specify recommended and possible hardware platforms, including disc subsystem, file
   system options (UFS, VxFS, etc.) and RAID configurations. It is anticipated that the
   hardware will be purchased separately by ILCSO. Indicate if third-party hosting is offered.
   Any associated costs for selecting third-party hosting services should be listed separately in
   the Pricing Proposal.

3.    List all third-party components (e.g., web application server, RDBMS) required by the
     System. Indicate those which may be upgraded independently of System software
     releases, and those which may not.

4. Identify all communication protocols supported by the software, including any private
    extensions. Include any ports which must be dedicated to the System. What secured
    connections are supported for what aspects of the System?

5. List all operating systems (including versions) on which the host System may be run. When
   the software is upgraded, for which operating systems is it first made available?

6. List all operating systems (including versions) supported for client applications used for
   System administration, database maintenance, or user access.

7.    List all web browsers supported including version and operating system.         Include any
     browsers designed for use on handheld devices.

8. Describe in detail how the System can be configured to be used by members at both the
   consortial and local levels for the 65 ILCSO libraries. How many instances of your software
   would be required to accomplish this? Indicate all features or options in the System that
   must be configured system-wide, rather than at the institutional level.

9. Describe the level of support for Unicode. Which UTFs are used or supported? List all
   scripts (e.g., Arabic, Cyrillic, Latin) supported for input and display. Is Unicode data stored,
   indexed, and made available for query and display natively, or is it mapped to a System-
   internal encoding?

2.12.2 Database
1. Describe the database system(s) used for each component of the System.

2. Give the database schema used by the System. Clearly show which aspects of the System,
   for example user accounts, are used by which portion of the schema.

3. Describe the extent to which the System supports SGML/XML data structures for digital
   objects, including:
       a. Hierarchically nested data elements (subfields)
       b. Attributes
       c. Repeating elements
       d. Ordered elements
       e. ID/IDREF linking

4. Describe how metadata is stored (e.g., in RDBMS tables, SGML/XML).

5. Describe the System capabilities for support of persistent identifiers, as well as options for
   using external options such as a Handles server. Describe the System processes for the
   creation, maintenance and reporting functions related to persistent identifiers.


                                                                                      Appendix I.12
                                                                                 RFP No.1JLJ505

6. Describe the application’s logging capabilities and options. What events must be logged, and
   which may optionally be logged? How often can logs be refreshed? What tools are available
   for log scanning or for real-time monitoring for intrusion detection?

2.12.3 Data and Object Storage

1. Identify and discuss all software components and digital objects that are stored by the
   System. Include application data, user data, security data, application logic, program code,
   stored procedures, etc. Describe which of these must be stored within System databases
   and which must be stored outside of System databases. Indicate which are optionally stored
   within or outside of the System.

2. Describe options for storing objects in the System as well as on remote servers for access
   and preservation. Explain options for distributed application and storage servers, and
   indicate the degree to which the System can be scaled for this purpose.

3. Describe how the System supports batch loading of records into existing databases. How do
   these updates impact upon records already in the database?

4. Describe how the System supports the export of metadata in all of its internally supported
   formats.

5. Describe the distributability and scalability of the storage system.

6. Provide recommended space allocation per user for storage of personalized or other user-
   specific data.

7. Describe the System capabilities for insuring the integrity of stored objects including methods
   of validation and any types of reports that the System maintains for this purpose.

2.12.4 Performance and Scalability

1. Provide information about your largest customers, including your largest consortial customer
   and your largest single site customer. Provide information about your largest consortial and
   single site customers operating in a technical environment similar to ILCSO’s (see Section
   1.4 of the Introduction for additional information).

2. Describe how user state or session information is maintained, transmitted, and terminated.
   Describe how the number of concurrent users or sessions is determined, and their effect on
   system and target databases.

3. What, if any, is the limit on the number of concurrent open patron sessions supported by the
   System? What, if any, is the limit on active staff sessions supported by the System? If there
   are limits, describe what happens when either of these limits is reached (e.g., users are
   prevented from starting new sessions).

4. What is the largest number of concurrent open patron sessions experienced by current
   production installations of the software?

5. Does the System use methods for process prioritizing and load balancing? Describe them.

6.   Describe the effects of adjusting the session timeout value on the performance of the
     System. Give a recommendation for the value.

                                                                                     Appendix I.13
                                                                                  RFP No.1JLJ505

7. Describe typical factors that negatively impact system performance either internally (e.g.,
   issues directly related to the product itself as well as its interaction with operating systems
   and hardware platforms) or through network connectivity issues. Describe specific instances
   of the above in which a customer experienced an outage for more than four hours (include
   the identity of the customer, duration of outage, cause, and restoration details).

8. Does the System use methods for process prioritizing and load balancing? If so, describe
   them.

9. Define the scalability and performance benchmarks determined for the System, and provide
   details of the latest benchmark testing

10. For the hardware configurations described in Section 1.4 of the Introduction, list the
   expected time required to retrieve metadata result sets of:

       a. 100
       b. 1,000
       c. 10,000

11. List the hardware requirements for supporting the following numbers of simultaneous users.
    If you are making assumptions about the size of result sets, please state these assumptions.

       a. 500
       b. 2000
       c. unlimited number of users, when timeout is set to 10 minutes

12. List examples of customers who have implemented your product along with federated
    search engine and/or link resolver software from other vendors. Examples should include
    the names of the other products involved, timelines for implementing their interoperation,
    and descriptions and history of any known problems interacting with the named products.

2.12.5 Availability and Maintenance

1. Describe all instances when the System may be unavailable for staff or user access, (e.g.,
   during software updates, database loads, index regens).      Describe how the size of
   databases impacts such required outages.

2. Identify all uses of batch updates, including processes that are scheduled directly with job
   scheduling tools, and processes that are scheduled “behind the scenes” as part of the online
   System.

3. Describe the processes of backup and recovery systemwide and/or per library “instance”.
   For purposes of recovery, describe how backups, in combination with forward recovery from
   transaction logs, can prevent data loss in the event of an unanticipated outage. Indicate if
   backups can be made during normal use of the System. If so, describe how the backups
   are made and include any impacts on performance. Describe whether and how backups
   can be made during normal use of the System, including any impacts on performance.

4. Describe the process for installing a new release of the application. Describe how the
   parameters that control access, authentication, etc., are maintained in a system upgrade
   and what, if any, user modifications might need to be re-entered.

5. Describe performance monitoring tools and options that are used at large customer sites.

                                                                                     Appendix I.14
                                                                                  RFP No.1JLJ505

6. How are software bugs reported and tracked? Describe in detail mechanisms for reporting,
   tracking, and disseminating information on outstanding problems. Who can log problem
   requests? How are these requests tracked?

7. Describe the organization’s support for prior releases.         When does the organization
   discontinue support of a prior release?

8. On average, how often does the company release new versions of the software? On average,
    how often does the company release software patches between releases of new software
    versions? What is the role of customers in testing early releases?

2.12.6 Development Environment

1. Describe all application programming interface (API) or software development kits (SDK)
   available (e.g., for creation of automated import programs and alternative search and
   browse interfaces).

2. Describe any other tools provided for customization of user interfaces or System services.

2.12.7 Integration

1. Indicate how this application could be integrated with each of the other software components
    described in this RFP: Federated Search Software (Appendix II), and Link Resolver
    Software (Appendix III), whether from the same vendor or other vendors. Identify the
    products in each category with which this product has successfully been implemented.
    Provide references of customers, preferably consortia, which have integrated these
    products.

2. Describe ways in which the System can integrate with the following products licensed by
   ILCSO and ILCSO member libraries: Endeavor’s Voyager (specify which versions of the
   Voyager software the System can successfully be integrated with), OCLC’s ILLiad,
   EBSCOhost, FirstSearch, WorldCat, Ovid, and various other bibliographic management
   tools.

3.    Describe how the System supports the Open Archives Initiative Protocol for Metadata
     Harvesting (OAI-PMH) specification as a data provider? As a harvester? With what
     version(s) of OAI-PMH is the System fully compliant for data provider and harvester
     services?

4. Describe how the System implements ANSI/NISO Z39.50 Application Service Definition and
   Protocol Specification. Does it comply with Z39.50 as specified in the Bath Profile, version
   1.1? Describe other Z39.50 services and attributes it supports.

5. Describe the System's support for OpenURL version 1.0.

6. Describe in detail the level of support for the Open Knowledge Initiative (OKI).

7. Describe the system’s interoperability with software being used for web portals at academic
   institutions (e.g., u-Portal, Campus Pipeline Luminis).

8. Describe the System’s interoperability with course management systems (e.g., Blackboard,
  WebCT), including the process for embedding search boxes in course management system
  public interfaces.

                                                                                      Appendix I.15
                                                                                  RFP No.1JLJ505

2.12.8 Security

1. Describe the System's support for network transport encryption (e.g., SSL), either for front-
   end connections to Web interface, or for tunneled connections between application
   components on different hosts.

2. Describe any procedures in place to allow timely detection, notification and remediation of
   security problems.

3. If System components run on different hosts, describe how to identify, change, and secure
   the network routes between them (e.g., to identify and change port numbers for firewall
   configuration).

4. Identify all instances in which System processes require access to (or run as) privileged
   UNIX accounts (e.g., root).

5.    What procedures are in place for secure and monitored vendor access to hosts and
     applications (e.g., ssh, sudo)?

6. Identify any other security controls provided in the System (e.g., checking of user inputs to
   prevent buffer overflow conditions).

2.12.9 System Administration

1.    Describe the system administration module and interface, indicating whether the
      module/interface is a separate client program, a Web interface, etc. The description
      should include, among other features:

        a.   Timeout control
        b.   Access/authorization control
        c.   System parameterization
        d.   Management of metadata indexing
        e.   Collection/database creation

2. Describe how delegated administrators are able to differentiate and secure levels of access
   across the System. Describe how the system administration module itself can be
   segmented to authorize staff to manage certain aspects and only those aspects. Define
   levels of granularity of authorization.

3. Describe how, in a consortium setting, system administration features such as management
   of collections can be delegated to the Consortium member libraries. How many instances of
   which components of the software would be required for each ILCSO library to have its own
   set of search options that is under the library’s control? Is it possible to save redundant
   setup effort for databases/products which multiple ILCSO libraries have in common?

4. Identify the level of technical expertise required to use the system administration application.
    Describe the steps required to perform common system administration tasks, including
    those identified in 6.12.9.1 and 6.12.9.2 above. What software would system administrators
    need to be able to use, what product specific training might they need, and how would they
    receive this training?

5. List necessary and recommendable programming or other technical skills (indicate level) for
   system administrators. What aspects of support require technical application specialists?

                                                                                      Appendix I.16
                                                                                       RFP No.1JLJ505

6. Describe the statistical reporting capabilities of the System. Provide a complete list of all of
   the standard reports. Describe the electronic formats in which the reports can be delivered.
   Describe how the reports can be customized in terms of content and frequency by individual
   institutions in a consortial arrangement. Describe how necessary information and access
   options are provided to allow the development of custom reports through standard tools
   such as Microsoft Access, etc.

2.12.10 Patron Authentication and Access

1.    Explain how the System supports end-user and staff authentication and authorization.
     Include all options supported by the System (e.g., IP wrapping, password/ID, Public/private
     key, certificates, LDAP, Shibboleth). Describe whether the System provides its own
     authentication and access control systems, which external systems it supports, and whether
     this is a configurable option.

2. Once a user has been authenticated, the affiliation and patron type may be known. For each
   target, can we have a distinct login for each type of user (e.g., University of Illinois at
   Urbana-Champaign faculty vs. University of Illinois at Urbana-Champaign undergrads vs.
   Eastern Illinois faculty)?

3. Describe the ability of the System to make authorization decisions based on users’ attributes
   (e.g., student vs. faculty status), including the ability to access external systems (e.g.,
   integrated library system patron database) for those attributes.

4. Describe the ability of the System to support proxy server use for patrons accessing the
   System from outside the campus.

5.    Describe which user transactions occur over secure channels (e.g., network transport
     encryption), and which do not.

6. Describe all instances (e.g., logs, database tables) where specific users are associated with
   specific transactions and access to specific resources. In each case, indicate how long that
   information is retained, and whether and how it can be purged without affecting the
   System’s functionality.

2.12.11 Rights Management

1. Describe how the System manages rights for both owned and licensed material, and how
   this integrates with the authentication and authorization process.

2. Indicate whether the System can define access profiles by:

        a. User roles or other group attributes such as institutional affiliation (if so, describe)
        b. Individual user attributes that override user group attributes
        c. IP ranges

3. Describe the levels at which aggregation access policies can be asserted for:

        a. Collection
        b. Subcollection
        c. Object (or record)
        d. File (for composite digital object)


                                                                                          Appendix I.17
                                                                                       RFP No.1JLJ505

     For example, if a digital object, represented by a single metadata record, consists of several
     separate digital images, how can access to those images be controlled separately?

     4. Describe how access policies are represented in the System. Can the System associate
        digital objects with access or license policies for purposes of access control? If so, describe
        how the linkage occurs.

     5. Does the System provide a license tracking system? If so, describe it.

3.   Implementation

     3.1    Provide a list of sites in production, including consortial sites where applicable, along
            with the number of collections and number of objects.

     3.2    Provide current release/version number(s) and date(s) for the System.

     3.3    Provide an example of a schedule from a recent consortial implementation.

     3.4    What consulting services are included for System installation and implementation?

     3.5    Summarize the roles of the vendor, ILCSO’s consortial office system support staff, and
            ILCSO member library staff during the implementation process.

4.   Training and Other Services

     4.1    Describe the standard training provided with the purchase of this System, including class
            descriptions and training objectives for staff, methods used (e.g., instructor led, distance
            learning, “train-the-trainer”, CBT), locations, and frequency of offerings. Confirm that
            training will be provided in Chicago, Champaign-Urbana, and other sites in the state of
            Illinois to be agreed upon by the successful Proposer and ILCSO.

     4.2    Identify the standard training and any customized training that is available to reflect
            individual institution needs, and include any limitations such as class sizes, locations,
            and time limits. Any additional costs associated with add-on or customized training
            should be listed separately in the Pricing Proposal.

     4.3    Provide a training plan for training 25 system administrators, 50 library staff involved in
            system configuration, and 75 library staff who will use the product as a finding tool.

            1. Describe any training or consulting services that are available at extra cost (e.g., not
            listed as standard training above) and describe how those costs are calculated, including
            trainers’ travel and expenses, if applicable.

            2. Indicate the number of trainers employed by the company.

5.   Technical Support

     5.1    Describe the on-going support available to staff including hot line or toll free numbers,
            day and time availability, and any restrictions. List any web sites used for support
            purposes.

     5.2    Describe how you communicate with users about upcoming changes.


                                                                                          Appendix I.18
                                                                                       RFP No.1JLJ505

    5.3    Describe how requests for software enhancements are handled. Who can log
           enhancement requests for a given customer? How are they tracked? How are priorities
           set for enhancements? What role, if any, does a user group have in this process?

    5.4    Describe how the company performs custom development work for a customer, if
           applicable. Describe generally the principles you might use to develop pricing for custom
           work.

    5.5    Describe the user and technical documentation that is available for the System. Include
           information on documentation that provides:

           1. An overview of the System

           2. Installation/configuration information

           3. System and database administration

           4. Technical information on jobs or modules executed

           5. Data element documentation

           6. Description of tables and views and the relationship of database entities

           7. Context sensitive help

6   Accessibility Issues

    Describe in detail how the System addresses web accessibility issues including a statement of
    the current level of compliance with Section 508, and/or future plans to achieve compliance.

7   Vision, Plans and Distinguishing Features

    7.1    Describe your company’s vision and plans for this offering over the next two years.

    7.2    Describe any planned changes in the product’s functionality or interface.

    7.3    Describe any planned changes in services offered in support of the product.

    7.4    Describe any features of your product (in addition to those referenced in the sections
           above) which distinguish it from its competitors in the marketplace.


8   Licensing

    8.1    Licensing Terms
           List all the licenses that would be required to access the proposed solution. Provide
           those actual license agreements in your response to Appendix I. ALL REQUIRED
           LICENSE AGREEMENTS MUST BE ADDRESSED IN THIS RFP RESPONSE.

    8.2    Third Party Licenses
           List all 3rd party licenses required for any underlying operating systems, databases, or
           other software components necessary to operate systems.


                                                                                          Appendix I.19
                                           RFP No.1JLJ505



                    RFP # JLJ505


                Digital Library Products




                   APPENDIX II



Proposer Information and Functional Specifications

           Federated Search Software
                                                                                    RFP No.1JLJ505

                 ILLINOIS LIBRARY COMPUTER SYSTEMS ORGANIZATION
                        DIGITAL LIBRARY PRODUCTS COMMITTEE

     APPENDIX II – PROPOSER INFORMATION AND FUNCTIONAL SPECIFICATIONS

                              FEDERATED SEARCH SOFTWARE


GENERAL OVERVIEW

The Board of Trustees of the University of Illinois (University) on behalf of the Illinois Library
Computer Systems Organization (ILCSO) seeks to license Federated Search Engine software
capable of simultaneously searching multiple electronic resources and providing consolidated,
de-duplicated, and organized sets of results. Such systems are also known as cross-domain
search engines, one-search systems, or metasearch systems.

ILCSO is a consortium of 65 Illinois academic libraries, serving over 600,000 students and
faculty. ILCSO members freely share access to their resources, and operate a shared online
integrated library system. ILCSO’s online union catalog, ILLINET Online, currently contains over
8 million bibliographic records for nearly 30 million holdings.

Care should be taken to address all questions related to the integration of the Proposer’s
products with the existing elements of the ILCSO environment (integrated library system,
information resources, etc.) and the other components sought in this RFP (DOMS, Federated
Search, and Link Resolver). The Proposer must clearly state and describe how the Federated
Search product will accomplish this integration.

ILCSO TECHNICAL ENVIRONMENT

See Section 1.4 of the Introduction for a complete description of ILCSO’s technical
infrastructure and capacities. Appendix VII of this RFP provides schematic diagrams of the
ILCSO environment.

IMPLEMENTATION

ILCSO anticipates a phased implementation of the selected federated search engine product(s).
Representative ILCSO member libraries will be selected in the Fall of 2004 to participate in a
Phase I implementation. In consultation with the successful Proposer, an implementation plan
will be developed, with July 2005 as the anticipated target to make the federated search
software available to the students and faculty of participating libraries (see Section 1.6 of the
Introduction for more information).

PRICING

Proposers must submit a response for each attachment of Appendix IV, V and VI. If you do not
wish to propose a solution for a particular model, indicate “no” to the first question listed on each
attachment form, “Are you offering pricing for this model?” and sign the document.

Where applicable, ILCSO prefers that the license or subscription allow ILCSO to use as many
instances of the software as might be needed to properly serve authorized ILCSO libraries.
This could enable ILCSO libraries to explore various alternative configurations. One library
might have its own separate instance of one of the software modules, where a group of libraries
might conceivably share another instance. A library might maintain its own instance of a

                                                                                       Appendix II. 1
                                                                               RFP No.1JLJ505

module on its own server, or choose to have ILCSO maintain it on an ILCSO server, or have the
software run on a Proposer’s server. ILCSO will consider all proposed configuration models.
Appendix IV, V, VI of this RFP contains additional information on submitting pricing models.

EVALUATION PROCESS

Evaluation of the Responses this RFP for federated search software will be conducted by a
team comprising staff of the University of Illinois Office for Planning and Budgeting and ILCSO
member libraries. See Section 3.7 of the Introduction for additional information.




                                                                                  Appendix II. 2
                                                                                    RFP No.1JLJ505

                              FEDERATED SEARCH SOFTWARE

This Appendix II and Proposer’s response to it will be incorporated into the final Contract.

Note: Proposer shall state the name of the product being bid in this section, and describe the
most current version in use by customers. Proposer shall state whether this service will be
Proposer hosted or Customer hosted. If more than one version of the same software
component is offered by the Proposer, a separate set of functional specifications must be
submitted for each software version.

Different configurations of a product must individually and completely address all of the
technical specifications listed and must provide a clearly labeled price quotation for each
specific configuration (see Section 2.2.2 of the Introduction section for additional information).

Responses must be provided in both hard copy and as an electronic document submitted via
email, email attachment, diskette, or CD-Rom in MS Word.
To provide uniformity and to facilitate comparison of Proposals, all information submitted must
clearly refer to the page number, section, or other identifying reference in this RFP.            All
information submitted must be noted in the same sequence as its appearance in this RFP. Only
graphical figures may appear at the end of the responses and they must be clearly numbered
and referenced in the text of the response. It is not the responsibility of the University to search
through the RFP response or long appendices to locate relevant information that may answer
the questions listed below. Such responses may be considered “Non-responsive”.


1.      Respondent Corporate Information
1.1     Contact Personnel
Fill in the requested information for the following personnel:

            Primary Contact Person (if different     Person Authorized to Negotiate and
            from Respondent)                         Make Commitment for Respondent
Name
Title
Address
Address
Phone
800
Fax
Email
Signature


1.2     Organization Chart of Key Personnel
Provide a current organization chart for your company

1.3     Respondent Demographics


                                                                                       Appendix II. 3
                                                                                    RFP No.1JLJ505

Year of incorporation/business registration


Human Resource Distribution by Function             Total Corporation
Total number of employees
Number of employees in sales & marketing
Number of employees in client support
Number of employees in consulting services
Number of employees in research and
development
Number of employees in quality assurance
Number of employees in admin./operations
Number of employees in other roles
Number of field offices


1.4    Respondent’s Statement of Contractual Disputes, Mergers and Acquisitions, and
       Legal Risks

If any answer is affirmative, Respondent must describe the reasons, its current status and its
outlook for the future.
Yes       No
                  Has the Respondent been declared in default of any contract?
                  Has the Respondent forfeited any payment of performance bond issued
                  by a surety company on any contract?
                  Has an uncompleted contract been assigned by the Respondent's surety
                  company on any payment or performance bond issued to the
                  Respondent arising from the Respondent's failure to fully discharge all
                  contractual obligations thereunder for that contract?
                  Within the past three years, has the Respondent filed for reorganization,
                  protection from creditors or dissolution under bankruptcy statues?
                  Is the Respondent now the subject of any litigation in which an adverse
                  decision might result in a material change in the firm's financial position
                  or future viability?
                  Is the Respondent currently involved in any stage of fact-finding,
                  negotiations or resistance to a merger, friendly acquisition or hostile take-
                  over, either as a target or as a pursuer?


1.5    Corporate Viability and Financial Status
All information provided will be used solely by ILCSO for the purpose of evaluating the financial
viability of the Respondent and will be held in the strictest confidence.
Provide the two most recent annual reports and two complete sets of audited financial
statements.

                                                                                       Appendix II. 4
                                                                                     RFP No.1JLJ505


1.6       Respondent References
1.6.1     Customer References
Respondent must provide a reference list of at least three installations currently implemented. If
possible, at least one of these should be an academic consortium that has an installation
similar to that required by ILCSO. The respondent certifies that it is empowered to use the
names of references it provides and agrees that ILCSO may contact these references. For each
reference, provide the following information:
      •   Client name
      •   Contact person
      •   Address
      •   Telephone number
      •   E-mail
      •   Services provided
      •   Installation configuration model (e.g., locally hosted, remotely hosted)
      •   Average number of concurrent users
      •   Maximum number of concurrent users
      •   Transaction volume
1.6.2     References of Customers That Cancelled Services or Stopped Implementation
Respondent shall provide information on any clients who have dropped service and/or stopped
implementation of the vendor's product in the last 3 years. The respondent certifies that it is
empowered to use the names of references it provides and agrees that ILCSO may contact
these references. For each reference, please provide the following information:
      •   Client name
      •   Contact person
      •   Address
      •   Telephone number
      •   E-mail address
      •   Reason(s) for service cancellation and/or stopping implementation




                                                                                       Appendix II. 5
                                                                                    RFP No.1JLJ505

2       Technical Specifications for Federated Search Software

This section describes a System that allows library patrons to search multiple
databases/sources simultaneously using a single interface and displaying results in a variety of
formats. This capability is also known as “broadcast search”, “federated search”, “unified
search interface”, “metasearch” and others.

Provide details of how your proposed solution will address each of the following criteria listed
below. If modifications/enhancements must be made to your product to make the proposed
solution meet our requirements, that must be indicated in this technical response and also
reflected in the appropriate pricing appendix.

2.1     Databases/Sources

2.1.1 Describe in detail the databases/sources available for broadcast searching, the
configurations and capabilities of the search engine, and the options for local administration
thereof.

2.1.2 List number and names of vendors and databases/sources for which translators are
provided for broadcast searching in initial installation (provide full list).

2.1.3 Describe types of databases/sources that can be searched (e.g., MARC/bibliographic;
abstracting/indexing database; digital text/full-text, images, video, and audio content; citations in
journal articles and other electronic text).

2.1.4 Describe types of databases/sources that cannot be searched via the broadcast search
interface.

2.1.5 Describe types of protocols that are supported: (e.g., Z39.50, HTTP, SQL, XML,
OpenURL and any others).

2.1.6 Describe limitations on number of databases/sources that can be searched
simultaneously.

2.2     Search Functions

2.2.1 Describe in detail the capabilities of the System to perform concurrent/simultaneous
broadcast searching of multiple databases/sources. Describe how the System deals with
differences in indexing practices across databases/sources.

2.2.2 List types of indexes searched (e.g., metadata (author, title, subject descriptors); full text
of documents).

2.2.3   List types of searches available (e.g., keyword, browse).

2.2.4 List types of search qualifiers available (e.g., Boolean operators, proximity operators,
phrase searching, left-anchored, truncation).

2.2.5 List types of search limits available by field (e.g., author, title, descriptor; date, date
range, ISBN, ISSN).

2.3     Search Interface


                                                                                       Appendix II. 6
                                                                                   RFP No.1JLJ505

2.3.1 Describe in detail the interface and the capabilities of the System to provide various
options for searching, navigation and local customization.

2.3.2 Provide information on the ability for library patrons to select which databases/sources to
search.

2.3.3 Provide information on the ability to               offer   pre-configured   collections   of
databases/sources (e.g., by subject) for searching.

2.3.4   Describe the ability to provide options for both simple and advanced searching.

2.3.5 Describe the ability for library patron to save search queries and re-run at a later time or
have the search automatically re-run on a specified schedule with results sent to user.

2.3.6 Describe the ability to customize the search interface page (e.g., colors, fonts, graphics,
placement of elements).

2.3.7   Describe the ability to support local branding.

2.4     Results List Display

2.4.1 Describe in detail the capabilities of the System to display the results of broadcast
searches.

2.4.2 Describe options for library patrons to sort and save results according to selectable
criteria (e.g., relevance-ranked, author, title, year, by database/source.)

2.4.3 Describe options for library patrons to group results according to selectable criteria (e.g.,
integrated vs. separate by database/source, format, date of publication, type of material).

2.4.4 Describe ability to "pre-search" databases/sources: retrieve only the number of hits for
the term in each database, rather than immediately seeing the records; enable user to select
databases/sources for further searching based on this information.

2.4.5 Describe how non-responsive databases/sources are handled. What message(s) is
displayed? Can this message be customized at the consortial or the institutional level?

2.4.6 Describe how a patron moves to the native interface (including how authentication is
handled at this point) and returns from the results.

2.4.7 Describe ability to merge results from several databases/sources and to eliminate
duplicates from the merged results. What criteria can be used for de-duplication and in what
combinations or weighting can these criteria be used?

2.5     Record and Digital Object Displays

2.5.1 Describe in detail the capabilities of the System to display records for the items retrieved
through broadcast searches and the digital objects associated with the records.

2.5.2   Describe options for record displays.

2.5.3 Describe types of display formats supported (e.g., ASCII text, PDF, GIF, JPG, MPEG,
RTF, HTML, XHTML, sound, image, video, Microsoft Excel and other data storage file types).

                                                                                      Appendix II. 7
                                                                                     RFP No.1JLJ505

2.5.4 Describe indications of availability and "how to get" the digital object associated with a
record.

2.5.5 Describe ability to initiate a borrowing request for non-digital materials directly from the
search results display, and demonstrate how this works with Endeavor Voyager Universal
Borrowing.

2.5.6    Describe how the system determines relevance rankings.

2.6      Email/Print/Download/Export

2.6.1    Describe how library patrons can keep a copy of their searches and search results.

2.6.2    Provide information on the ability to email, print, and download to disk.

2.6.3 Provide information on compatibility of System with bibliographic software (e.g., ProCite,
EndNote, etc).

2.7      Personal Customization

Describe in detail how library patrons can customize or set preferences for the search, retrieve
and display functions. Identify which preferences are limited to a single session and which can
be saved for use in later sessions.

2.8      Help Functions

Describe the help functions available to assist library patrons. To what degree are the help
functions context-sensitive?

2.9      Additional Functionality

Describe in detail any additional functionality that the software/services provide. Explain why
this functionality is important to such a System.

2.10     Technical Requirements

Note: When responding to questions about sessions or simultaneous users, please define what
you mean by “session” or “user”.

2.10.1 Architecture and Platforms

1. Describe the architecture of the System in specific terms, including hardware and software
   (including versions) required, and recommended, but optional, add-on software products.
   Include capacity for test and training environments. Descriptions should include a high level
   diagram. Where applicable, provide information on current customers running your software
   in environments similar to the ILCSO technical environment (see Section 1.4 of the
   Introduction).

2.     Specify recommended and possible hardware platforms, including disc subsystem, file
      system options (UFS, VxFS, etc.) and RAID configurations. It is anticipated that the
      hardware will be purchased separately by ILCSO. State if third-party hosting is offered. Any
      associated costs for selecting third-party hosting services should be listed separately in the
      Pricing Proposal.

                                                                                       Appendix II. 8
                                                                                  RFP No.1JLJ505

3. List all third-party components (e.g., web application server, RDBMS) required by the
   System. Indicate those which may be upgraded independently of System software
   releases, and those which may not.

4. Identify all communication protocols supported by the software, including any private
    extensions. Include any ports which must be dedicated to the System. What secured
    connections are supported for what aspects of the System?

5. List all operating systems (including versions) on which the host System may be run. When
   the software is upgraded, for which operating systems is it first made available?

6. List all operating systems (including versions) supported for client applications used for
   System administration, database maintenance, or user access.

7.    List all web browsers supported including version and operating system.         Include any
     browsers designed for use on handheld devices.

8. Describe in detail how the System can be configured to be used by members at both the
   consortial and local levels for the 65 ILCSO libraries. How many instances of your software
   would be required to accomplish this? Indicate all features or options in the System that
   must be configured system-wide, rather than at the institutional level.

9. Describe the level of support for Unicode. Which UTFs are used or supported? List all
   scripts (e.g., Arabic, Cyrillic, Latin) supported for input and display. Is Unicode data stored,
   indexed, and made available for query and display natively, or is it mapped to a System-
   internal encoding?

2.10.2 Database

1. Describe the database system(s) used for each component of the System.

2. Give the database schema used by the System. Clearly show which aspects of the System,
   for example user accounts, are used by which portion of the schema.

3. Describe the application’s logging capabilities and options. What events must be logged,
   and which may optionally be logged? How often can logs be refreshed? What tools are
   available for log scanning or for real-time monitoring for intrusion detection?

2.10.3 Data and Object Storage

1. Identify and discuss all components and objects that are stored by the System. Include
   application data, user data, security data, application logic, program code, stored
   procedures, and so on. Describe which of these must be stored within System databases
   and which must be stored outside of System databases. Indicate which are optionally stored
   within or outside of the System.

2. Describe the distributability and scalability of the storage system.

3. Provide recommended space allocation per user for storage of personalized or other user-
   specific data.

2.10.4 Performance and Scalability


                                                                                      Appendix II. 9
                                                                                  RFP No.1JLJ505

1. Provide information about your largest customers, including your largest consortial customer
   and your largest single site customer. Provide information about your largest consortial and
   single site customers operating in a technical environment similar to ILCSO’s (see Section
   1.4 of this Appendix).

2. Describe how user state or session information is maintained, transmitted, and terminated.
   Describe how the number of concurrent users or sessions is determined, and their effect on
   system and target databases.

3. What, if any, is the limit on the number of concurrent open patron sessions supported by the
   System? What, if any, is the limit on active staff sessions supported by the System? If
   there are limits, describe what happens when either of these limits is reached (e.g., users
   are prevented from starting new sessions).

4. What is the largest number of concurrent open patron sessions experienced by current
   production installations of the software?

5. Describe how the System handles concurrent user limits associated with some licensed
   databases.

6.   Describe the effects of adjusting the session timeout value on the performance of the
     System? Give a recommendation for the value.

7. Describe typical factors that negatively impact system performance either internally (e.g.,
   issues directly related to the product itself as well as its interaction with operating systems
   and hardware platforms) or through network connectivity issues. Describe specific
   instances of the above in which a customer experienced an outage for more than four hours
   (include the identity of the customer, duration of outage, cause, and restoration details).

8. Does the System use methods for process prioritizing and load balancing? If so, describe
   them.

9. Define the scalability and performance benchmarks determined for the System, and provide
   details of the latest benchmark testing

10. For the hardware configurations described in Section 1.4 of the Introduction, what is the
    expected time required to retrieve metadata result sets of:

        a.     100
        b.     1,000
        c.     10,000

11. List the hardware requirements for supporting the following numbers of simultaneous users,
     assuming each user is searching five targets (if you are making assumptions about the
     size of result sets, state these assumptions):

      a.       500
      b.       2,000
      c.       unlimited number of users, when timeout is set to 10 minutes

12. List examples of customers who have implemented your product along with link resolver
    and/or digital collection management software from other vendors. Examples should
    include the names of the other products involved, timelines for implementing their

                                                                                    Appendix II. 10
                                                                                RFP No.1JLJ505

     interoperation, and descriptions and history of any known problems interacting with the
     named products.

2.10.5 Availability and Maintenance

1. Describe all instances when the System may be unavailable for staff or user access, (e.g.,
   during software updates, database loads, index regens). Describe how the size of
   databases impacts such required outages.

2. Identify all uses of batch updates, including processes that are scheduled directly with job
   scheduling tools, and processes that are scheduled “behind the scenes” as part of the online
   System.

3. Describe the processes of backup and recovery systemwide and/or per library “instance”.
   For purposes of recovery, describe how backups, in combination with forward recovery from
   transaction logs, can prevent data loss in the event of an unanticipated outage. Describe
   whether and how backups can be made during normal use of the System, including any
   impacts on performance.

4. Describe the process for installing a new release of the application. Describe how the
   parameters that control access, authentication, etc., are maintained in a system upgrade
   and what, if any, user modifications might need to be re-entered.

5. Describe performance monitoring tools and options that are used at large customer sites.

6. How are software bugs reported and tracked? Describe in detail mechanisms for reporting,
   tracking, and disseminating information on outstanding problems. Who can log problem
   requests? How are these requests tracked?

7. Describe the organization’s support for prior releases.       When does the organization
   discontinue support of a prior release?

8. On average, how often does the company release new versions of the software? On average,
    how often does the company release software patches between releases of new software
    versions? What is the role of customers in testing early releases?

2.10.6 Development Environment

1. Describe all application programming interfaces (API) or software development kits (SDK)
   available (e.g., for creation of automated import programs and alternative search and
   browse interfaces).

2. Describe any other tools provided for customization of user interfaces or System services.

2.10.7 Integration

1. Indicate how this application could be integrated with each of the other software components
    described in this RFP: Digital Object Management System (Appendix I) and Link Resolvers
    (Appendix III) whether from the same vendor or other vendors. Identify the products in each
    category with which this product has successfully been implemented. Provide references of
    customers, preferably consortia, which have integrated these products.

2. Describe ways in which the System can integrate with the following products licensed by
   ILCSO and ILCSO member libraries: Endeavor’s Voyager (specify which versions of the
                                                                                  Appendix II. 11
                                                                                 RFP No.1JLJ505

     Voyager software the System can successfully be integrated with), OCLC’s ILLiad,
     EBSCOhost, FirstSearch, WorldCat, Ovid, and various other bibliographic management
     tools.

3. Does the System support the Open Archives Initiative Protocol for Metadata Harvesting
   (OAI-PMH) specification as a data provider? As a harvester? With what version(s) of OAI-
   PMH is the System fully compliant for data provider and harvester services?

4. Does the System implement ANSI/NISO Z39.50 Application Service Definition and Protocol
   Specification? Does it comply with Z39.50 as specified in the Bath Profile, version 1.1?
   What other Z39.50 services and attributes does it support?

5. Describe the System's support for OpenURL version 1.0.

6. Describe the system’s interoperability with software being used for web portals at academic
   institutions (e.g., u-Portal, Campus Pipeline Luminis).

7. Indicate other typical applications or services with which this application can integrate or
   interface, including serials management software (e.g., TDNet, Serials Solutions) and
   course management systems (e.g., Blackboard, WebCT), including the process for
   embedding a search box in course management systems.

2.10.8 Security

1. Describe the System's support for network transport encryption (e.g., SSL), either for front-
   end connections to Web interface, or for tunneled connections between application
   components on different hosts.

2. Describe any procedures in place to allow timely detection, notification and remediation of
   security problems.

3. If System components run on different hosts, describe how to identify, change, and secure
   the network routes between them (e.g., to identify and change port numbers for firewall
   configuration).

4. Identify all instances in which System processes require access to (or run as) privileged
   UNIX accounts (e.g., root).

5.    What procedures are in place for secure and monitored vendor access to hosts and
     applications (e.g., ssh, sudo)?

6. Identify any other security controls provided in the System, (e.g., checking of user inputs to
   prevent buffer overflow conditions).

2.10.9 System Administration

1.    Describe the system administration module and interface, including whether the
      module/interface is a separate client program, a Web interface, etc. The description
      should include, among other features:

           a. Timeout control
           b. Access/authorization control
           c. System parameterization
           d. Management of metadata indexing
                                                                                   Appendix II. 12
                                                                                  RFP No.1JLJ505

           e. Collection/database creation
           f. Parameters for retrieval (e.g., limits on result sizes, etc.)

2. Describe how delegated administrators are able to differentiate and secure levels of access
   across the System. Describe how the system administration module itself can be
   segmented, to authorize staff to manage certain aspects and only those aspects. Define
   levels of granularity of authorization.

3. Describe how, in a consortium setting, system administration features such as management
   of collections can be delegated to the Consortium member libraries. How many instances of
   which components of the software would be required for each ILCSO library to have its own
   set of search options that is under the library’s control? Is it possible to save redundant
   setup effort for databases/products which multiple ILCSO libraries have in common? For
   example, if three libraries have ten database subscriptions in common, would it be possible
   for one library to do setup work for these ten databases, the other two libraries simply
   copying that information into their own respective administrative modules?

4. Identify the level of technical expertise required to use the system administration application.
    Describe the steps required to perform common system administration tasks, including
    those identified in 7.10.9.1 and 7.10.9.2 above. What software would system administrators
    need to be able to use, what product specific training might they need, and how would they
    receive this training?

5. List necessary and recommendable programming or other technical skills (indicate level) for
   system administrators. What aspects of support require technical application specialists?

6. Describe the statistical reporting capabilities of the System. Provide a complete list of all of
   the standard reports. Describe the electronic formats the reports can be delivered in.
   Describe how the reports can be customized in terms of content and frequency by individual
   institutions in a consortial arrangement. Describe how necessary information and access
   options are provided to allow the development of custom reports through standard tools
   such as Microsoft Access, etc.

2.10.10 Patron Authentication and Access

1. Explain how the System supports end-user and staff authentication and authorization.
   Include all options supported by the System, (e.g., IP wrapping, password/ID, Public/private
   key, certificates, LDAP, Shibboleth). Describe whether the System provides its own
   authentication and access control systems, which external systems it supports, and whether
   this is a configurable option.

2. Once a user has been authenticated, the affiliation and patron type may be known. For each
   target, can we have a distinct login for each type of user (e.g., University of Illinois at
   Urbana-Champaign vs. University of Illinois at Urbana-Champaign undergraduates vs.
   Eastern Illinois University faculty)?

3. Describe the ability of the System to make authorization decisions based on users’ attributes
   (e.g., student vs. faculty status), including the ability to access external systems (e.g.,
   integrated library system patron database) for those attributes.

4. Describe the ability of the System to support proxy server use for patrons accessing the
   System from outside the campus.


                                                                                    Appendix II. 13
                                                                                           RFP No.1JLJ505

    5.     Describe which user transactions occur over secure channels (e.g., network transport
          encryption), and which do not.

    6. Describe all instances (e.g., logs, database tables) where specific users are associated with
       specific transactions and access to specific resources. In each case, indicate how long that
       information is retained, and whether and how it can be purged without affecting the
       System’s functionality.

    2.10.11 Rights Management

    1. Describe how the System manages rights for both owned and licensed material, and how
       this integrates with the authentication and authorization process.

    2. Indicate whether the System can define access profiles by:

          a. User roles or other group attributes (e.g., institutional affiliation)
          a. Individual user attributes that override user group attributes
          b. IP ranges

    3. Does the System provide a license tracking system? If so, describe it.

3   Implementation

    3.1       Provide a list of sites in production, including consortial sites where applicable.

    3.2       Provide current release/version number(s) and date(s) for the System.

    3.3       Provide an example of a schedule from a recent consortial implementation.

    3.4       What consulting services are included for System installation, and implementation?

    3.5       Summarize the roles of the vendor, ILCSO’s consortial office system support staff, and
              ILCSO member library staff during the implementation process.

4   Training and Other Services

    4.1     Describe the standard training provided with the purchase of this System, including class
    descriptions and training objectives for staff, methods used (e.g., instructor led, distance
    learning, “train-the-trainer”, CBT), locations, and frequency of offerings. Confirm that training
    will be provided in Chicago, Champaign-Urbana, and other sites in the state of Illinois to be
    agreed upon by the successful Proposer and ILCSO.

    4.2     Identify the standard training and any customized training that is available to reflect
    individual institution needs, and include any limitations such as class sizes, locations, and time
    limits. Any additional costs associated with add-on or customized training should be listed
    separately in the Pricing Proposal.

    4.3   Provide a training plan for training 25 system administrators, 50 library staff involved in
    system configuration, and 75 library staff who will use the product as a finding tool.

    4.4     Describe any training or consulting services that are available at extra cost (e.g., not
    listed as standard training above), and describe how those costs are calculated. Include
    trainers’ travel and expenses, if applicable.

                                                                                             Appendix II. 14
                                                                                       RFP No.1JLJ505

    4.5    Indicate the number of trainers employed by the company.

    4.6    Describe the consulting services offered for typical types of work.

5   Technical Support

    5.1   Describe the on-going support available to staff, including hot line or toll free numbers,
    day and time availability, and any restrictions. List any web sites used for support purposes.

    5.2    Describe the methodologies and tools used for testing new software versions prior to
    release.

    5.3    Describe how you communicate with users about upcoming changes.

    5.4   Describe how requests for software enhancements are handled. Who can log
    enhancement requests for a given customer? How are they tracked? How are priorities set for
    enhancements? What role, if any, does a user group have in this process?

    5.5    Describe how the company performs custom development work for a customer, if
    applicable. Describe generally the principles you might use to develop pricing for custom work.

    5.6    Describe the user and technical documentation that is available for the System. Include
           information on documentation that provides:

           1. An overview of the System

           2. Installation/configuration information

           3. System and database administration

           4. Technical information on jobs or modules executed

           5. Data element documentation

           6. Description of tables and views and the relationship of database entities

           7. Context sensitive help

6   Accessibility Issues

    Describe in detail how the System addresses web accessibility issues including a statement of
    the current level of compliance with Section 508, and/or future plans to achieve compliance.

7   Vision, Plans and Distinguishing Features

    Describe your company’s vision and plans for this offering over the next two years:

    7.1    Describe any planned changes in the product’s functionality or interface.

    7.2    Describe any planned changes in services offered in support of the product.

    7.3    Describe any features of your product (in addition to those referenced in the sections
    above) which distinguish it from its competitors in the marketplace.

                                                                                          Appendix II. 15
                                                                                      RFP No.1JLJ505

8   Licensing

    8.1    Licensing Terms

    List all the licenses that would be required to access the proposed solution. Provide those
    actual license agreements in your response to Appendix II. ALL REQUIRED LICENSE
    AGREEMENTS MUST BE ADDRESSED IN THIS RFP RESPONSE.

    8.2    Third Party Licenses

    List all 3rd party licenses required for any underlying operating systems, databases, or other
    software components necessary to operate systems.




                                                                                        Appendix II. 16
                                           RFP No.1JLJ505



                    RFP # JLJ505


                Digital Library Products




                   APPENDIX III



Proposer Information and Functional Specifications

              Link Resolver Software
                                                                                    RFP No.1JLJ505

                  ILLINOIS LIBRARY COMPUTER SYSTEMS ORGANIZATION
                        DIGITAL LIBRARY PRODUCTS COMMITTEE

     APPENDIX III – PROPOSER INFORMATION AND FUNCTIONAL SPECIFICATIONS
                           LINK RESOLVER SOFTWARE


GENERAL OVERVIEW

The Board of Trustees of the University of Illinois (University) on behalf of the Illinois Library
Computer Systems Organization (ILCSO) seeks to license a link resolver capable of linking
citations from electronic abstracting and indexing databases, an integrated library system, or
other searching tool to a library’s licensed, full text electronic resources, regardless of the
provider of either the citation or full text resource.

ILCSO is a consortium of 65 Illinois academic libraries, serving over 600,000 students and
faculty. ILCSO members freely share access to their resources, and operate a shared online
integrated library system. ILCSO’s online union catalog, ILLINET Online, currently contains
over 8 million bibliographic records for nearly 30 million holdings.

Care should be taken to address all questions related to the integration of the Proposer’s
products with the existing elements of the ILCSO environment (integrated library system,
information resources, etc.) and the other components sought in this RFP (DOMS and
Federated Search). The Proposer must clearly state and describe how the link resolver
software product will accomplish this integration.

ILCSO TECHNICAL ENVIRONMENT

See Section 1.4 of the Introduction for a complete description of ILCSO’s technical
infrastructure and capacities. Appendix VII of this RFP provides schematic diagrams of the
ILCSO environment.

IMPLEMENTATION

ILCSO anticipates a phased implementation of the selected link resolver product.
Representative ILCSO member libraries will be selected in the Fall of 2004 to participate in a
Phase I implementation. In consultation with the successful Proposer, an implementation plan
will be developed, with July 2005 as the anticipated target to make the link resolver software
available to the students and faculty of participating libraries (see Section 1.6 of the Introduction
for more information).

PRICING

Proposers must submit a response for each attachment of Appendix IV, V, and VI. If you do not
wish to propose a solution for a particular model, indicate “no” to the first question listed on each
attachment form, “Are you offering pricing for this model?” and sign the document.

Where applicable, ILCSO prefers that the license or subscription allow ILCSO to use as many
instances of the software as might be needed to properly serve authorized ILCSO libraries.
This could enable ILCSO libraries to explore various alternative configurations. One library
might have its own separate instance of one of the software modules, where a group of libraries
might conceivably share another instance. A library might maintain its own instance of a
module on its own server, or choose to have ILCSO maintain it on an ILCSO server, or have the

                                                                                       Appendix III. 1
                                                                               RFP No.1JLJ505

software run on a Proposer’s server. ILCSO will consider all proposed configuration models.
Appendix IV, V, VI of this RFP contains additional information on submitting pricing models.

EVALUATION PROCESS

Evaluation of the Responses this RFP for link resolver software will be conducted by a team
comprising staff of the University of Illinois Office for Planning and Budgeting and ILCSO
member libraries. See Section 3.7 of the Introduction section for additional information on the
evaluation process.




                                                                                  Appendix III. 2
                                                                                    RFP No.1JLJ505


                                 LINK RESOLVER SOFTWARE

This Appendix III and Proposer’s response to it will be incorporated into the final Contract.

Note: Proposer shall state the name of the product being bid in this section, and describe the
most current version in use by customers. If more than one version of the same software
component is offered by the Proposer, a separate set of functional specifications must be
submitted for each software version. Proposer shall state whether this service will be Proposer
hosted or Customer hosted.

Different configurations of a product must individually and completely address all of the
technical specifications listed below and must provide a clearly labeled price quotation for each
specific configuration in the appropriate price Appendix (see Section 2.2.2 for additional
information on submitting pricing).
Responses must be provided in both hard copy and on diskette or CD-ROM in Microsoft Word.
To provide uniformity and to facilitate comparison of Proposals, all information submitted must
clearly refer to the page number, section, or other identifying reference in this RFP.            All
information submitted must be noted in the same sequence as its appearance in this RFP. Only
graphical figures may appear at the end of the responses and they must be clearly numbered
and referenced in the text of the response. It is not the responsibility of the University to search
through the RFP response or long appendices to locate relevant information that may answer
the questions listed below. Such responses may be considered “Non-responsive”.

1.      Respondent Corporate Information
1.1     Contact Personnel
Fill in the requested information for the following personnel:
            Primary Contact Person (if different     Person Authorized to Negotiate and
            from Respondent)                         Make Commitment for Respondent
Name
Title
Address
Address
Phone
800
Fax
Email
Signature


1.2     Organization Chart of Key Personnel
Provide a current organization chart for your company
1.3     Respondent Demographics
Year of incorporation/business registration


                                                                                       Appendix III. 3
                                                                                    RFP No.1JLJ505

Human Resource Distribution by Function             Total Corporation
Total number of employees
Number of employees in sales & marketing
Number of employees in client support
Number of employees in consulting services
Number of employees in research and
development
Number of employees in quality assurance
Number of employees in admin./operations
Number of employees in other roles
Number of field offices


1.4    Respondent’s Statement of Contractual Disputes, Mergers and Acquisitions, and
Legal Risks

If any answer is affirmative, Respondent must describe the reasons, its current status and its
outlook for the future.
Yes       No
                  Has the Respondent been declared in default of any contract?
                  Has the Respondent forfeited any payment of performance bond issued
                  by a surety company on any contract?
                  Has an uncompleted contract been assigned by the Respondent's surety
                  company on any payment or performance bond issued to the
                  Respondent arising from the Respondent's failure to fully discharge all
                  contractual obligations thereunder for that contract?
                  Within the past three years, has the Respondent filed for reorganization,
                  protection from creditors or dissolution under bankruptcy statues?
                  Is the Respondent now the subject of any litigation in which an adverse
                  decision might result in a material change in the firm's financial position
                  or future viability?
                  Is the Respondent currently involved in any stage of fact-finding,
                  negotiations or resistance to a merger, friendly acquisition or hostile take-
                  over, either as a target or as a pursuer?


1.5     Corporate Viability and Financial Status
All information provided will be used solely by ILCSO for the purpose of evaluating the financial
viability of the Respondent and will be held in the strictest confidence.
Provide the two most recent annual reports and two complete sets of audited financial
statements.

1.6     Respondent References
1.6.1   Customer References
                                                                                      Appendix III. 4
                                                                                   RFP No.1JLJ505

Respondent must provide a reference list of at least three installations currently implemented. If
possible, at least one of these should be an academic consortium that has an installation
similar to that required by ILCSO. The respondent certifies that it is empowered to use the
names of references it provides and agrees that ILCSO may contact these references. For each
reference, provide the following information:
   •    Client name
   •    Contact person
   •    Address
   •    Telephone number
   •    E-mail
   •    Services provided
   •    Installation configuration model (e.g., locally hosted, remotely hosted)
   •    Average number of concurrent users
   •    Maximum number of concurrent users
   •    Transaction volume
1.6.2   References of Customers That Cancelled Services or Stopped Implementation
Respondent shall provide information on any clients who have dropped service and/or stopped
implementation of the vendor's product in the last 3 years. The respondent certifies that it is
empowered to use the names of references it provides and agrees that ILCSO may contact
these references. For each reference, please provide the following information:
   •    Client name
   •    Contact person
   •    Address
   •    Telephone number
   •    E-mail address
   •    Reason(s) for service cancellation and/or stopping implementation




                                                                                     Appendix III. 5
                                                                                     RFP No.1JLJ505

2       Technical Specifications for Link Resolver Software
Provide details of how your proposed solution will address each of the following criteria listed
below. If modifications/enhancements must be made to your product to make the proposed
solution meet our requirements, that must be indicated in this technical response and also
reflected in the appropriate pricing appendix.

This section describes a System that allows linking service among information resources (e.g.,
citations, full text documents, library catalog records, other digital objects) and with related
services (e.g., document delivery and interlibrary loan). As used in this section, the source is an
information resource such as an OPAC, an abstracting & indexing database or a citation
database, from which a user is directed from a bibliographic citation to full-text for the citation
via context-sensitive linking. The target describes the information resource that contains the
full-text content or other related information to where the user is taken. The source and target
may be in the same content provider or information resource or they may be in totally unrelated
information resources or content providers. The resource database refers to the database
containing information on databases, aggregators, and individual titles available through
aggregators.

2.1     Context-Sensitive Linking: General

2.1.1 Describe in detail the components of the System and the resources or products that are
available for use with this System. In addition, please address the related topics below.

2.1.2 Describe the process by which context-sensitive linking can be provided to and from
locally created and/or maintained databases, the library’s OPAC, and interlibrary loan,
document delivery services, and course management systems.

2.1.3 Describe how the System's link resolver functions and how it is maintained, including the
System's use of OpenURLs, Cross Ref/DOI, or other standards or methods. Specify the level of
compliance with all standards referenced, by indicating all aspects of the System that do not
fully comply and to which version(s) of the standard(s).

2.1.4 Describe how the System resolves and manages access permissions and licenses for
databases and individual journal titles.

2.2     Resource Database: General

2.2.1   Describe in detail the resource database, as it relates to the library's actual holdings.

2.2.2 Describe in detail the target content providers the resource database is populated with at
the time of initial installation.

2.2.3   List all associated data elements, such as subject or resource type.

2.2.4 Describe the System’s ability to incorporate locally-defined data elements in the
resource database.

2.2.5 Describe how the System can be configured for the level of subscription for a given title
in the resource database (e.g., ability to specify volume(s) or date ranges to which library’s
users have full-text access rights).

2.2.6 Describe how the resource database and the System can be configured to
accommodate access and linking based on rolling horizon-type access, and whether the time
                                                                                       Appendix III. 6
                                                                                 RFP No.1JLJ505

specified can represent either when the library has access (e.g., most recent 12 months) or
when it does not have access (e.g., embargo on the most recent 3 months).

2.3     Resource Database: Sources

2.3.1 List the databases or products from which context-sensitive linking is compatible with
your resolver. Describe which protocols are used in every instance.

2.3.2 List the databases or products from which context-sensitive linking is known to not be
compatible with your resolver.

2.3.3 Describe the process for configuring and activating linking from new sources as they are
negotiated and added to the System.

2.4     Resource Database: Targets

2.3.1 List the databases or products to which context-sensitive linking is compatible with your
resolver, including levels from which linking can take place.

2.3.2 List the databases or products to which context-sensitive linking is known to not be
compatible with your resolver.

2.3.3 Describe the process for setting up links to new target databases or products. Include
documentation or screen shots of the process.

2.5     Resource Database: Administration, Updating and Maintenance

2.5.1 Describe in detail the administrative module and/or interface for resource database
management, including:

1. The process by which the resource database is updated.

2. The roles the Proposer and the library have in updating and maintaining this data.

3. The frequency at which updates are received.

2.5.2 Describe the initial set-up process including any options that would allow members of a
consortium to share some of their set-up work (e.g., there will be a number of resources that are
common to some or all consortial members).

2.5.3 Describe the data that can be imported into the resource database for target resources
and the conditions under which such importation can take place, addressing:

1. The ability to batch process, the prescribed data format(s) (e.g., XML, tab-separated,
spreadsheet, none)

2. The use of outside content tracking service vendors

3. The integration of data provided directly by full-text resource vendors

2.5.4 Similarly, describe the data that can be exported from the resource database and in
what forms.

2.5.5   Describe the link-checking process.
                                                                                   Appendix III. 7
                                                                                       RFP No.1JLJ505


1. Is the process automated?

2. How frequently is the process scheduled?

3. If a user or the System encounters a non-working link, to whom is this reported, how are
corrections made, and how long will it take to get corrected URLs into production?

4. Is the System capable of automatically and dynamically modifying its behavior when target
services are temporarily unavailable or responding incorrectly? How does this get reflected to
the end user, and what System logs would indicate such an event?

2.5.6 List all electronic serials management systems currently known to be fully compatible
with the System. List any serials management systems that are known to be incompatible with
the System.

2.5.7 Can multiple staff work in the administrative module of the resource database
simultaneously? Describe any protections in place to prevent simultaneous update to the same
record or data.

2.6     Linking Interface and Public Display

2.6.1   Describe the linking interface and how options are presented to the user.

2.6.2 How does the System provide for selectively displaying or ordering the targets or other
options (e.g., will it suppress the display of an interlibrary loan link if full-text is available)? What
is the technical process for setting up these options?

2.6.3 Describe the impact, if any, of the System on licensed resources that have limits on
simultaneous users.

2.6.4 Apart from context-sensitive links originating from established sources, describe any
public interface included with the System (e.g., searching the resource database for full-text
based on a known citation).

2.6.5 Describe in detail the extent to which and how the library can customize the System for
public display and the technical expertise needed to do so.

2.6.6 Describe in detail how library patrons can customize or set preferences for context-
sensitive linking.

2.6.7 Describe the help functions available to assist library patrons, and whether those help
functions are customizable by the institution or consortium.

2.6.8 Describe any ability to generate lists from the resource database that are available for
use (e.g., A-Z title lists, lists of titles arranged by subject or resource type).

1. Describe the set-up required by the library to create these lists.
2. Describe the file formats in which they are available.
3. Any additional costs associated with such lists must be listed on the Pricing Proposal.


2.7     Additional Functionality

                                                                                          Appendix III. 8
                                                                                RFP No.1JLJ505

Describe in detail any additional functionality that the System provides.     Explain why this
functionality is important to such a system.

2.8     Technical Requirements

Note: When responding to questions about sessions or simultaneous users, please define what
you mean by “session” or “user”.

2.8.1   Architecture and Platforms

1. Describe the architecture of the System in specific terms, including hardware and software
(including versions) required, and recommended, but optional, add-on software products.
Include capacity for test and training environments. Descriptions should include a high level
diagram. Where applicable, provide information on current customers running your software in
environments similar to the ILCSO technical environment (see Section 1.4 of the Introduction
section for additional information).

2. Specify recommended and possible hardware platforms, including disc subsystem, file
system options (UFS, VxFS, etc.) and RAID configurations. It is anticipated that the hardware
will be purchased separately by ILCSO. State if third-party hosting is offered. Any associated
costs for selecting third-party hosting services should be listed separately in the Pricing
Proposal.

3. List all third-party components (e.g., web application server, RDBMS) required by the
System. Indicate those which may be upgraded independently of System software releases,
and those which may not.

4. Identify all communication protocols supported by the software, including any private
extensions. Include any ports which must be dedicated to the System. What secured
connections are supported for what aspects of the System?

5. List all operating systems (including versions) on which the host System may be run. When
the software is upgraded, for which operating systems is it first made available?

6. List all operating systems (including versions) supported for client applications used for
System administration, database maintenance, or user access.

7. List all web browsers supported including version and operating system. Include any
browsers designed for use on handheld devices.

8. Describe in detail how the System can be configured to be used by members at both the
consortial and local levels for the 65 ILCSO libraries. How many instances of your software
would be required to accomplish this? Indicate all features or options in the System that must
be configured system-wide, rather than at the institutional level.

9. Describe the level of support for Unicode. Which UTFs are used or supported? List all
scripts (e.g., Arabic, Cyrillic, Latin) supported for input and display. Is Unicode data stored,
indexed, and made available for query and display natively, or is it mapped to a System-internal
encoding?


2.8.2   Database

1. Describe the database system(s) used for each component of the System.
                                                                                  Appendix III. 9
                                                                                  RFP No.1JLJ505


2. Give the database schema used by the System. Clearly show which aspects of the System,
   for example user accounts, are used by which portion of the schema.

3. Describe how metadata is stored (e.g., in RDBMS tables, SGML/XML).

4. Describe the application's logging capabilities and options. What events must be logged,
   and which may optionally be logged? How often can logs be refreshed? What tools are
   available for log scanning or for real-time monitoring for intrusion detection?

2.8.3   Data and Object Storage

1. Identify and discuss all components and objects that are stored by the System. Include
   application data, user data, security data, application logic, program code, stored
   procedures, and so on. Describe which of these must be stored within System databases
   and which must be stored outside of System databases. Indicate which are optionally
   stored within or outside of the System.

2. Describe the distributability and scalability of the storage system.

3. Provide recommended space allocation per user for storage of personalized or other user-
   specific data.

2.8.4   Performance and Scalability

1. Provide information about your largest customers, including your largest consortial customer
   and your largest single site customer. Provide information about your largest consortial and
   single site customers operating in a technical environment similar to ILCSO’s (see Section
   1.4 of the Introduction for additional information).

2. Describe how user state or session information is maintained, transmitted, and terminated.
   Describe how the number of concurrent users or sessions is determined, and their effect on
   system and target databases.

3. What, if any, is the limit on the number of concurrent open patron sessions supported by the
   System? What, if any, is the limit on active staff sessions supported by the System? If
   there are limits, describe what happens when either of these limits is reached (e.g., users
   are prevented from starting new sessions).

4. What is the largest number of concurrent open patron sessions experienced by current
   production installations of the software?

5. Describe how the System handles concurrent user limits associated with some licensed
   databases.

6.   Describe the effects of adjusting the session timeout value on the performance of the
     System? Give a recommendation for the value.

7. Describe typical factors that negatively impact system performance either internally (e.g.,
   issues directly related to the product itself as well as its interaction with operating systems
   and hardware platforms) or through network connectivity issues. Describe specific
   instances of the above in which a customer experienced an outage for more than four hours
   (include the identity of the customer, duration of outage, cause, and restoration details).

                                                                                   Appendix III. 10
                                                                               RFP No.1JLJ505

8. Does the System use methods for process prioritizing and load balancing? Describe them.

9. Define the scalability and performance benchmarks determined for the System, and provide
   details of the latest benchmark testing.

10. For the hardware configurations described in Section 1.4 of the Introduction, what is the
    expected time required to retrieve metadata result sets:

         a. 100
         b. 1,000
         c. 10,000

11. List the hardware requirements for supporting the following numbers of simultaneous users.
    If you are making assumptions about the size of result sets, state these assumptions.

        a. 500
        b. 2000
        c. unlimited number of users, when timeout is set to 10 minutes

12. List examples of customers who have implemented your product along with federated
   search engine and/or digital collection management software from other vendors. Examples
   should include the names of the other products involved, timelines for implementing their
   interoperation, and descriptions and history of any known problems interacting with the
   named products.

2.8.5   Availability and Maintenance

1. Describe all instances when the System may be unavailable for staff or user access, (e.g.,
   during software updates, database loads, index regens). Describe how the size of
   databases impacts such required outages.

2. Identify all uses of batch updates, including processes that are scheduled directly with job
   scheduling tools, and processes that are scheduled “behind the scenes” as part of the online
   System.

3. Describe the processes of backup and recovery systemwide and/or per library “instance”.
   For purposes of recovery, describe how backups, in combination with forward recovery from
   transaction logs, can prevent data loss in the event of an unanticipated outage. Describe
   whether and how backups can be made during normal use of the System, including any
   impacts on performance.

4. Describe the process for installing a new release of the application. Describe how the
   parameters that control access, authentication, etc., are maintained in a system upgrade
   and what, if any, user modifications might need to be re-entered.

5. Describe performance monitoring tools and options that are used at large customer sites.

6. How are software bugs reported and tracked? Describe in detail mechanisms for reporting,
   tracking, and disseminating information on outstanding problems. Who can log problem
   requests? How are these requests tracked?

7. Describe the organization’s support for prior releases.       When does the organization
   discontinue support of a prior release?

                                                                                Appendix III. 11
                                                                                RFP No.1JLJ505

8. On average, how often does the company release new versions of the software? On average,
    how often does the company release software patches between releases of new software
    versions? What is the role of customers in testing early releases?

2.8.6   Development Environment

1. Describe all application programming interfaces (API) or software development kits (SDK)
   available (e.g., for creation of automated import programs and alternative search and
   browse interfaces).

2. Describe any other tools provided for customization of user interfaces or System services.

2.8.7   Integration

1. Indicate how this application could be integrated with each of the other software components
    described in this RFP: Digital Object Management System (Appendix I) and Federated
    Search Software (Appendix II) whether from the same vendor or other vendors. Identify the
    products in each category with which this product has successfully been implemented.
    Provide references of customers, preferably consortia, which have integrated these
    products.

2. Describe ways in which the System can integrate with the following products licensed by
   ILCSO and ILCSO member libraries: Endeavor’s Voyager (specify which versions of the
   Voyager software the System can successfully be integrated with), OCLC’s ILLiad,
   EBSCOhost, FirstSearch, WorldCat, Ovid, and various other bibliographic management
   tools.

3. Does the System support the Open Archives Initiative Protocol for Metadata Harvesting
   (OAI-PMH) specification as a data provider? As a harvester? With what version(s) of OAI-
   PMH is the System is fully compliant for data provider and harvester services?

4. Does the System implement ANSI/NISO Z39.50 Application Service Definition and Protocol
   Specification? Does it comply with Z39.50 as specified in the Bath Profile, version 1.1?
   What other Z39.50 services and attributes does it support?

5. Describe the System's support for OpenURL version 1.0.

6. Describe the system’s interoperability with software being used for web portals at academic
   institutions (e.g., u-Portal, Campus Pipeline Luminis).

7. Indicate other typical applications or services with which this application can integrate or
   interface, including serials management software (e.g., TDNet, Serials Solutions) and
   course management systems (e.g., Blackboard, WebCT), including the process for
   embedding a search box in course management systems.


2.8.8   Security

1. Describe the System's support for network transport encryption (e.g., SSL), either for front-
   end connections to Web interface, or for tunneled connections between application
   components on different hosts.

2. Describe any procedures in place to allow timely detection, notification and remediation of
   security problems.
                                                                                 Appendix III. 12
                                                                                  RFP No.1JLJ505


3. If System components run on different hosts, describe how to identify, change, and secure
   the network routes between them (e.g., to identify and change port numbers for firewall
   configuration)?

4. Identify all instances in which System processes require access to (or run as) privileged
   UNIX accounts (e.g., root).

5.    What procedures are in place for secure and monitored vendor access to hosts and
     applications (e.g., ssh, sudo)?

6. Identify any other security controls provided in the System (e.g., checking of user inputs to
   prevent buffer overflow conditions).

2.8.9    System Administration

1.      Describe the system administration module and interface, including whether the
        module/interface is a separate client program, a Web interface, etc. The description
        should include, among other features:

         a. Timeout control
         b. Access/authorization control
         c. System parameterization
         d. Management of metadata indexing
         e. Collection/database creation
         f. Parameters for retrieval (e.g., limits on result set sizes, etc.)

2. Describe how delegated administrators are able to differentiate and secure levels of access
   across the System. Describe how the system administration module itself can be
   segmented, to authorize staff to manage certain aspects and only those aspects. Define
   levels of granularity of authorization.

3. Describe how, in a consortium setting, system administration features such as management
   of collections can be delegated to the Consortium member libraries. How many instances of
   which components of the software would be required for each ILCSO library to have its own
   set of search options that is under the library’s control? Is it possible to save redundant
   setup effort for databases/products which multiple ILCSO libraries have in common?

4. Identify the level of technical expertise required to use the system administration application.
    Describe the steps required to perform common system administration tasks, including
    those identified in 8.8.9.1 and 8.8.9.2 above. What software would system administrators
    need to be able to use, what product specific training might they need, and how would they
    receive this training?

5. List necessary and recommendable programming or other technical skills (indicate level) for
   system administrators. What aspects of support require technical application specialists?

6. Describe the statistical reporting capabilities of the System. Provide a complete list of all of
   the standard reports. Describe the electronic formats in which the reports can be delivered.
   Describe how the reports can be customized in terms of content and frequency by individual
   institutions in a consortial arrangement. Describe how necessary information and access
   options are provided to allow the development of custom reports through standard tools
   such as Microsoft Access, etc.

                                                                                    Appendix III. 13
                                                                                          RFP No.1JLJ505

    2.8.10 Patron Authentication and Access

    1. Explain how the System supports end-user and staff authentication and authorization.
       Include all options supported by the System (e.g., IP wrapping, password/ID, Public/private
       key, certificates, LDAP, Shibboleth, Kerberos). Describe whether the System provides its
       own authentication and access control systems, which external systems it supports, and
       whether this is a configurable option.

    2. Describe the ability of the System to make authorization decisions based on users’ attributes
       (e.g., student vs. faculty status), including the ability to access external systems (e.g.,
       integrated library system patron database, LDAP, custom API) for those attributes.

    3. Describe the ability of the System to support proxy server use for patrons accessing the
       System from outside the campus.

    4.     Describe which user transactions occur over secure channels (e.g., network transport
          encryption), and which do not.

    5.     Describe how the System authenticates or maintains authentication of users from one
          licensed resource to another, whether the resource uses IP-based authorization or if access
          is controlled by username/password.

    6. If the link resolver is not hosted by the library, does this have any affect on what IP address
        will appear to the target resource as far as authentication is concerned? If so, how are
        institutional licenses, usage limits, usage reports, etc. reconcilable for the target resource?

    7. Describe all instances (e.g., logs, database tables) where specific users are associated with
       specific transactions and access to specific resources. In each case, indicate how long that
       information is retained, and whether and how it can be purged without affecting the
       System’s functionality.

    2.8.11 Rights Management

    1. Describe how the System manages rights for both owned and licensed material, and how
       this integrates with the authentication and authorization process.

    2. Indicate whether the System can define access profiles by:

             a. User roles or other group attributes (e.g., institutional affiliation)
             b. Individual user attributes that override user group attributes
             c. IP spaces

    3. Does the System provide a license tracking system? If so, describe it.

    4. Does the System generate automated administrator-set prompts or reports when
       renewal/expiry dates are due?

3   Implementation

    3.1        Provide a list of sites in production, including consortial sites where applicable.

    3.2        Provide current release/version number(s) and date(s) for the System.

    3.3        Provide an example of a schedule from a recent consortial implementation.
                                                                                           Appendix III. 14
                                                                                       RFP No.1JLJ505


    3.4      What consulting services are included for System installation, and implementation?

    3.5    Summarize the roles of the vendor, ILCSO’s consortial office system support staff, and
    ILCSO member library staff during the implementation process.

4   Training and Other Services

    4.1       Describe the standard training provided with the purchase of this System, including
    class descriptions and training objectives for staff, methods used (e.g., instructor led, distance
    learning, “train-the-trainer”, CBT), locations, and frequency of offerings. Confirm that training
    will be provided in Chicago, Champaign-Urbana, and other sites in the state of Illinois to be
    agreed upon by the successful Proposer and ILCSO.

    4.2       Identify the standard training and any customized training that is available to reflect
    individual institution needs, and include any limitations such as class sizes, locations, and time
    limits. Any additional costs associated with add-on or customized training should be listed
    separately in the Pricing Proposal.

    4.3     Provide a training plan for training 25 system administrators, 50 library staff involved in
    system configuration, and 75 library staff who will use the product as a finding tool.

    4.4        Describe any training and consulting services that are available at extra cost (e.g., not
    listed as standard training above) and describe how those costs are calculated, including
    trainers’ travel and expenses, if applicable.

    4.5      Indicate the number of trainers employed by the company.

5   Technical Support

    5.1      Describe the on-going support available to staff, including hot line or toll free numbers,
    day and time availability, and any restrictions. List any web sites used for support purposes.

    5.2      Describe the methodologies and tools used for testing new software versions prior to
    release.

    5.3      Describe how you communicate with users about upcoming changes.

    5.4    Describe how requests for software enhancements are handled. Who can log
    enhancement requests for a given customer? How are they tracked? How are priorities set for
    enhancements? What role, if any, does a user group have in this process?

    5.5      Describe how the company performs custom development work for a customer, if
    applicable. What policies and pricing apply to such custom work?

    5.6       Describe the user and technical documentation that is available for the System.
    Include information on documentation that provides:
             1. An overview of the System
             2. Installation/configuration information
             3. System and database administration
             4. Technical information on jobs or modules executed

                                                                                         Appendix III. 15
                                                                                      RFP No.1JLJ505

             5. Data element documentation
             6. Description of tables and views and the relationship of database entities
             7. Context sensitive help

6   Accessibility Issues

    Describe in detail how the System addresses web accessibility issues including a statement of
    the current level of compliance with Section 508, and/or future plans to achieve compliance.

7   Vision, Plans and Distinguishing Features

    Describe your company’s vision and plans for this offering over the next two years:

    7.1      Describe any planned changes in the product’s functionality or interface.

    7.2      Describe any planned changes in services offered in support of the product.

    7.3    Describe any features of your product (in addition to those referenced in the sections
           above) which distinguish it from its competitors in the marketplace.

8   Licensing

    8.1    Licensing Terms

    List all the licenses that would be required to access the proposed solution. Provide those
    actual license agreements in your response to Appendix III. ALL REQUIRED LICENSE
    AGREEMENTS MUST BE ADDRESSED IN THIS RFP RESPONSE.

    8.2    Third Party Licenses

    List all 3rd party licenses required for any underlying operating systems, databases, or other
    software components necessary to operate systems.




                                                                                         Appendix III. 16
                                          RFP No.1JLJ505



                   RFP # JLJ505


               Digital Library Products




                  APPENDIX IV


                Pricing Document

Individual Component Pricing Proposal Attachments
                                                                                    RFP No.1JLJ505


APPENDIX IV - PRICING INTRODUCTION


The vendor must provide sufficient pricing details to permit the University to understand the
basis for the quotation. At a minimum, the University requires detailed information on the
relative cost of each component of the software products and support services, what if any
discounts are applied, and all assumptions or requirements upon which prices are contingent.
Pricing should include any educational discount provided to Higher Education Clients.

Provide a line item cost analysis for all components necessary (including any components
necessary for 24x7 availability). The University will assume that the price quoted will include all
software and database components necessary to implement the proposed system solution. The
University must be able to calculate the marginal costs of adding additional geographic
locations and/or instances.

All pricing options listed in Appendix IV, V and VI may be considered in the overall proposal
analysis and award.

The University will award the Contract to the responsible Proposer whose offer is determined to
be the most advantageous to the University, taking into consideration price and the evaluation
factors set forth in this RFP. It is the intent of the University to enter into negotiations with the
firm(s) whose proposal(s) are deemed most advantageous. The University will award the
contract(s) to the respondent(s) whose proposal best serves the interest of the University. The
University reserves the right to award a contract to a respondent selected on a basis other than
least cost.

Proposers must submit a response for each attachment of Appendix IV, V and VI. If you do not
wish to propose a solution for a particular model, indicate “no” to the first question listed on each
attachment form, “Are you offering pricing for this model?” and sign the attachment.
Responses to Appendix IV, Appendix V, and Appendix VI must be in both hard copy and on
diskette or CD-ROM in Microsoft Excel.

1. Where applicable, ILCSO prefers that the license or subscription allow ILCSO to use as
   many instances of the software as might be needed to properly serve authorized ILCSO
   libraries. This could enable ILCSO libraries to explore various alternative configurations.
   One library might have its own separate instance of one of the software modules, where a
   group of libraries might conceivably share another instance. A library might maintain its own
   instance of a module on its own server, or choose to have ILCSO maintain it on an ILCSO
   server, or have the software run on a Proposer’s server. ILCSO will consider all proposed
   configuration models.

2. For all pricing Attachments, Proposer shall indicate whether the software will be hosted by
   their company (Proposer) or ILCSO (Customer).

3. From time to time, ILCSO will admit additional member libraries (e.g., ILCSO admitted nine
   new members in November 2003). Some future ILCSO members may wish to use the
   digital library products licensed by ILCSO. Proposers shall provide specific pricing models
   for extending access to new members beyond the current 65 members.




                                                                                      Appendix IV. 1
                                                                                RFP No.1JLJ505


4. ILCSO desires to exercise its right to renew the contract on a year-to-year basis and would
   prefer to have Proposers provide pricing for a minimum five year period.

5. The pricing proposal forms were developed using the following basic principles:

   a. Proposers may submit pricing for one, two, or all three digital library software
      components. Pricing submitted for each of the components must be provided separately
      (e.g., if a Proposer bids three components, the Proposer must provide separate pricing
      for each component). Appendix IV, Attachments 1-18, as applicable should be used for
      submitting individual component pricing.

   b. Proposers submitting pricing for more than one component may provide an additional
      bundled price for those components. Should ILCSO choose more than one component
      from the Proposer, any applicable discounts are to be outlined. In such cases, the
      Proposer must still provide individual pricing for each component as indicated above.
      Appendix V, Attachments 1-3, as applicable should be used for submitting bundled
      pricing.

   c. Proposers have the option to submit alternative pricing models that differ from the
      individual component pricing or the bundled pricing models. This may be a variation on
      these two models, or may be something entirely different. Examples of alternative pricing
      models might include discounted pricing based on the number of participating
      institutions, pricing based on simultaneous users, etc. Appendix VI, Attachments 1-2, as
      applicable are to be used for submitting alternative pricing.

6. Proposers should submit pricing using the following licensing models:

   a. Acquisition Model - Paying a license fee up front to acquire the software, with annual
      software maintenance fees in subsequent years. The recurring maintenance and support
      fees would be set at a percentage of the initial software license fee.

   b. Subscription Model - Paying an annual subscription fee to lease access to the software
      on a year-to-year basis. This would be similar to how libraries subscribe to electronic
      resources (e.g., the first year’s subscription would be the base price, and subsequent
      years’ subscriptions would be incremented at a rate that is agreeable to both parties).

7. In order to allow for flexibility in pricing models, ILCSO suggests three possible pricing
   options. These options apply to the acquisition and subscription models. Submitting pricing
   for the alternative pricing method is optional. Proposers are strongly encouraged to submit
   pricing for the following:

   a. Site License – One license, one price, for the ILCSO community as a whole (e.g., ILCSO
      would pay the same single license regardless of how many libraries actually use the
      software). There would be no additional charges if libraries opt to begin using the
      software in years following the initial implementation, other than generally scheduled
      annual increases agreed to in the contract.

   b. Per Library – Proposers would provide a fixed fee price for each individual library,
      regardless of levels of participation. Under this model, ILCSO would pay only for those
      libraries actually using the software in a given year. There would be no additional



                                                                                     Appendix IV. 2
                                                                         RFP No.1JLJ505


   charges if libraries opt to begin using the software in years following the initial
   implementation, other than prices as agreed to in the contract.

c. Alternative - Proposers may submit pricing for the acquisition or subscription models
   which may be a variation on the site license or per library pricing methods.




                                                                           Appendix IV. 3
                                                                                 RFP No.1JLJ505


APPENDIX IV – INDIVIDUAL COMPONENT PRICING PROPOSAL ATTACHMENTS


DIGITAL OBJECT MANAGEMENT SOFTWARE

Attachment 1: Acquisition Model - Unlimited Site License

Attachment 2: Acquisition Model - Per Library

Attachment 3: Acquisition Model - Per Library (cost for each ILCSO library listed)

Attachment 4: Subscription Model - Unlimited Site License

Attachment 5: Subscription Model - Per Library

Attachment 6: Subscription Model - Per Library (cost for each ILCSO library listed)

FEDERATED SEARCH SOFTWARE

Attachment 7: Acquisition Model - Unlimited Site License

Attachment 8: Acquisition Model - Per Library

Attachment 9: Acquisition Model - Per Library (cost for each ILCSO library listed)

Attachment 10: Subscription Model - Unlimited Site License

Attachment 11: Subscription Model - Per Library

Attachment 12: Subscription Model - Per Library (cost for each ILCSO library listed)

LINK RESOLVER SOFTWARE

Attachment 13: Acquisition Model - Unlimited Site License

Attachment 14: Acquisition Model - Per Library

Attachment 15: Acquisition Model - Per Library (cost for each ILCSO library listed)

Attachment 16: Subscription Model - Unlimited Site License

Attachment 17: Subscription Model - Per Library

Attachment 18: Subscription Model - Per Library (cost for each ILCSO library listed)




                                                                                      Appendix IV. 4
                            RFP No.1JLJ505



     RFP # JLJ505


 Digital Library Products




    APPENDIX V


 Pricing Document

Bundled Price Model
                                                                                    RFP No.1JLJ505


APPENDIX V - PRICING INTRODUCTION


The vendor must provide sufficient pricing details to permit the University to understand the
basis for the quotation. At a minimum, the University requires detailed information on the
relative cost of each component of the software products and support services, what if any
discounts are applied, and all assumptions or requirements upon which prices are contingent.
Pricing should include any educational discount provided to Higher Education Clients.

Provide a line item cost analysis for all components necessary (including any components
necessary for 24x7 availability). The University will assume that the price quoted will include all
software and database components necessary to implement the proposed system solution. The
University must be able to calculate the marginal costs of adding additional geographic
locations and/or instances.

All pricing options listed in Appendix IV, V and VI may be considered in the overall proposal
analysis and award.

The University will award the Contract to the responsible Proposer whose offer is determined to
be the most advantageous to the University, taking into consideration price and the evaluation
factors set forth in this RFP. It is the intent of the University to enter into negotiations with the
firm(s) whose proposal(s) are deemed most advantageous. The University will award the
contract(s) to the respondent(s) whose proposal best serves the interest of the University. The
University reserves the right to award a contract to a respondent selected on a basis other than
least cost.

Proposers must submit a response for each attachment of Appendix IV, V and VI. If you do not
wish to propose a solution for a particular model, indicate “no” to the first question listed on each
attachment form, “Are you offering pricing for this model?” and sign the attachment.
Responses to Appendix IV, Appendix V, and Appendix VI must be in both hard copy and on
diskette or CD-ROM in Microsoft Excel.

1. Where applicable, ILCSO prefers that the license or subscription allow ILCSO to use as
   many instances of the software as might be needed to properly serve authorized ILCSO
   libraries. This could enable ILCSO libraries to explore various alternative configurations.
   One library might have its own separate instance of one of the software modules, where a
   group of libraries might conceivably share another instance. A library might maintain its own
   instance of a module on its own server, or choose to have ILCSO maintain it on an ILCSO
   server, or have the software run on a Proposer’s server. ILCSO will consider all proposed
   configuration models.

2. For all pricing Attachments, Proposer shall indicate whether the software will be hosted by
   their company (Proposer) or ILCSO (Customer).

3. From time to time, ILCSO will admit additional member libraries (e.g., ILCSO admitted nine
   new members in November 2003). Some future ILCSO members may wish to use the
   digital library products licensed by ILCSO. Proposers shall provide specific pricing models
   for extending access to new members beyond the current 65 members.




                                                                                       Appendix V. 1
                                                                                 RFP No.1JLJ505


4. ILCSO desires to exercise its right to renew the contract on a year-to-year basis and would
   prefer to have Proposers provide pricing for a minimum five year period.

5. The pricing proposal forms were developed using the following basic principles:

   d. Proposers may submit pricing for one, two, or all three digital library software
      components. Pricing submitted for each of the components must be provided separately
      (e.g., if a Proposer bids three components, the Proposer must provide separate pricing
      for each component). Appendix IV, Attachments 1-18, as applicable should be used for
      submitting individual component pricing.

   e. Proposers submitting pricing for more than one component may provide an additional
      bundled price for those components. Should ILCSO choose more than one component
      from the Proposer, any applicable discounts are to be outlined. In such cases, the
      Proposer must still provide individual pricing for each component as indicated above.
      Appendix V, Attachments 1-3, as applicable should be used for submitting bundled
      pricing.

   f.   Proposers have the option to submit alternative pricing models that differ from the
        individual component pricing or the bundled pricing models. This may be a variation on
        these two models, or may be something entirely different. Examples of alternative pricing
        models might include discounted pricing based on the number of participating
        institutions, pricing based on simultaneous users, etc. Appendix VI, Attachments 1-2, as
        applicable are to be used for submitting alternative pricing.

6. Proposers should submit pricing using the following licensing models:

   c. Acquisition Model - Paying a license fee up front to acquire the software, with annual
      software maintenance fees in subsequent years. The recurring maintenance and support
      fees would be set at a percentage of the initial software license fee.

   d. Subscription Model - Paying an annual subscription fee to lease access to the software
      on a year-to-year basis. This would be similar to how libraries subscribe to electronic
      resources (e.g., the first year’s subscription would be the base price, and subsequent
      years’ subscriptions would be incremented at a rate that is agreeable to both parties).

7. In order to allow for flexibility in pricing models, ILCSO suggests three possible pricing
   options. These options apply to the acquisition and subscription models. Submitting pricing
   for the alternative pricing method is optional. Proposers are strongly encouraged to submit
   pricing for the following:

   d. Site License – One license, one price, for the ILCSO community as a whole (e.g., ILCSO
      would pay the same single license regardless of how many libraries actually use the
      software). There would be no additional charges if libraries opt to begin using the
      software in years following the initial implementation, other than generally scheduled
      annual increases agreed to in the contract.

   e. Per Library – Proposers would provide a fixed fee price for each individual library,
      regardless of levels of participation. Under this model, ILCSO would pay only for those
      libraries actually using the software in a given year. There would be no additional



                                                                                     Appendix V. 2
                                                                                RFP No.1JLJ505


       charges if libraries opt to begin using the software in years following the initial
       implementation, other than prices as agreed to in the contract.

Alternative - Proposers may submit pricing for the acquisition or subscription models which may
be a variation on the site license or per library pricing methods.




                                                                                   Appendix V. 3
                                                                          RFP No.1JLJ505


APPENDIX V – BUNDLED PRICING PROPOSAL ATTACHMENTS


Attachment 1: Bundled Pricing Model - Proposer Hosted System

Attachment 2: Bundled Pricing Model - Customer Hosted System

Attachment 3: Bundled Pricing Model - Proposer and/or Customer Hosted System




                                                                               Appendix V. 4
                              RFP No.1JLJ505



       RFP # JLJ505


   Digital Library Products




      APPENDIX VI


   Pricing Document

Alternative Pricing Model
                                                                                    RFP No.1JLJ505


APPENDIX VI - PRICING INTRODUCTION


The vendor must provide sufficient pricing details to permit the University to understand the
basis for the quotation. At a minimum, the University requires detailed information on the
relative cost of each component of the software products and support services, what if any
discounts are applied, and all assumptions or requirements upon which prices are contingent.
Pricing should include any educational discount provided to Higher Education Clients.

Provide a line item cost analysis for all components necessary (including any components
necessary for 24x7 availability). The University will assume that the price quoted will include all
software and database components necessary to implement the proposed system solution. The
University must be able to calculate the marginal costs of adding additional geographic
locations and/or instances.

All pricing options listed in Appendix IV, V and VI may be considered in the overall proposal
analysis and award.

The University will award the Contract to the responsible Proposer whose offer is determined to
be the most advantageous to the University, taking into consideration price and the evaluation
factors set forth in this RFP. It is the intent of the University to enter into negotiations with the
firm(s) whose proposal(s) are deemed most advantageous. The University will award the
contract(s) to the respondent(s) whose proposal best serves the interest of the University. The
University reserves the right to award a contract to a respondent selected on a basis other than
least cost.

Proposers must submit a response for each attachment of Appendix IV, V and VI. If you do not
wish to propose a solution for a particular model, indicate “no” to the first question listed on each
attachment form, “Are you offering pricing for this model?” and sign the attachment.
Responses to Appendix IV, Appendix V, and Appendix VI must be in both hard copy and on
diskette or CD-ROM in Microsoft Excel.

1. Where applicable, ILCSO prefers that the license or subscription allow ILCSO to use as
   many instances of the software as might be needed to properly serve authorized ILCSO
   libraries. This could enable ILCSO libraries to explore various alternative configurations.
   One library might have its own separate instance of one of the software modules, where a
   group of libraries might conceivably share another instance. A library might maintain its own
   instance of a module on its own server, or choose to have ILCSO maintain it on an ILCSO
   server, or have the software run on a Proposer’s server. ILCSO will consider all proposed
   configuration models.

2. For all pricing Attachments, Proposer shall indicate whether the software will be hosted by
   their company (Proposer) or ILCSO (Customer).

3. From time to time, ILCSO will admit additional member libraries (e.g., ILCSO admitted nine
   new members in November 2003). Some future ILCSO members may wish to use the
   digital library products licensed by ILCSO. Proposers shall provide specific pricing models
   for extending access to new members beyond the current 65 members.




                                                                                       Appendix VI.1
                                                                                 RFP No.1JLJ505


4. ILCSO desires to exercise its right to renew the contract on a year-to-year basis and would
   prefer to have Proposers provide pricing for a minimum five year period.

5. The pricing proposal forms were developed using the following basic principles:

   g. Proposers may submit pricing for one, two, or all three digital library software
      components. Pricing submitted for each of the components must be provided separately
      (e.g., if a Proposer bids three components, the Proposer must provide separate pricing
      for each component). Appendix IV, Attachments 1-18, as applicable should be used for
      submitting individual component pricing.

   h. Proposers submitting pricing for more than one component may provide an additional
      bundled price for those components. Should ILCSO choose more than one component
      from the Proposer, any applicable discounts are to be outlined. In such cases, the
      Proposer must still provide individual pricing for each component as indicated above.
      Appendix V, Attachments 1-3, as applicable should be used for submitting bundled
      pricing.

   i.   Proposers have the option to submit alternative pricing models that differ from the
        individual component pricing or the bundled pricing models. This may be a variation on
        these two models, or may be something entirely different. Examples of alternative pricing
        models might include discounted pricing based on the number of participating
        institutions, pricing based on simultaneous users, etc. Appendix VI, Attachments 1-2, as
        applicable are to be used for submitting alternative pricing.

6. Proposers should submit pricing using the following licensing models:

   e. Acquisition Model - Paying a license fee up front to acquire the software, with annual
      software maintenance fees in subsequent years. The recurring maintenance and support
      fees would be set at a percentage of the initial software license fee.

   f.   Subscription Model - Paying an annual subscription fee to lease access to the software
        on a year-to-year basis. This would be similar to how libraries subscribe to electronic
        resources (e.g., the first year’s subscription would be the base price, and subsequent
        years’ subscriptions would be incremented at a rate that is agreeable to both parties).

7. In order to allow for flexibility in pricing models, ILCSO suggests three possible pricing
   options. These options apply to the acquisition and subscription models. Submitting pricing
   for the alternative pricing method is optional. Proposers are strongly encouraged to submit
   pricing for the following:

   f.   Site License – One license, one price, for the ILCSO community as a whole (e.g., ILCSO
        would pay the same single license regardless of how many libraries actually use the
        software). There would be no additional charges if libraries opt to begin using the
        software in years following the initial implementation, other than generally scheduled
        annual increases agreed to in the contract.

   g. Per Library – Proposers would provide a fixed fee price for each individual library,
      regardless of levels of participation. Under this model, ILCSO would pay only for those
      libraries actually using the software in a given year. There would be no additional



                                                                                     Appendix VI.2
                                                                                RFP No.1JLJ505


       charges if libraries opt to begin using the software in years following the initial
       implementation, other than prices as agreed to in the contract.

Alternative - Proposers may submit pricing for the acquisition or subscription models which may
be a variation on the site license or per library pricing methods.




                                                                                   Appendix VI.3
                                                             RFP No.1JLJ505


           APPENDIX VI – ALTERNATIVE PRICING PROPOSAL ATTACHMENTS


Attachment 1: Alternative Pricing Model - Acquisition

Attachment 2: Alternative Pricing Model – Subscription




                                                               Appendix VI.4
                                              RFP No.1JLJ505



              RFP # JLJ505


         Digital Library Products




            APPENDIX VII


ILCSO TECHNICAL ENVIRONMEMT




 APPENDIX VII – ILCSO TECHNICAL ENVIRONMENT
                                   RFP No.1JLJ505




Attachment 1:   ILCSO Server Map

Attachment 2: ILCSO Network Map
                                       RFP No.1JLJ505



                RFP # JLJ505


            Digital Library Products




              APPENDIX VIII


VENDOR DESCLOSURE OF FINANCIAL INTERESTS
                               RFP No.1JLJ505



        RFP # JLJ505


    Digital Library Products




       APPENDIX IX


BIDDERS APPLICATION FORM
                                    RFP No.1JLJ505



             RFP # JLJ505


         Digital Library Products




            APPENDIX X


INDEMNITY AGREEMENTS AND LIABILITY
            INSURANCE
                                      RFP No.1JLJ505



               RFP # JLJ505


           Digital Library Products




              APPENDIX XI


SAMPLE CONTRACT TERMS AND CONDITIONS
                                                                                     RFP No.1JLJ505


  Contractual Terms and Conditions

  Provide a copy of your established standard company contract with the proposal.

  Below is a list of the University’s standard terms and conditions applicable to Software and
  Professional Services contracts. This language will be incorporated into any contract resulting
  from an award of this RFP. Specific additional contract details will be added to the contract
  based on substantive information provided in any successful Respondent’s response.

  Any exceptions to the University’s standard terms and conditions listed below must be made
  explicit and clearly indicated in the Respondent’s response. Additionally, any alternate
  language and/or terms and conditions to an exception must be provided by the Respondent in
  the response submitted to the RFP.

  The University reserves the right to negotiate all terms and conditions.

1. TERMINATION FOR CONVENIENCE
  The University may terminate this contract for convenience upon thirty (30) days prior written
  notice to the contractor. In the event of termination for convenience, the Contractor shall be paid
  for services satisfactorily performed under this contract up to the effective date of termination.

2. TERMINATION FOR CAUSE
  The University may cancel the Contract for breach, as determined by the University, for items
  such as, but not limited to: failure to meet insurance requirements, failure to meet required
  performance or progress standards as described herein, or if the quality or level of service is
  unsatisfactory to the University. This cause for breach may include any cessation or diminution
  of service which, in the opinion of the University, is not in its best interest or any failure to
  comply with the terms of the Contract.

  The University shall notify the Contractor in writing of any Contract breach. The Contractor shall
  remedy the breach within ten (10) calendar days. If the breach is not remedied in ten (10)
  calendar days, the University may cancel the Contract by giving thirty (30) days notice in writing
  of its intention to cancel this Contract.

  Should the University breach any terms or provisions of the Contract, the Contractor shall serve
  written notice on the University setting forth the alleged breach and demanding compliance with
  the Contract. Unless within ten (10) calendar days after receiving such notice, the allegation
  shall be contested or such breach shall cease and arrangements be made for corrections, the
  Contractor may cancel the Contract by giving thirty (30) days notice, in writing of its intention to
  cancel this Contract.

  In the event of cancellation for breach, the Contractor shall be paid only for work satisfactorily
  performed up to the date of cancellation.

  In the event of early termination or cancellation for any cause, no payment for services
  performed will be made until and unless any necessary reports and/or deliverables have been
  provided.

  If, during the term of this contract, University determines that the contractor is delinquent in the
  payment of any debt to the State of Illinois as set forth in Section 50-11 of the Illinois



                                                                                        Appendix XI. 1
                                                                                     RFP No.1JLJ505


  Procurement Code (30 ILCS 500), the University may declare the contract void if it determines
  that voiding the contract is in the best interests of the State.

3. ADMINISTRATION OF CONTRACT
  The University Contract Representative named below shall be the University’s authorized
  representative in all matters pertaining to procedures or the administration of the terms and
  conditions of this Contract. All matters of interpretation and/or approval shall be directed to the
  University Contract Representative who will be the primary point of contact and coordinate any
  necessary response.

  For information purposes, a University Technical Representative may be indicated below. If
  listed, the University Technical Representative may be contacted directly by the Contractor to
  discuss technical issues or schedules related to performance of duties and responsibilities in
  the Contract.

  Any substantive changes to any term or condition or work to be performed under the Contract
  must be made in the form of an amendment to this Contract.

  University Contract Representative:               University Technical Representative:


4. NOTIFICATION
  All communications hereunder shall be in writing and shall be sent by registered or certified
  mail, return receipt requested, or by an overnight courier service to the persons listed below. A
  notice shall be deemed to have been given when received at the specified notification address.
  Include the Contract Number (or Purchase Order Number, if applicable) in any notifications.

  Notices to the University shall be sent to:       Notices to the Contractor shall be sent to:


5. INDEPENDENT CONTRACTOR
  The Contractor will independently perform all services specified in this Contract, except as
  provided herein. The Contractor shall have sole control over the manner and means of providing
  the work and services performed under this Contract including the selection and use of any
  Subcontractors used in the performance of the required services. The University’s relationship
  to the Contractor under this Contract shall be that of Independent Contractor. The Contractor
  will not be considered an agent or employee of the University for any purpose. Contractor will
  not hire University employees to perform any portion of the work or services provided for herein,
  including clerical, secretarial, and similar incidental services, except with the prior written
  approval of the University.

6. CONFLICT OF INTEREST
  The Contractor affirms that, to the best of its knowledge, there exists no actual or potential
  conflict between the Contractor’s family, business, or financial interests and its services under
  this Contract; and, in the event of change in either its private interests or services under this
  Contract, the Contractor will raise with the University any questions regarding possible conflict
  of interest which may arise as a result of such change.




                                                                                        Appendix XI. 2
                                                                                        RFP No.1JLJ505



7. ASSIGNMENT
  This Contract may not be assigned, in whole or in part, by either party without the prior written
  approval of the other party, except in connection with a merger or sale of all or substantially all of
  the assets of such party provided, however, that the obligations of such party under this Contract
  shall not be extinguished or otherwise affected by any such assignment.

8. SUBCONTRACTORS
  If any Subcontractor is to be used in the performance of the services required under this
  Contract, the Contractor has provided the name(s), address(es) and amount(s) expected to be
  paid to Subcontractor(s) and a description of which portion(s) of the work will be subcontracted
  out is listed below or in a separate Exhibit to this Contract.

  Contractor may not use the services of other Contractors or Subcontractors not named herein
  without prior written permission of the University. If at any time during the term of the resulting
  Contract, a Contractor adds or changes any Subcontractor, the Contractor shall promptly notify,
  in writing, the University Contract Representative of the names and addresses and the expected
  payment each new or replaced Subcontractor will receive under the Contract.

9. DISCREPANCIES AND OMISSIONS
  Should anything which is necessary for a clear understanding of the work be omitted from the
  Contract documents, or should it appear that various instructions are in conflict, the Contractor shall
  secure written instructions from the University Contract Representative before proceeding with the
  work affected by such omissions or discrepancies.

10.      COMPENSATION
           10.1 RATE OF COMPENSATION
         The Contractor shall receive compensation at the rate of _____________________ for
          the period of this contract as compensation for all work and services performed. This
          fee is to include all secretarial, clerical, and similar incidental services. Reasonable
          expenses, including travel expenses, not to exceed $_________________________,
          will be reimbursed with prior University approval and in accordance with University
          policy. Reimbursement requires appropriate documentation as determined by the
          University.
           10.2 METHOD OF PAYMENT
          The University agrees to pay the Contractor no more frequently than monthly for
          services rendered for the contract period in accordance with the amounts specified in
          this Contract. The rate of payment will be __________________________. Any
          applicable discount will be taken if payment is processed within the stated time.
          Payment of interest may be available if the University fails to comply with the State
          Prompt Payment Act (30 ILCS 540/0.01).

          The University may withhold or, on account of subsequently discovered evidence,
          nullify the whole or a part of any invoice to such extent as the University may deem
          necessary to protect the University from loss on account of: a) Unsatisfactory work
          performed; b) Failure of the Contractor to make required payments to Subcontractors;
          c) Damage to University property or related liability; or d) Incomplete, inaccurate, or
          unauthorized billing.

          The Contractor is responsible for completing the scope of work specified in this


                                                                                          Appendix XI. 3
                                                                                    RFP No.1JLJ505


          Contract. The University may withhold final payment until all services, reports and/or
          other deliverables specified herein have been completed in a form satisfactory to the
          University.
           10.3 METHOD OF BILLING
          To receive payment, the Contractor must submit an appropriately itemized invoice to
          the University for services performed and allowable expenses incurred. Invoices are to
          be sent in duplicate to the University Technical Representative. The Contract Number
          (or Purchase Order Number, if applicable) must be included on the invoice.

11.UNIVERSITY’S RIGHT OF INSPECTION
  The University reserves right to inspect and investigate thoroughly the establishment, facilities,
  equipment, business reputation, and other qualifications of the Contractor and any of its
  Subcontractors throughout the life of the Contract.

12.UNIVERSITY’S RIGHT TO HAVE WORK EXECUTED
  If the Contractor should neglect to execute the work or any part or parts thereof diligently and
  properly or fail to perform any provision of the Contract, the University, after ten (10) days’
  written notice to the Contractor, may without prejudice to any other remedy it may have, make
  good such deficiencies and may deduct the cost thereof from the payment then or thereafter
  due the Contractor.

13.INDEMNIFICATION
  The Contractor shall indemnify and hold harmless the University and University’s agents,
  servants and employees from and against all loss, damage and expense which they may
  sustain or become liable for on account of injury to or death of persons, or on account of
  damage to or destruction of property resulting from the performance of work under the Contract
  by the Contractor or its Subcontractors, or due to or arising in any manner from the wrongful act
  or negligence of the Contractor or its Subcontractors or any employee of any of them.

14.INSURANCE
  The Contractor shall cause a Certificate of Insurance to be issued showing the following
  required coverage in no less than the minimum coverage limits listed below. The insurance
  companies providing coverage must have a B+:VI or better rating in the current edition of Best’s
  Key Rating Guide. The Contractor must agree to maintain such insurance for the duration of the
  project or the term for which services will be rendered.

       A. Worker’s Compensation and Occupational Diseases            Illinois Statutory Limits
          Employer’s Liability (Part B)                              $500,000 per occurrence
       B. Commercial General Liability
             Combined Single Limit                                   $1,000,000 per occurrence
                      OR
             Bodily Injury                                           $1,000,000 per occurrence
             Property Damage                                         $1,000,000 per occurrence
       C. Commercial Auto Liability
             Combined Single Limit                                   $1,000,000 per occurrence
                      OR
             Bodily Injury                                           $1,000,000 per occurrence
             Property Damage                                         $1,000,000 per occurrence



                                                                                      Appendix XI. 4
                                                                                         RFP No.1JLJ505


  Umbrella liability insurance may be used to meet the general liability coverage limit
  requirements.

  Subcontractors must comply with the same insurance coverage requirements as the Contractor.
  Subcontractors shall submit the required Certificate of Insurance through the primary
  Contractor.

  With respect to the required Commercial General Liability insurance, The Board of Trustees of
  the University of Illinois shall be named as an additional insured. In order to meet this
  requirement, the following wording should appear on any Certificate of Insurance provided:
  “The Board of Trustees of the University of Illinois is an additional insured for any liability
  incurred by the University arising from the activities of the Contractor and/or Subcontractor
  performing work on behalf of the Contractor.”

  The Contractor shall furnish any original Certificate(s) of Insurance evidencing the required
  coverage to be in force on the date of this Contract, and any renewal Certificate(s) of Insurance
  if coverage has an expiration or renewal date occurring during the term of this Contract to the
  University of Illinois, Purchasing Division, 616 E. Green, Suite 212, Champaign, IL 61820. The
  receipt of any certificate does not constitute Contract by the University that insurance
  requirements have been met. Failure of the University to obtain certificates or other insurance
  evidence from the vendor/contractor shall not be deemed a waiver by the University. Failure to
  comply with insurance requirements may be regarded as a breach of contract terms.

15. COVENANT AGAINST CONTINGENT FEES
  The Contractor warrants that no person or selling agency has been employed or retained to
  solicit or secure this Contract upon a contract or understanding for a commission, percentage,
  brokerage, or contingency fee, excepting bona-fide employees or bona-fide established
  commercial or selling agencies maintained by the Contractor for purposes of securing business.
  For breach or violation of this warranty, the University shall have the right to annul this Contract
  without liability, or, in its discretion, to deduct from the Contract price or consideration, or
  otherwise recover, the full amount of such commission, percentage, brokerage or contingent
  fee.

16.DELAY
  Neither party hereto shall be liable in damages for any delay or default in performing its
  respective obligations under this Contract if such delay or default is caused by conditions
  beyond its control. Such conditions include but are not limited to, acts of God, government
  restrictions, strikes, fires, floods, or work stoppages, or acts or failures to act of third parties. So
  long as any such delay or default continues, the party affected by the conditions beyond its
  control shall keep the other party at all times fully informed concerning the matters causing the
  delay or default and the prospects of their ending.

17.COMPLIANCE WITH LAWS
  The Contractor agrees to comply with all laws, statutes, regulations, rulings, or enactments of
  any governmental authority. The Contractor shall obtain (at its own expense) from third parties,
  including state and local governments, all licenses and permissions necessary for the
  performance of the work.




                                                                                           Appendix XI. 5
                                                                                        RFP No.1JLJ505



18.TAXES
  The University is an instrumentality of the State of Illinois, and as such it is exempt from
  Federal Income Tax under Sections 115 and 501(c)(3) of the Internal Revenue Code
  and is exempt from State of Illinois Income Tax in accordance with the Illinois Income
  Tax Act (35 ILCS 5/205). However, the University is subject to Federal and State of
  Illinois Income Tax only if, and to the extent, it has unrelated business taxable income.
  In addition, the University is exempt from payment of state and local Retailers'
  Occupation Tax, state and local Service Occupation Tax, state Use Tax, and state
  Service Use Tax, as provided by Illinois law. Certificates of exemption will be provided
  upon written request.

19.GOVERNING LAWS
  This Contract is to be governed and construed in accordance with the laws of the State of
  Illinois.

20.WAIVER
  The failure of either party hereto at any time or times to enforce any provision of this Contract shall
  in no way be construed to be a waiver of such provisions or to affect the validity of this Contract or
  any part hereof, or the right of either party thereafter to enforce each and every provision in
  accordance with the terms of this Contract.

21.CONFIDENTIALITY
  Any information furnished by the University shall be treated as confidential. The Contractor shall
  not disclose information unless specifically authorized and required to do so by law. The
  Contractor is hereby advised that any part of this contract or any materials provided by the
  contractor and marked as confidential, proprietary, or trade secret, can only be protected to the
  extent permitted by Illinois Statues.

22.NON-LIABILITY
  In no event shall the University be liable for any claims or liabilities arising out of the use of any
  libelous or other unlawful matter contained in data furnished by Contractor under this Contract.

23.ACKNOWLEDGMENT OF SPONSORSHIP
  The Contractor agrees not to use the name of the University in advertising or for any other
  commercial purpose without the prior written approval of the University. The Contractor may be
  required to acknowledge sponsorship of work performed under this Contract.

24.PATENT AND COPYRIGHT
  The Contractor and its Surety shall pay for all royalties and/or license fees and assume all costs
  incident to the use in performance of the work or the incorporation in the work of any invention,
  design, process, product or device which is subject to patent or copyrights held by others, and,
  additionally, shall defend all suits or claims for infringements of any patent or invention right or
  copyrights involved in the items furnished hereunder.

  The Contractor and its Surety shall hold and save the University and their officers, agents,
  servants and employees harmless from liability of any nature or kind, including cost and
  expenses, for, or on account of, any patented or unpatented invention, process, article or




                                                                                          Appendix XI. 6
                                                                                        RFP No.1JLJ505


  appliance furnished in the performance of the Contract including its use by the University,
  unless otherwise specifically stipulated and agreed to in this Contract.

25.CERTIFICATIONS BY CONTRACTOR
  Willfully falsifying certifications or affirmations may subject Contractor to criminal penalties
  including fines and/or imprisonment.
            25.1 EMPLOYMENT STATUS
          The Contractor certifies that if any of its personnel are an employee of the State of
          Illinois, they have permission from their employer to perform the service.
           25.2 ANTI-BRIBERY
          The Contractor certifies it is not barred under 30 Illinois Compiled Statutes 500/50-5(a)
          from contracting as a result of a conviction for or admission of bribery or attempted
          bribery of an officer or employee of the State of Illinois or any other state.
           25.3 LOAN DEFAULT
           If the Contractor is an individual, the Contractor certifies that he/she is not in default for
          a period of six (6) months or more in an amount of $600 or more on the repayment of
          any educational loan guaranteed by the Illinois State Scholarship Commission made by
          an Illinois institution of higher education or any other loan made from public funds for
          the purpose of financing higher education (5 ILCS 385/3).
           25.4 CONVICTED OF FELONY
          The Contractor certifies that it is not barred pursuant to 30 ILCS 500/50-10 from
          conducting business with the State of Illinois or any agency as a result of being
          convicted of a felony and also certifies in accordance with 30 ILCS 500/50-10.5 that no
          officer, director, partner or other managerial agent of the contracting business has been
          convicted of a felony under the Sarbanes-Oxley Act of 2002 or a Class 3 or Class 2
          felony under the Illinois Securities Law of 1953 for a period of five years prior to the
          date of the bid or contract. The Contractor acknowledges that the contracting agency
          shall declare the contract void if this certification if false.
           25.5 BARRED FROM CONTRACTING
          The Contractor certifies that it has not been barred from contracting as a result of a
          conviction for bid-rigging or bid rotating under 720 Illinois Compiled Statutes 5/33E or a
          similar law of another state.
            25.6 DRUG FREE WORKPLACE
          The Contractor certifies that it is in compliance with the Drug Free Workplace Act (30
          Illinois Compiled Statutes 580) as of the effective date of this Contract. The Drug Free
          Workplace Act requires, in part, that Contractors with twenty-five (25) or more
          employees certify and agree to take steps to ensure a drug-free workplace by informing
          employees of the dangers of drug abuse, of the availability of any treatment or
          assistance program, of prohibited activities and of sanctions that will be imposed for
          violations; and that individuals with contracts certify that they will not engage in the
          manufacture, distribution, dispensation, possession, or use of a controlled substance in
          the performance of the Contract.
           25.7 INTERNATIONAL BOYCOTT
          The Contractor certifies that neither it nor any substantially owned affiliated company is
          participating or shall participate in an international boycott in violation of the provisions
          of the U.S. Export Administration Act of 1979 or the regulations of the U.S. Department
          of Commerce promulgated under that Act (30 ILCS 582/1).


                                                                                          Appendix XI. 7
                                                                               RFP No.1JLJ505


  25.8 NON-DISCRIMINATION AND EQUAL EMPLOYMENT OPPORTUNITY
 The Contractor agrees to comply with applicable provisions of the Illinois Human Rights
 Act (775 Illinois Compiled Statutes 5), the U.S. Civil Rights Act, the Americans with
 Disabilities Act, Section 504 of the U.S. Rehabilitation Act and the rules applicable to
 each. The equal opportunity clause of Section 750.10 of the Illinois Department of
 Human Rights Rules is specifically incorporated herein. The Contractor shall comply
 with Executive Order 11246, entitled “Equal Employment Opportunity”, as amended by
 Executive Order 11375, and as supplemented by U.S. Department of Labor regulations
 (41 C.F.R. Chapter 60). The Contractor agrees to incorporate this clause into all
 Subcontracts under this Contract.
  25.9 INTERNATIONAL BOYCOTT
The Contractor certifies that neither it nor any substantially owned affiliated company is
participating or shall participate in an international boycott in violation of the provisions of
the U.S. Export Administration Act of 1979 or the regulations of the U.S. Department of
Commerce promulgated under that Act (30 ILCS 582/1). This Act applies to contracts of
$10,000 or more.

 25.10 RECORD RETENTION AND AUDITS
 30 Illinois Compiled Statutes 500/20-65 requires the Contractor (and any
 Subcontractors) to maintain, for a period of three (3) years after the later of the date of
 completion of this Contract or the date of final payment under the Contract, all books
 and records relating to the performance of the Contract and necessary to support
 amounts charged to the University under the Contract. The Contract and all books and
 records related to the Contract shall be available for review and audit by the University
 and the Illinois Auditor General. If this Contract is funded from contract/grant funds
 provided by the U.S. Government, the Contract, books, and records shall be available
 for review and audit by the Comptroller General of the U.S. and/or the Inspector
 General of the federal sponsoring agency. The Contractor agrees to cooperate fully
 with any audit and to provide full access to all relevant materials. Failure to maintain the
 required books and records shall establish a presumption in favor of the University for
 the recovery of any funds paid by the University under this Contract for which adequate
 books and records are not available.
25.11 TATE-APPROPRIATED FUNDS
  If this Contract is funded from State of Illinois-appropriated funds, the Contractor
 understands that this Contract is subject to termination and cancellation without any
 penalty, accelerated payment, or other recoupment mechanism as provided herein in
 any fiscal year for which the Illinois General Assembly fails to make an appropriation to
 make payments under the terms of this Contract. In the event of termination for lack of
 appropriation, the Contractor shall be paid for services performed under this Contract
 up to the effective date of termination.
25.12 DEBT CERTIFICATION
 The contractor or bidder certifies that it, or any affiliate, is not barred from being
 awarded a contract under 30 ILCS 500. Section 50-11 prohibits a person from entering
 into a contract with a State agency if it knows or should know that it, or any affiliate, is
 delinquent in the payment of any debt to the State as defined by the Debt Collection
 Board. Section 50-12 prohibits a person from entering into a contract with a State
 agency if it, or any affiliate, has failed to collect and remit Illinois Use Tax on all sales of
 tangible personal property into the State of Illinois in accordance with the provisions of
 the Illinois Use Tax Act. The contractor further acknowledges that the University may


                                                                                  Appendix XI. 8
                                                                                     RFP No.1JLJ505


        declare the contract void if the preceding certification is false or if the contractor, or any
        affiliate, is determined to be delinquent in the payment of any debt to the State during
        the term of the contract.
        25.13 LABOR CERTIFICATION
        The contractor certifies in accordance with 30 ILCS 583/10 that no foreign made
        equipment, materials, or supplies furnished to the State under the contract have been
        produced in whole or in part by forced labor, convict labor, or indentured labor under
        penal sanction.
        25.14 ENVIRONMENTAL CERTIFICATION
       The contractor certifies in accordance with 30 ILCS 500/50-12 that it has not been found
       by a court or the Pollution Control Board to have committed a willful or knowing violation
       of the Civil Penalties of the Environmental Protection Act (415 ILCS 5/42) for a period of
       five years prior to the date of the bid or contract. The contractor acknowledges that the
       contracting agency shall declare the contract void if this certification is false.



26    PARKING
The University provides no free parking for contractors, their employees or representatives.
Contact the University campus parking office for availability of parking in the University’s lots. All
vehicles belonging to the Contractor shall clearly display parking permits issued by the
University campus parking office.

Travel expenses will be reimbursed at rates in accordance with Section 15 of the Business and
Financial Policies and Procedures Manual of the University of Illinois Business Affairs,
www.obfs.uillinois.edu/manual/#s15




                                                                                       Appendix XI. 9
                                  RFP No.1JLJ505



           RFP # JLJ505


       Digital Library Products




         APPENDIX XII


CERTIFICATIONS AND PREFERENCES
 When submitting your response, please use the mailing label below—be sure to enter
 the Bid or RFP number. This will direct your response to the correct address and alert
 Purchasing Division staff to provide special handling.




  Please check if you
  are submitting a no bid.

                                 UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN
Bid/RFP #1JLJ505                 PURCHASING DIVISION
                                 TECH PLAZA, SUITE 212
                                 616 EAST GREEN STREET
                                 CHAMPAIGN, IL 61820-5752

								
To top