• A PDF version of this request for proposals is also available at: http://dp.la/info/wp-content/uploads/2015/09/rs-rfp.pdf
• A PDF version of the Requirements for the Technical Infrastructure for Standardized International Rights Statements is available at: http://dp.la/info/wp-content/uploads/2015/09/irswg-tech-white-paper-rfp.pdf

Timeline

• RFP issued: 18 September 2015
• Deadline for proposals: 00:00 GMT, 6 October 2015
• Work is to be performed no sooner than 8 October 2015.
• Functional prototypes for components A and C must be completed by 24 December 2015.
• Work for components A, B, and C below must be completed by 15 January 2016.

Overview

This document specifies the project scope and requirements for technical infrastructure supporting a framework and vocabulary of machine-readable rights statements under development by the International Rights Statements Working Group, a joint Digital Public Library of America (DPLA)–Europeana Foundation working group.

The working group shall provide and maintain RDF descriptions of the rights statements, with canonical serializations in Turtle, modeled as a vocabulary in the Simple Knowledge Organization System (SKOS).  These descriptions will include multiple official translations of each statement, and support versioning of the statements and/or vocabulary scheme. Alongside the descriptions statements, the working group will produce a summary of the data model and properties used.

The contractor will provide an implementation that acts as a platform for hosting these statements. The platform consists of an application for publishing the rights statements according to linked data best practices and a content management system to be used by the working group to publish materials related to the project. These two components should provide the feel of an integrated user experience, and must be served publicly from a single domain (http://rightsstatements.org/). As part of this contract, the contractor will also provide one year of maintenance, support, and security updates for these components, their dependencies, and the operating systems for servers on which they are deployed.

Components

Component A. Rights Statements Application

A web application that provides both machine-readable representations of the rights statements (in RDF serializations including JSON-LD and Turtle) and human-readable representations. The working group will provide a canonical version of the rights statements in Turtle-serialized RDF as needed for launch, as well as a testing version used to implement and test specific features, including, but not limited to, versions (see 3a) and translations (see 4b and 4c).

1. Human readable representations
   1. The application shall provide a human-readable web page representing each rights statement, with provision for versions, multiple language support, and additional request parameters as described in Requirements for the Technical Infrastructure for Standardized International Rights Statements.
   2. All human-readable representations shall be generated from the canonical Turtle-serialized RDF.
   3. Human-readable representations must be available as HTML5 with RDFa 1.1 or RDFa 1.1 Lite.
   4. Human-readable representations must provide links to the RDF representations listed below.
2. RDF representations
   1. The application shall provide multiple RDF serializations of the individual rights statements through content negotiation on the statement URI. Minimally, it must support Turtle and JSON-LD. Additional serializations are desirable but not required.
   2. The application shall provide multiple RDF serializations of the entire vocabulary through content negotiation on the vocabulary version URI.  The vocabulary shall support the same RDF serializations as the individual statements.
   3. All RDF serializations must be equivalent to the canonical Turtle-serialized RDF.
3. Versions
   1. The application shall support multiple versions of each statement. The structure of the versions is described in Requirements for the Technical Infrastructure for Standardized International Rights Statements.
   2. Otherwise valid statement URIs that omit the version number should respond with code 404.
4. Languages and translation
   1. Human-readable representations should dynamically handle requests for translations of the statements through HTTP Accept-Language headersand through the use of parameters as specified in Requirements for the Technical Infrastructure for Standardized International Rights Statements.
   2. The working group will provide text in one or more languages for each statement as RDF language-tagged literals in compliance with IETF BCP47. All language-tagged literals will be encoded as UTF-8.
   3. The working group will provide translations for content not derived from the statement RDF, e.g., navigational elements. The application will support this through an internationalization framework, e.g., GNU gettext.
5. Additional request parameters
   1. For specific statements, human-readable representations must accept query string parameters and generate a view of the statement enhanced by additional metadata described in Requirements for the Technical Infrastructure for Standardized International Rights Statements.
6. Resource URIs and HTTP request patterns
   1. The HTTP behavior of the application shall follow the URI structure and interaction patterns described in Requirements for the Technical Infrastructure for Standardized International Rights Statements.
   2. Resources must follow best practices for serving both human- and machine-readable representations for linked data vocabularies.
7. Visual identity
   1. The working group will provide static HTML templates developed by another vendor charged with implementing the site’s visual identity.
   2. These templates must be transformed to work in the context of the application to ensure that human-readable representations follow the visual identity of the site as provided by the working group.

Component B. Content management system

An implementation of an off-the-shelf, free/libre/open source content management system (CMS), and associated plugins to publish pages about the project and initiative, related publications, etc.

1. The CMS will be separate from the rights statements application.
2. The CMS may be a static site generator.
3. The CMS should support multilingual versions of content, either natively or through the use of plugin modules.
4. A theme or templates for the CMS must be provided, which follow the visual identity defined for the site.
5. The CMS must provide export of static content (text and multimedia).
6. All content will be edited and maintained by members of the working group.

Component C. Server configuration, deployment, and maintenance implementation

An implementation of an existing free/libre/open source configuration management and deployment automation system, and any needed templates, scripts, etc., used to install dependencies, to configure and deploy components A and B above, and to manage the servers.

1. The implementation must be published to a version control repository under the working group’s organization on GitHub.
2. The implementation should support a shared set of configuration with templating to allow the components above to be deployed to a staging virtual machine and a production virtual machine using a common set of procedures.
3. An implementation of an agentless configuration and deployment management system (e.g., Ansible) is strongly preferred.
4. The implementation must include a configuration for an HTTP proxy server (e.g., Nginx, Apache HTTPD, etc.) that will allow components A and B to be presented together through a single domain name.
   1. The proxy server configuration must allow components A and B to be served from a common domain name (http://rightsstatements.org/).
   2. The proxy server configuration should provide caching for requests that respects the HTTP interaction patterns described in Requirements for the Technical Infrastructure for Standardized International Rights Statements.
5. The vendor will also develop, execute, and provide reports for a load testing strategy for the implemented configuration.

Other restrictions

All components must run within a shared Linux virtual machine, preferably running Debian stable. The virtual machine will be hosted on a server physically located in a Luxembourg-based data center. The working group is providing both a staging environment and a production environment.

All materials developed during this project shall be released under open source/open content licensing. Source code will be licensed under the European Union Public License, version 1.1. Documentation will be licensed under a CC0 Public Domain Dedication.

Guidelines for proposals

All proposals must adhere to the following submission guidelines and requirements.

• Proposals are due no later than 00:00 GMT, 6 October 2015.
• Proposals should be sent via email to [log in to unmask] as a single PDF file attached to the message. Questions about the proposal can also be sent to this address.
• Please format the subject line with the phrase “RightsStatements.org Proposal - [Name of respondent].”
• You should receive confirmation of receipt of your proposal no later than 00:00 GMT, 8 October 2015. If you have not received confirmation of your proposal by this time, please send an email to [log in to unmask], otherwise follow the same guidelines as above.

All proposals should include the following:

• Pricing, in US Dollars and/or Euros, as costs for each work component identified above, and as an hourly rate for any maintenance costs. The exchange rate will be set in the contract. The currency for payment will be chosen by the agent of the working group that is the party to this contract.
• Proposed staffing plan, including qualifications of project team members (resumes/CVs and links or descriptions of previous projects such as open source contributions).
• References, listing all clients/organizations with whom the proposer has done business like that required by this solicitation with the last three years.
• Qualifications and experience, including
  • General qualifications and development expertise
    • Information about development and project management skills and philosophy
    • Examples of successful projects, delivered on time and on budget
    • Preferred tools and methodologies used for issue tracking, project management, and communication
    • Preferences for change control tools and methodologies
  • Project specific strategies
    • History of developing software in the library, archives, or museum domain
    • Information about experience with hosting and maintenance of RDF/SKOS vocabularies and linked data resources
• Legal authority/capacity, or proof that the vendor is authorized to perform the contract under national law. Proof of the above is to be provided by (a copy of) a certificate of registration in the relevant trade or professional registers in the country of establishment/incorporation.

Contract guidelines

• Proposals must be submitted by the due date.
• Proposers are asked to guarantee their proposal prices for a period of at least 60 days from the date of the submission of the proposal.
• Proposers must be fully responsible for the acts and omissions of their employees and agents.
• The working group reserves the right to extend the deadline for proposals.
• The working group reserves the right to include a mandatory meeting via teleconference with proposers individually before acceptance. Top scored proposals may be required to participate in an interview to support and clarify their proposal.
• The working group reserves the right to negotiate with each contractor.
• There is no allowance for project expenses, travel, or ancillary expenses that the contractor may incur.
• Ownership of any intellectual property will be shared between the Digital Public Library of America and the Europeana Foundation.