20240410_PWS_RevA_ABMC CMS.pdf

PERFORMANCE WORK STATEMENT

FOR

Museum and Archives Collection Management System (CMS)

Rev A

April 10, 2024

A. Introduction

The American Battle Monuments Commission (ABMC) is an independent agency that administers, operates, and maintains 26 permanent American military cemeteries and 32 federal memorials, monuments, and markers, located in 10 foreign countries, the U.S. Commonwealth of the Northern Mariana Islands, and the British Dependency of Gibraltar; four of the memorials are located within the United States. ABMC personnel are located in the Headquarters Office in Arlington, VA, the Office of Overseas Operations in Paris, France, and at 26 American military cemeteries. ABMC is also responsible for establishing and maintaining new memorials as directed by Congress.

The Commission is composed of up to 11 members and a Secretary of the Commission, which are all appointed by the President. The Secretary is responsible for the day‐to‐day operation of the Commission.

English is the primary verbal and written language at all ABMC sites.

B. Background and Objectives

ABMC currently uses a hosted instance of a museum Collection Management System (CMS) which contains a centralized database that allows ABMC staff to digitally catalog and store detailed information about curatorial artworks, artifacts, specimens, and other items in their collections. The existing CMS provides an interface for creating, editing, and updating records, enabling curators, registrars, and researchers to access accurate and up-to-date information about each item. The current system also supports the inclusion of multimedia files, such as high-resolution images, videos, and audio recordings, enriching the documentation and enabling a more immersive experience for users.

ABMC staff use the current CMS to perform complex searches based on various criteria, including artist, title, date, medium, provenance, and more. This facilitates efficient research, cross-referencing, and data analysis, and helps make informed decisions about our collections. ABMC also utilizes the CMS’s comprehensive collections management features, including tools for inventory management, loan tracking, conservation documentation, and object movement tracking. These features enable ABMC to track the location and condition of each item, manage loans to other institutions, generate reports, and maintain a complete audit trail of activities.

ABMC museum object collections and archives seek to improve users and staff experiences with a central system for the management and administration of ABMC object and archive collections. They seek to accomplish this by acquiring a license for access to and implementation of a comprehensive, integrated, software-as-a-service (SaaS) Museum and Archives Collection Management System to replace the current hosted museum CMS, current front-facing digital archives system, and assorted decentralized archival collections data, which are insufficient for the collection’s needs.

Objective

The objective of this Contract is to acquire software licenses and support which shall provide access to a SaaS system that provides unified and efficient management of all resources that ABMC museum and archives owns, licenses, stewards, and makes available to end users for discovery and delivery. In addition, the licenses shall provide access to a system that enables ABMC museum and archives users quick and accurate access to electronic, physical, and local collections, bibliographic data, and full text content of its electronic assets.

The product shall be an established enterprise-class software solution to manage ABMC museum objects and archival collections through the use of an online accessible CMS. The solution may be either one single CMS housing both collections, or two separate modules from the same Contractor. The current curatorial collection consists of approximately 5,000 object entries (with approximately 25,000 media attachments), which must be migrated into the new CMS.

C. Scope

The scope of this work is to implement, configure, maintain, and train users on a new hosted SaaS CMS. A successful solution shall meet the requirements outlined in the IT Security and Privacy Requirements.

Contractor shall provide in-depth system training and user guides for ABMC users worldwide. Contractor shall design and develop a CMS to digitally manage the collections that will meet all the documented requirements.

Contractor shall provide the necessary configuration for the optimal functioning of the solution, considering the number of records and images which will include data migration from existing systems (approximately 5,000 items with approximately 25,000 media attachments), as well as those which shall be required to be bulk uploaded from spreadsheets or CSV files (approximately 14,000 item level PDFs and 3,500 collection level PDFs). It must also anticipate the evolution of the database and plan for the future records and images that will be added.

C.1. Collections Management System (CMS)

The scope includes the tools for uploading scanned and born digital records for researchers worldwide to access object collections and archival content in a modern, secure, and user-friendly manner. The system shall be designed to handle large, heterogeneous collections that have complex cataloging requirements and require support for a variety of metadata standards and media formats along with all necessary technical services to acquire, design, test, implement, secure, operate, and maintain a comprehensive CMS with effective internal controls to secure and safeguard electronic records. Core functionality of the system shall include workflows that allow for creation and movement of collection hierarchies, as well as essential elements of administration, to include accessioning, description, controlled taxonomy, thesaurus services, authority control, loan management, custodial management/inventory control, and search capabilities. Key functionality shall be based on:

1. Data management

a. Workflows that allow for creation and movement of collection hierarchies,

b. User experience and navigation control,

c. Management at both the collection and item level,

d. Supports core functions of administration, i.e.: object management, appraisal, accessioning, description, preservation administration, and Boolean search capabilities,

e. Organization of collections by subject or topic.

2. Metadata management

a. Use one or more standard schemas, including EAD, MODS, Dublin Core, etc., including those used by art galleries and museums.

b. Application of bulk metadata updates and or ingestion from existing systems or databases,

c. Authority and taxonomy control,

d. Thesaurus, nomenclature, and controlled vocabulary, such as Getty vocabularies, Art &

Architecture thesaurus, material thesaurus (for object description), geographical thesaurus (for location description), Library of Congress, and Nomenclature for Museum Cataloging:

https://page.nomenclature.info/apropos-about.app?lang=en (including associated updates).

e. Tagging functionality,

f. Multilingual, with support for all modern languages.

3. Administration

a. Standard reports and configurable dashboards across all functions including ingest, access, preservation, and storage activity,

b. Support of multiple file (including media) types,

c. Web publishing capabilities across multiple platforms (browser-agnostic).

C. 2 Compliance with Federal Requirements

Contractor shall ensure that the CMS complies with all relevant Federal government requirements and guidelines, including Enterprise Architecture, security, privacy, disaster recovery, etc.

D. Estimated Period of Performance (POP):

The period of performance is to be negotiated following the contract award. It is anticipated to include a base year plus four (4) consecutive option years.

E. Place of Performance

Work shall be performed off-site. No travel is expected as part of this Contract.

Headquarters address is:

2300 Clarendon Blvd., Ste 500 Arlington, VA 22201

F. Government Furnished Equipment

No GFEs will be provided for this contract. Proposers shall include all hardware, software, licenses, and equipment needed to fulfill the project’s scope. Secure data transfer for migration will be discussed and coordinated with the contractor.

https://page.nomenclature.info/apropos-about.app?lang=en

G. Specific Requirements

The system license shall include the following features:

G.1 General Requirements

a) Four (4) administrative logins with additional non-administrative limited edit rights.

b) Public internet (web) interface to front end only of the system with unlimited public access.

c) Ability to limit access to certain collections to the ABMC Zscaler Gov instance IP range (for internal, non-public, access only).

d) Ability to create metadata for and administrate both Museum and Archives Collections and supporting materials

e) Minimum cloud storage of 1 TB (storage pricing tiers to be provided as part of section J response to

RFP - INSTRUCTIONS FOR SUBMITTING QUOTES AND EVALUATION)

f) Customizable data input screens per individual user

g) Robust and customizable system search capability with full page search display

h) Spellcheck (system or browser based)

G.2 Technical Support and Training

a) Eastern Standard Time business hours access to ticketing support accessible via phone, email or company online system

b) System implementation virtual training and system support for four (4) administrative users

c) Access to training portal with documentation and recorded training

I. The Contractor shall identify and provide complete and comprehensive software system training for ABMC staff administrators using and managing the system. This training shall include, but is not limited to:

• Planning and setting up the structure and hierarchy of collections;

• Performing database management functions;

• Monitoring and managing the system's performance.

II. The Contractor shall provide all instructional materials, including printed manuals, audio, video, interactive self-paced personal computer programs, and complete equipment operating instructions for all technical and operational training classes.

III. Product upgrades shall be included as part of the quote. Contractor shall provide additional training associated with product upgrades upon government request at no additional cost.

d) Support and implementation of website configuration and branding standards (logo, fonts, color pallet, etc.). Branding standards shall include the following elements:

i. Branding Continuity: Ensure consistency in logos, colors, and typography across all pages, to develop consistent visual identity that aligns with ABMC’s branding.

ii. User Experience: Design an engaging interface to enhance positive user interaction with intuitive navigation, taking into consideration how users research, view and share information with their social communities.

iii. Information Filtering: Implement functionalities for easy access and sorting of information.

iv. Simplicity: Maintain a clean, uncluttered design for straightforward navigation and content presentation.

v. Compliance with Standards: Adhere to guidelines including accessibility (Section 508 compliance), cybersecurity, and all relevant federal requirements.

vi. Simplicity and Clean Design: Develop a clean, uncluttered layout, focusing on simplicity and ease of use. Prioritize content and features to enhance the overall user journey and position ABMC as a trusted source of information.

ABMC branding standards guidelines can be found as a separate attachment in the provided RFP documentation.

G.3 Reporting and Analytics

a) Customizable report generation

b) Ability to export customizable reports in both/either a delimited (Tab or Comma) text file or Excel spreadsheet file

G.4 System Updates and Data Backups

a) Annual updates with notifications of new version releases.

b) Daily automatic database backups to the Cloud with on call backups and ability to revert to previous versions, minimum of 30 days.

G.5 Workflow

a) Realtime database indexing on the front and back ends

b) The capability to separate records, create record sets, and employ multiple tagging

c) Item information tracking of the following but not limited to:

• Exhibition history

• Inventory status

• Deaccession

d) Item barcode scanning and printing capability

e) Ability to attach finding aids and supporting documents including but not limited to .docx and .pdf

f) Thumbnail image in item summary capability

g) System needs to support images, documents, audio, and video formats, including: .png, .jpg, .mp4, mp3, .tiff, .zip folders, .doc/.docx, .pdf

h) Ability to create multiple relationships between items via a related objects function and/or tab

i) Front end and back-end item and resource linking to show connections between objects/archival materials/photos (example: Suggested Related Items)

G.6 Metadata

a) Standard metadata elements associated with objects and archives, with ability to “turn on/off” those which are appropriate for each record type.

i. An objects database metadata fields (with field type as associated comments) of the existing CMS is included in the RFP package. Elements should be the same or offer similar alternatives.

b) Support of metadata formats for transforming and import/export including, but not limited to: .csv, .xml, EAD3, .json

c) Ability to make global edits to all instances of a metadata field

d) Customizable controlled vocabulary and field names with the ability to link related terms

G.7 Data Migration

a) Assistance with data migration

i. Contractor shall develop a Data Migration Strategy Plan regarding data conversion and migration from the incumbent platform which currently includes approximately 5,000 records (and related media attachments), documents and photographs, as well as associated spreadsheets or other databases, to the implemented system.

ii. Contractor shall be responsible for the extraction of all records, metadata, and file attachments and the translation function of the conversion process.

iii. Contractor shall be responsible for the overall successful execution of the data migration, which includes all previously managed records their associations and attachment (and metadata crosswalks if necessary).

b) Import and export documents and metadata (able to work with CSV, Word documents, and Excel spreadsheet formats) including existing finding aids with supporting documentation and container lists

i. ABMC has recently completed several digitization contracts (documents, photographs, & blueprints) which also include associated CSV files of metadata corresponding to each record. Contractor shall upload both the digital file and its associated metadata using appropriate crosswalks, as necessary, for each data element. Approximately 17,500 (14,000 item level blueprints and 3,500 collection level records) digital files and associated metadata will require batch upload by the Contractor.

c) Provide a trial migration for organization and customization finalization

G.8 Security

General:

Contractors, contractor personnel, subcontractors, and subcontractor personnel shall be subject to the same Federal laws, regulations, standards, and ABMC policies regarding information and information system security.

Authority to Operate:

Contractor shall undergo an Assessment and Authorization of security and privacy controls and receive an Authority to Operate (ATO) from ABMC (see required security and IT documentation in section J as part of RFP submission - INSTRUCTIONS FOR SUBMITTING QUOTES AND EVALUATION).

Contractor shall provide, at a minimum, the following documents to support ABMC’s review of the system:

1. System security plan (SSP)

2. Contingency & Business Continuity Plan

3. Information Security Risk Assessment from an independent third party/auditor, provided at least annually, and must include the executive summary.

Post contract award, the Government will perform a review for a local ATO decision, required for go-live, and ongoing security and privacy assessments for continuous monitoring thereafter. The Government will determine the risk rating of identified vulnerabilities at least once per year. Contractor shall respond to the Government with an action plan and schedule to mitigate security or privacy risks found within 10 business days of notification of security or privacy risks. The Government will notify Contractor of whether or not the action plan and schedule are acceptable. Contractor shall implement the action plan according to the agreed-upon schedule.

The product’s security controls shall meet the requirements laid out in Security and Privacy Controls for Information Systems and Organizations NIST Special Publication 800-53 Revision 5. The level of security controls is based on the impact rating as defined in Standards for Security Categorization of Federal Information and Information Systems (FIPS Pub 199). The impact rating levels for this solution, based on NIST use cases (by security objective), are Integrity = Moderate, Availability = Moderate, and Confidentiality = Moderate.

Custom Software:

Custom software development and outsourced operations shall be located in the U.S. to the maximum extent practical. If such services are proposed to be performed abroad and are not disallowed by other ABMC policy or mandates, the contractor/subcontractor shall state where all non-U.S. services are provided and detail a security plan, deemed to be acceptable by ABMC, specifically, to address mitigation of the resulting problems of communication, control, data protection, and so forth. Location within the U.S. may be an evaluation factor.

Staffing:

Contractor or Subcontractor shall notify ABMC within five business days when an employee working on an ABMC system or with access to ABMC information is reassigned or leaves the contractor or subcontractor’s employ. The Contracting Officer (CO) shall also be notified immediately by Contractor or Subcontractor prior to an unfriendly termination.

G.9 Systems Infrastructure

a) The solution shall be delivered as a Software as a Service (SaaS) platform.

b) Contractor is responsible for all maintenance and upgrades during the term of the subscription.

c) The system will be accessible through modern web browsers.

d) All ABMC data stored in Contractor systems remains the exclusive property of the Government and

Contractor shall make no unauthorized copies of data without explicit direction by authorized agents of the Government. In the event of a migration of the data to a new system, Contractor is required to maintain the data until successful, stable migration (i.e. without data loss/corruption) is confirmed by the Government, for a minimum of 90 days from end of contract.

e) The system will undergo periodic penetration testing and vulnerability scans by agencies authorized by the government. The contractor will be responsible for remediating all vulnerabilities discovered and reported by these agencies.

f) System shall provide a means for single sign-on authenticating all administrative users and systems that access the environment and data. System shall allow for the configuration of access capabilities and permissions for each back-end user based on user type, user group, and customization of permissions for discrete elements of the dataset.

g) The authentication and permission configurations shall directly support the audit functions of the system.

h) Contractor shall provide any password, access, and auditing policies that will be used.

i) The security, network, server and equipment shall be monitored 24 hours a day, seven days a week and the monitoring shall provide a customizable log analysis and review.

j) Contractor shall provide the Government with its standard Service-Level Agreement (SLA) / plan to perform technical and administrative support including severity levels and standards for response time and service restoration.

k) The hosted solution shall demonstrate full redundancy for all critical components and at critical interfaces and demonstrate 99% uptime or higher outside of emergencies.

l) Contractor shall provide technical and administrative support for all system components for the entirety of the contract.

m) Contractor shall provide an online issue/ticket reporting system with tracking numbers enabling customer to monitor issue status from reported to resolved. The ticketing system shall allow the ability to view all open and closed tickets. If ticketing is separated by application, then one segment must be for system infrastructure.

n) Contractor shall provide a representative to track and monitor issues, plan and schedule upgrades, provide requested system information, and to serve as a primary point of contact for ABMC for non-technical/administrative support issues.

G.10 Authentication

a) Contractor shall work with ABMC’s IT department to configure its product to construct secure access permissions and implement integration with ABMC’s Single Sign On (SSO) solution for ABMC users.

G.11 Internet Protocol Version 6 (IPv6)

a) Contractor shall provide ABMC with a statement regarding its plans to implement IPv6, including timeframe and milestones.

G.12 Incident Response

a) Contractor shall ensure coordination of its incident response team with the OCIO specifically, any confirmed incident of a system containing ABMC data or controlling ABMC assets shall be reported to ABMC OCIO within 48 hours that results in unauthorized access, loss or modification of ABMC data, or denial of service affecting the availability of ABMC data. Contractor shall provide any application and operating system logs associated with an incident as well as a file system timeline for potentially compromised hosts and any additional files referenced during forensic analysis upon request. Logging must be enabled and available for a minimum of 90 days. If possible, Contractor shall provide memory dumps and forensic images of any ABMC systems that were possibly compromised.

Contractor shall restore ABMC data to the last known good state within ten working days.

G.13 Section 508

a) The product shall comply with Section 508 of the Rehabilitation Act (www.section508.gov ).

i. This contract vehicle is subject to Section 508 of the Rehabilitation Act of 1973 (29 U.S.C.

749d) as amended by the Workforce Investment Act of 1998 (P.L. 105-220). The Revised Section 508 Standards, which consist of 508 Chapters 1 and 2 (Appendix A), along with Chapters 3 through 7 (Appendix C), contain scoping and technical requirements for information and communication technology (ICT) to ensure accessibility and usability by individuals with disabilities. Compliance with these standards is mandatory for Federal agencies subject to Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C.

794d).

H. Functional requirements and product specifications

This task order aims to have the Contractor perform the development, implementation, and operational integration of its collections management system (CMS). The Contractor should have knowledge of controlled metadata elements, bulk importation options, contextual linkages between records, search optimization, and the best practices in collections management workflows to analyze business processes in a holistic and integrated context. The Contractor shall provide and support for the tasks as described below.

Number Solution Criteria Solution Description

Section A: Core collections management criteria

A.1 Acquisition and accessioning The management and documentation of the addition of objects or object lots to the collection

A.1.2 Unique system number automatically assigned (required)

The system can ensure that a unique system number is assigned to all objects or object lots.

A.1.3 Object number (required) The system can record a unique number identifying an object or specimens, including any separated parts. Protocols or functionality to avoid number duplication.

A.1.4 Object name (required) The system can record a description of the form, function or type of object.

A.1.5 Title (required) The system can record the name assigned to an object or group of objects by the artist/creator or collector at the time of origin or subsequent titles either specifically assigned or generally understood to refer to it.

A.1.6 Brief description (required) The system can record a text description of an object in approximately one sentence; normally used for administrative and identification purposes. It records the most important information from a number of separate descriptive units of information.

A.1.7 Object history note (desirable/optional )

The system can record the history of an object, including its creation, owners, Contractors and the circumstances surrounding such events. Record information here which has not been recorded elsewhere using controlled terminology.

A.1.8 Source/Provenance (required) The system can record source information (for example, acquisition source, title, surname, address) about objects or object lots.

A.1.9 Document management/control

The system will allow for uploaded documents associated with the accessions process (invoices, condition reports, etc.).

A.2 Location & movement control

The management and documentation of information concerning the current and past locations of all objects/object lots in the institution's care to ensure that the institution can locate any object at any time

A.2.1 Object location information (required)

The system can record where an object is located. See Location information for the place itself.

A.2.1.1 Record of permanent location (required)

The system can provide a record of the location where an object or object lot is normally displayed or stored (for example, permanent location).

A.2.1.2 Location search (desirable/optional)

The system can retrieve information about objects or object lots by location.

A.3 Cataloging The compilation and maintenance of primary information describing, formally identifying, or otherwise relating to objects in the collection

A.3.1 Object number (required) The system allows a unique number identifying an object or specimens, including any separated parts. Protocols or functionality to avoid number duplication.

A.3.2 Object name (required) The system can display a description of the form, function or type of object.

A.3.3 Number of objects (required) The system allows the display of the number of objects at the next level down in an object record.

A.3.4 Title (required) The system can display a name assigned to an object or group of objects by the artist/creator or collector at the time of origin or subsequent titles either specifically assigned or generally understood to refer to it.

A.3.5 Dimension/size (required) The system can document an aspect of a part or component of an object being measured.

A.3.6 Conservation (required) The system can document associated conservation treatment notes, plans, or treatments.

A.3.7 Compulsory fields (required) The system shall denote compulsory/required fields, which must be filled in to validate the backup of a record.

A.3.7 Reminder features (desirable/optional)

Reminders or notification can be set up when some action needs to be taken (conservation treatment, exhibit rotation, etc.)

Section B: Other collections management criteria

B.1 Condition checking and technical assessment

The object aspects of a condition or technical assessment

B.2 Deaccessioning & disposal The management of object disposals (transfer, sale, exchange, or destruction) and deaccessions (documentation of the disposal)

B.2.1 Reason for disposal (desirable/optional)

The system can document the reason for disposal.

B.2.2 Disposal reference number (desirable/optional)

The system can generate a unique number for a particular disposal action or event.

B.2.3 Disposal method (desirable/optional)

The system can record the method by which an object is disposed of for example, sold, destroyed.

B.2.4 Deaccession date (desirable/optional)

The system can record the date on which an object is deaccessioned.

B.2.5 Disposal date (desirable/optional)

The system can record the date on which an object is disposed of.

B.3 Rights management The management and documentation of information about the reproduction of records

B.3.1 Copyright (required) The system can record the copyright information for both the master digital image and its surrogates.

B.4 Object management The ability to manage specific elements within the record or collection

B.4.1 Object or record links and or associations (required)

The system can create connections between several objects referenced in the database in order to establish hierarchical links or relationships between them

B.4.2 Variable classification (required)

The system allows for the organization within several levels of classifications (department, object classification, theme). These classifications should all be allowed to be searched in order to find similar types or subjects.

B.4.3 Associations (required) The system allows for the entry of associations, which can be specific individuals or locations which may be related to an object or record. The entry can show who worked on a specific aspect of a task (conservation), who moved an object, who cataloged the object, etc. These associations should be able to be searched on in order to find tasks or entries of the same person or location.

Section C: Extended functionality criteria

C.1 Public access features

C.1.1 Internet public access

The system can provide public access via internet.

C.1.2 Welcome display (required) The system allows the display of a user-defined introductory/welcome screen.

C.1.3 API (application programming interface) (required)

An API provides access to a third-party product to access and work with system data.

C.1.4 Online capacity (desirable/optional)

As well as online search, the system provides creation of tours and/or virtual exhibits or other displays.

C.1.5 Sharing (desirable/optional) The system allows sharing of items (for example, send a link or search result)

C.1.6 Mobile (required) The public access system supports use on mobile.

C.1.7 Alternate language (desirable/optional)

The system allows the selection of an alternate language by the public.

View selected fields (desirable/optional)

The system allows viewing only selected fields.

C.1.8 Search refinement (required) The system allows the public to refine searches, both by including other search criteria and amending existing ones.

C.1.9 Print control (required) The system allows the institution to control the format, content and the number of records to print.

C.1.10 Printing of images (required) The system allows images to be printed by the public over the web.

C.1.11 Visitor statistics (desirable/optional)

The system can run statistics on visitors, hits, etc.

Section D: Other information management functions

D.1 Metadata administration The way in which metadata is stored, tracked and recognized

D.1.1 Metadata standards (required) The system can follow any particular standard for recording metadata about multimedia files, including compliance with the DACS, EAD, MARC, ISAD (g), and Dublin Core archival standards

D.1.2 Metadata import/export (required)

The system allows metadata about multimedia files to be imported/exported (for example, Exchangeable Image File Format (EXIF) or CSV files).

D.1.3 Metadata search (required) The metadata about multimedia files can be searched (for example, the user wants to find all the images created with a Canon scanner) in the system.

D.1.4 Recognition of metadata

The system can recognize existing metadata produced by digital equipment (for example, recognize and automatically read in metadata produced by a digital camera).

D.1.5 Language of metadata (required)

The system flags the language of the metadata.

D.1.6 Display of metadata (required) The system allows users to view metadata for specified data fields, such as classification fields, and files, such as image files.

D.2 Multimedia files The support and handling of metadata for multimedia files

D.2.1 Indexing (required) The system's multimedia files are indexed.

D.2.2 Sound files (required) The system supports sound files using standards supported by the institution.

D.2.3 Image Files (required) The system supports various common image file formats, such as *PDF, *, jpg, *.gif and *.tiff, as well as specific image file formats required by the institution.

D.2.4 Associated image files (required)

The system can associate image files to an object and the image files can be viewed within the system.

D.2.5 Streaming data files (required) The system can accept and deliver streaming data.

D.2.6 View both images and text (desirable/optional)

The system allows images and text to be viewed together on the same screen.

D.2.7 Automatic production of multiple image resolutions (desirable/optional)

The system can automatically produce images into multiple resolutions for display within the system, for reports generated by the system or for export.

D.2.8 Options for display of images (desirable/optional)

The system allows users to have access to non-destructive editing features, such as dynamic rotate or resizing, that only change the way the image is displayed.

D.2.9 Image text descriptions (desirable/optional)

The system allows for verbal descriptions and ALT tags.

D.2.10 Image captions (desirable/optional)

The system can record a caption that is to be displayed with the image.

D.2.11 Multimedia plug-ins (required) The system can use plug-ins required by the institution.

D.2.12 Export images (required) The system can export images in a number of formats. High resolution for publishing, lower resolution for PowerPoint, social media use, online use

D.3 Vocabulary control

D.3.1 Authority control For the purposes of this document, "authority" should be taken to mean a simple list of permissible terms (not arranged hierarchically) to be used during data entry and/or retrieval.

D.3.1.2 Develop authority lists (required)

Authority lists can be developed within the software or imported from third parties.

D.3.1.3 Fields with authority control (required)

The system allows the user to choose the fields for authority control.

D.3.1.4 Authorization to alter authority lists (required)

The system can control permissions to add, change, and delete terms in an authority list to ensure that a specific user is authorized to make changes.

D.3.2 Thesaural control For the purposes of this document, "thesaurus" is taken to mean a list of terms showing hierarchical, synonymous, and other relationships.

D.3.2.1 Developed thesauri (required) Thesauri can be developed within the software.

D.3.2.2

Fields with thesaural control

The user can choose the fields for thesaural control.

D.3.2.3 Thesauri for entry and validation (required)

The thesauri can be used to assist in the entry and validation of data in the system (e.g., user can browse and select from the thesaurus during data entry).

D.3.2.4 Thesauri for search (required) The system allows thesauri to be used to assist in the formulation of search criteria (for example, user can browse and select from the thesaurus to help select terms to enter as search criteria).

D.3.2.5 Authorization to alter thesaurus (required)

The system can provide a control over who can add, change, and delete terms in a thesaurus file.

Section E: User interface

E.1 Help features

E.1.2 Tutorial available (required) The system has an integrated tutorial.

E.1.3 On-line help (required) The system can provide on-line help.

E.1.4 Element help (desirable/optional)

The system allows a user to hover over a metadata element or function and receive more information or help as to its use

E.2 Data Entry

E.2.1 Mandatory fields (required) The system allows any number of fields to be flagged as mandatory.

E.2.2 Cut and paste (required) The system allows cut and paste operations (for example, cut a field and paste it to another field within the same document).

E.2.3 Data formatting (required) The system can support text format standards (italic, bold, underline, etc.).

E.2.4 Search and replace within record (required)

The system can offer a search and replace function within a single record during the data entry process (for example, identify a source name, search for the name within one record only, and replace with new text).

E.2.5 Spell checker (required) There is an on-line spell checker in the system which highlights the error.

E.3 Date formats

E.3.1 Date format (required) The system supports date formats required by the institution.

E.3.2 Unknown dates (required) The system allows unknown dates to be entered as such (for example, unknown).

E.4 User customization

E.4.1 Data entry screen(s) (desirable/optional)

The system allows users to customize the layout of data entry screens.

E.4.2 Data retrieval screen(s) (desirable/optional)

The system allows users to customize data retrieval screens (for example, on the data retrieval screen change a field label, retrieve and display a document).

E.4.3 Field tags (labels) (desirable/optional)

The system allows users to customize field tags (labels) on the data entry screen (for example, while in the data entry screen change a field label, display document).

E.5 Multilingual

E.5.1 Alternate language (required) The system can function in an alternate language.

E.5.2 Language selection at login time (desirable/optional)

The system allows an alternate language to be selected at login time.

E.5.3 Language selection on any screen (desirable/optional)

The system allows an alternate language to be selected from any screen.

E.6 Web integration

E.6.1 Access via internet (required) The system can provide access through a web browser.

E.6.2 Offline data entry (required) The system allows data collection offline and uploaded/imported later.

E.6.3 Consistent between platforms

The system can provide full functionality through a web browser.

E.6.4 Cross-platform browser support (required)

The system can operate in chrome, Firefox, Safari, Ede on PC and Mac.

E.6.5 Software as a service (SaaS) (required)

The system can be provided as a cloud-based Software as a service.

E.6.6 Scalable hosted storage (required)

The system can store large amounts of data, will be able to increase in response to repository growth.

E.6.7 Access via Mobile/Tablet (required)

The system can be used on a mobile device.

E.6.8 Metrics (required) The system can provide metrics on the online use of the collections (object views, object sharing).

E.6.9 Up-to-date data management (required)

The system offers a Java or web-based client for admin and data management.

E.6.10 Website branding The system can support configuration and implementation of branding standards across the platform.

E.7 Accessibility The system supports tools for ensuring the user interface and content is accessible to people with disabilities.

E.7.1 Alternative formats (required) The system supports alternate formats for accessibility.

E.7.2 Input methods (required) The system offers a choice of input methods (keyboard, touchscreen, speech).

E.7.3 Web Content Accessibility Guidelines (WCAG) Compliance (required)

The system is compliant with WCAG.

Section F: Query

F.1 General requirements

F.1.1 Query using native language (required)

A query can be executed using the query native language in the system.

F.1.2 Formatted screens (required) The system can use formatted screens to execute a query.

F.1.3 Query any field (required) A query can be run against any field in the system.

F.1.4 Boolean AND (required) The system allows the Boolean operator AND to be accepted.

F.1.5 Boolean OR (required) The system allows the Boolean operator OR to be accepted.

F.2 Wildcard searches

F.2.1 Right truncation wildcard (desirable/optional)

The use of wildcards at the end of a stem is always accepted (for example, book*).

F.2.2 Left truncation wildcard (desirable/optional)

The system allows the use of wildcards at the beginning of a stem (for example, *book).

F.2.3 Wildcard on any field ((desirable/optional)

The system allows the use of wildcards on any field.

F.2.4 Character substitution (desirable/optional)

The system allows the use of wildcards for any character substitution (for example, "sm*th" finds both "smith" and "smyth").

F.3 Query results

F.3.1 Save results (desirable/optional)

The system allows the results from a query to be saved for future use. (Not saving the query but saving the results from the query).

F.3.2 Export results (desirable/optional)

The system can export query results into excel documents.

F.3.3 View results in alternative format (desirable/optional)

The results of the query can be displayed and formatted in the data entry screen in the system.

F.3.4 Default format (desirable/optional)

The system has a default record display order.

F.3.5 Object display order (desirable/optional)

The system has a default field display order.

F.3.6 Access to related objects (desirable/optional)

The system can retrieve and display related objects based on their whole/part relationship (for example, retrieve a record with a whole/part relationship, display all related information).

F.3.7 Sort results (desirable/optional)

The system allows results from a query to be sorted by various fields (for example, perform a query, sort results on 3 different fields and display the documents).

F.3.8 Ascending (desirable/optional) The system allows results from a query to be sorted by various fields in ascending order (for example, perform a query, sort the results in ascending order, and display the documents).

F.3.9 Descending (desirable/optional)

The system allows results from a query to be sorted by various fields in descending order (for example, perform a query, sort the results in descending order, display the documents).

F.4 Features

F.4.1 Multiple field searches (required)

The system allows a search to be performed on multiple indexed and not-indexed fields.

F.4.2 Query hitlist (desirable/optional)

The system can browse through lists of previous queries.

F.4.3 Number of hits (required) The system can inform the user of the number of hits (query results).

F.4.4 Display of query results

Upon receiving the number of hits in a search, the system can give the option to proceed with the display.

F.4.5 Search refinement (desirable/optional)

The system can refine search results with new search criteria

F.4.6 Narrow the search scope (desirable/optional)

The system allows the scope of a result set to be narrowed

F.4.7 Filter search (required) Search results can be filtered by facets in the system.

F.4.8 Search history (desirable/optional)

The system can provide a facility for displaying previous search results.

F.4.9 Review results in query mode (desirable/optional)

The system can view the results from a query without having to exit the query function.

F.4.10 Modify query (desirable/optional)

Once a query has been executed, it can be modified for re-execution in the system.

F.4.11 Save query (desirable/optional)

A query can be saved for future use in the system.

F.4.12 Print query results (desirable/optional)

Query results can be printed from the system.

F.4.13 Simple (Google style) search (desirable/optional)

The system has a simple Google-type search interface available to the public.

F.4.14 SQL (Structured Query Language) compatibility (desirable/optional)

The system supports SQL standard for data queries

Section G: Reports

G.1 Pre-defined reports (required) Reports that have been designed and created in a specific layout format and that are available within the software

G.1.1 Change pre-defined reports (desirable/optional)

The system can change a pre-defined report.

G.1.2 Save changed reports (desirable/optional)

The system can save a changed report as a new report for future use.

Section H: Technical requirements

H.1 Import/export functions

H.1.1 Import files

H.1.1.1 Field selection available

The system can import American Standard for Information Interchange (ASCII) files and load the information into specific fields (for example, create a word processing file containing information for Accession number and Object name; import to specific fields).

H.1.1.2 Summary report (required) The system can generate a summary report for the import function listing such things as number of records read, rejected, accepted, etc.

H.1.1.3 Field validation (required) The system can perform field validation when importing data.

H.1.1.4 Duplicate checking (required) When importing records, the system can check for duplicate records.

H.1.1.5 Hold for verification (desirable/optional)

For records that have failed data validation during import, the system can produce an error report or hold these records for user verification (for example, import data with an invalid term to an authority-controlled field).

H.1.1.6 Long fields (desirable/optional)

The system can provide a report if data has been rejected or truncated on import.

H.1.1.7 Import extensible markup language (XML) (required)

The system can import XML.

H.1.2 Export files

H.1.2.1 Export XML (required) The system can export in XML in a standard or schema (for example, Dublin Core or SPECTRUM) or customizable format.

H.1.3 Interface with other software

H.1.3.1 Word processor (required) The system allows data to be imported from and exported to word processing software.

H.1.3.2 Attachments (required) The system allows document attachments from many types of software to a specific record

H.1.3.3 Spreadsheet (required) The system allows data to be imported from and exported to spreadsheet software.

H.1.3.4 Import/Export to other software (required)

The system has other software package types that interface (import/export) with the software.

Section I: System administration criteria

I.1 Security The way in which the system handles the identity of users and the control and tracking of permissions to change data

I.1.1 Multi-level security (required) The system provides security for different levels of user (for example, administrator, staff, or public access).

I.1.2 User ID security (required) The system requires user-id for certain access to the system.

I.1.3 Password security (required) The system requires all users to enter a password for certain access to the system.

I Password administration (required)

The system has procedures for initiating and changing passwords.

I.1.5 User function security (required)

The system allows system administration to define security at the function level (for example, allow a user to access data entry functions only).

I.1.6 User profile security (required) The system allows you to create task-specific environments for different groups of users. Read/write privileges for different fields based on group. Manage access rights (profiles) according to different types of collections and user categories (administrator, curator, public, etc.).

I.2 Change management The ability to monitor and track changes to data.

I.2.1 Edit and change notification (required)

The system can indicate an account which made an edit or change to a metadata element.

I.2.2 Operation / change status (desirable/optional)

The system can provide a status as to completion or duration of an action.

I.2.3 Operation / change stoppage (desirable/optional)

The system can allow a user to stop or interrupt an operation or change at any time.

I.2 Indexing The administration of indexing activities

I.2.1 Change of index (required) System administration can change the index of any field.

I.3 Backup The system’s role in creating and storing back-ups of data, interfaces, configurations, metadata, data structures, reports etc.

I.3.1 Backup and recovery process (required)

The software has a built-in backup and recovery process.

I.3.2 Back-end database back-up and recovery (required)

The standard functionality of the back-end database will completely backup and recover the system. This includes data, settings, transactions, users, interface, etc.

I.3.3 On-line backup (required) The system allows online backup in a multi-user environment.

I.3.4 On-line recovery (required) The system allows on-line recovery in a multi-user environment.

I.3.5 Backup process (required) The system has a built-in backup process or can use the standard functionality of the back-end database for back-ups.

I. ADMINISTRATIVE REQUIREMENTS

I.1 Meetings

a) Kickoff Meeting

Within five (5) business days following the contract awards, Contractor shall conduct a Kickoff meeting with the COR to discuss the Performance Work Statement (PWS) plans.

b) Meetings:

The COR and authorized Contractor representative(s) shall schedule recurring meetings to meet data migration and system configuration objectives. Meeting changes require written consent by a COR. The purpose of the meeting is to review the status reports, performance results, and current/outstanding issues and provide any ABMC-OCIO informational materials to Contractor. The goal is to keep track of performance, identify/mitigate any potential problems, resolve issues, and maintain a smooth operating contract.

1.2. Invoicing

Contractor shall invoice under the following base year CLINs. Please note that ABMC will withhold up to 20% of invoice amount until all deliverables are met:

Line CLIN# Description

0001 CLIN1 Software-as-a-Service Museum and Archival Collections Management Software (CMS) and associated subscription licenses for four (4) concurrent users, including up to four

(4) Option Year costs.

0002 CLIN2 Hosted implementation (including installation, security configuration, and user training)

0003 CLIN3 Migration & other data import

I.3.6 Backup process – SaaS (required)

Hosted, SaaS (Software as a service) solution regular backup is provided automatically.

I.3.7 Recovery process (required) The system has a built-in recovery process or can use the standard functionality of the back-end database for recovery

I.3.8 Automate backups (required) The system has a backup process that can be automated.

I.3.9 Automate recovery (required) The system has a recovery process that can be automated.

I.3.10 Downtime (required) The system can provide 98% or above uptime.

I.4 Audit reports Options for reporting on the system itself, rather than the data in the system

I.4.1 Audit report on data (required) The system provides a report of all newly created/amended/deleted records (for example, display the report of all newly…