SOURCES SOUGHT
70 -- Print Procurement Search Engine Refresh
- Notice Date
- 9/1/2010
- Notice Type
- Sources Sought
- NAICS
- 334119
— Other Computer Peripheral Equipment Manufacturing
- Contracting Office
- Government Printing Office, Acquisition Services, Acquisition Services, 732 North Capitol Street, NW, Washington, District of Columbia, 20401
- ZIP Code
- 20401
- Solicitation Number
- GPORFI0002
- Archive Date
- 10/15/2010
- Point of Contact
- Arza E. Gardner, Phone: 202-512-1488
- E-Mail Address
-
agardner@gpo.gov
(agardner@gpo.gov)
- Small Business Set-Aside
- N/A
- Description
- This Request for Information (RFI) is issued for market research, budgetary and planning purposes only. The United States Government Printing Office (GPO) is exploring search engine technology that could be used to replace the existing FAST Enterprise Search Platform used by the Federal Digital System (FDsys). The opportunity expressed in this RFI is referred to as Search Engine Refresh (SER) and the goal of SER is to identify candidate technologies that can be inserted with the least impact to FDsys. GPO has identified several high-level constraints which should be factored into any response to this RFI: GPO has particular interest in search engine technology that is Linux based, and supports high availability and high performance indexing and search operations on very large volumes of structured (in XML) and unstructured enterprise content. GPO wishes to reuse as much of the current infrastructure to operate the replacement search engine as possible. This includes a cluster of Red Hat enterprise servers, and NetApp NAS and SAN storage. GPO seeks a replacement search engine that provides robust consistency of the documents it indexes and serves in response to search queries. Stability of the indexes and accuracy of the search results are the key characteristics desired by GPO. GPO is open to vendor-proprietary technology, as well as open source based solutions for this procurement. The terms of your product and your proposed product are used interchangeably in this RFI to refer to either category of the solutions. Background The GPO is the Federal government's primary centralized resource for gathering, cataloging, producing, providing, and preserving published U.S. Government information in all its forms. Since its inception, under the authority of Title 44 of the U.S. Code, GPO has offered Congress, the courts, and government agencies a set of centralized services that enables them to easily and cost effectively produce printed documents. GPO has offered these publications for sale to the public and made them widely available for no fee through the Federal Depository Library Program (FDLP). In January of 2009 GPO launched the Federal Digital System (FDsys) - a complex information management system delivering world-class search capability. The eventual scope of FDsys includes all known Federal Government documents within the scope of GPO's Federal Depository Library Program (FDLP). This content is entered into the system and then authenticated and catalogued according to GPO metadata and document creation standards. Content currently includes text and associated graphics, but will also include video and sound and other forms of content that emerge. Opportunity GPO is seeking to better understand the technology roadmaps of possible solutions that can seamlessly replace the existing FDsys search engine. Making your Capabilities Known - Requested Information: Vendors should furnish the following information (Word or PDF file) to GPO: Capability Statement White Papers Answers to Mandatory Questions Comments or Questions on SER Capability Statement: Keeping SER objectives in mind please identify any technology solutions that would meet our requirements. Any submitted capability statement must be 10 pages or less and contain no marketing material. Please also list company points of contact and GSA Schedule number (if applicable). White Paper: Similar Solutions or Systems: Vendors may also submit a separate document that summarizes the vendor's work with similar search technology or systems. The document must be 20 pages or less; however, up to three (3) white papers may be submitted provided that each represents a discrete system or program. Mandatory Questions: Answers to the following questions are mandatory. In your response, answer the following questions as briefly and concisely as possible. Please limit your response to each question to no more than 500 words and please include optional diagram or diagrams required. (1) What constraints does your product place on choices for operating system, server type, networking, and storage architecture? (2) What is the recommended operating system, server type (PC, blade, SMP, etc.), networking, and storage architecture for hosting your product? (3) Describe the suggested licensing model of your proposed product. (4) Describe the architecture of the main components (if applicable) of your proposed product. The components should include but are not limited to: index, search, application integration for content feed and search. (5) What is the recommended number and type of servers and storage capacity for supporting your product? Assumptions are: 20,000 concurrent users logged on to the system, less than 2 second search response time is required, and the system contains 500 terabytes of source documents that are full text indexed. How does the server and storage sizing change if we double the size of the indexed documents? How about quadrupling? (6) What is the strategy of your proposed product for scaling the system in terms of both performance and availability? How does the server and storage sizing change if we double the size of the indexed documents? How about quadrupling? (7) How is the query per second (QPS) defined for your proposed product? What QPS is required to support the 20,000 concurrent users performing browse and search operations? (8) What document formats does your proposed product support for indexing (e.g. Text, PDF, Word, etc). Provide a detailed list. (9) What languages, in addition to English, does your proposed product support for indexing and search? (10) How does your proposed product support out-of-box and custom taxonomy? (11) Does your proposed product support the XPath/XQuery based search for structured data in XML? If yes, describe the key architecture and design artifacts. If not, what is the recommended approach to take advantage of the XML metadata for indexing with your proposed product? (12) How large is your index size compared to the indexed document size? (13) Are there any benchmark results available for index and query performance? (14) With constant updates to the indexes, what is recommended procedures to operate and maintain a stable and high performance search indexes of your proposed search engine? (15) How does your proposed product support the capability for monitoring, auditing and correcting (if applicable and necessary) the indexes to ensure the stability of the indexed documents? (16) How does your proposed product support integration of custom search applications? Describe the API architecture of your proposed search engine. (17) What is the recommended approach for re-indexing the entire dataset, if necessary, without system downtime for serving the search results? Is there any matrix available regarding the size of dataset and performance for the re-indexing? (18) Does your product support replication of its indexes (backup, failover, etc.), and any associated data if applicable, to standby systems? If yes, describe high-level architecture and key features. What is the recommended continuity of operations (COOP) approach with your product? (19) Are there any features of FAST that your proposed product would leverage as part of the search engine replacement? (20) Have you transitioned from FAST ESP to the proposed product? If yes, list any challenges, risks or issues faced. (21) Is there a limit to the number of documents returned by a search? If so, what is the limit and why is this a constraint? (22) Describe how your proposed search engine is able to filter search results based on custom fields. Does your proposed search engine include any out-of-the-box filters? If your proposed search engine includes out-of-the-box filters, can these filters be modified to include and exclude specific terms? Does your proposed search engine support the ability to apply different filters to different collections of documents? (23) Describe how relevancy ranking can be configured in your proposed search engine. Does your proposed search engine support multiple relevancy ranking profiles? (24) Is there a limit on the size of a document that can be indexed in your proposed search engine? If so, what is the limit and why is this a constraint? (25) Describe how your search engine is able to support query operators such as Boolean, proximity, and field operators. (26) Describe how your proposed search engine is able to apply different indexing parameters to different collections of documents? (27) Describe how your proposed search engine is able to apply different query parameters to different collections of documents? (28) Describe how your proposed search engine is able to handle adding, updating, and deleting documents from the index. (29) Describe how your proposed search engine returns results in XML that can be formatted for display to a user. Does your proposed search engine support the ability to include different information in search results for different collections of documents? Questions and/or Comments: Leading up to a potential Industry Day event, GPO may release additional documents to industry for comment and review. As the material is submitted, vendors should identify any gaps in the documentation - including concerns about GPO's approach to SER. Vendors should also identify any areas of search where technology may be lagging, identify missing or ambiguous requirements, capabilities or functions and provide the Government with any other general comments or concerns. Where possible, feedback should include specific comments and suggestions for refining the documents to reflect clear guidance to industry and industry best practices. Capability Statements, White Papers and Questions/Comments on the Search Engine Refresh program must be submitted to int@gpo.gov. You must also CC hjackson@gpo.gov and agardner@gpo.gov. For consideration, please use the subject heading "SER Market Research: YOUR COMPANY NAME" ). Faxed copies are not acceptable. NOTE: All capability statements, white papers and questions or comments must be submitted by September 30, 2010. Informational Meeting (Industry Day) Sometime in the Calendar Year 2010 GPO will host an industry day event during which the Government will further explain our vision, goals and objectives for SER. Background Material All background material will be made available through the Program Management Office website as it becomes available at http://www.gpo.gov/vendors/ser.htm. Original Point of Contact Contracting Officer - TBD U.S. Government Printing Office, Acquisition Services Division, 732 North Capitol Street, NW, Room A332, Washington, DC 20401 Place of Performance Location: Government Facility, U.S. Government Printing Office Address: 732 North Capitol Street, NW, Carl Hayden Room, Washington, DC 20401
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/spg/GPO/PSPSD/WashingtonDC/GPORFI0002/listing.html)
- Place of Performance
- Address: Government Facility, U.S. Government Printing Office, 732 North Capitol Street, NW, Carl Hayden Room, Washington, District of Columbia, 20401, United States
- Zip Code: 20401
- Zip Code: 20401
- Record
- SN02263911-W 20100903/100901235504-1acdc9a123edaa463854c484fb65bb9d (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |