Build and implementation of the OSPAR Data and Information Management System
The monitoring and assessments that take place within the context of OSPAR generate considerable amounts of data and information on the state of the North-East Atlantic. Some datasets cover several decades and represent an important asset for informing on-going decision-making processes.
United Kingdom-London: Information systems
2014/S 016-024505
Contract notice
Services
Directive 2004/18/EC
Section I: Contracting authority
OSPAR Commission
Victoria House, 37-63 Southampton Row
For the attention of: Emily Corcoran
WC1B 4DA London
UNITED KINGDOM
Telephone: +44 2074305200
E-mail: emily.corcoran@ospar.org
Fax: +44 2072423737
Internet address(es):
General address of the contracting authority: http://www.ospar.org
Further information can be obtained from: The above mentioned contact point(s)
Specifications and additional documents (including documents for competitive dialogue and a dynamic purchasing system) can be obtained from: The above mentioned contact point(s)
Tenders or requests to participate must be sent to: The above mentioned contact point(s)
Section II: Object of the contract
Service category No 7: Computer and related services
Main site or location of works, place of delivery or of performance: No requirement to be located at contracting authority premises.
NUTS code
.
Responses should consider the build phase, implementation and requirements for long-term maintenance and development of the system. Reponses to this tender should build on work undertaken to date and based on decisions taken by the OSPAR Commission.
.
The monitoring and assessments that take place within the context of OSPAR generate considerable amounts of data and information on the state of the North-East Atlantic. Some datasets cover several decades and represent an important asset for informing on-going decision-making processes. A previous contract to develop options and specifications for an OSPAR Data and Information Management System to enable the management, flow, interaction, use and communication of data, information and knowledge that would be interoperable with other data and reporting initiatives recommended:
.
a. the decentralised way in which OSPAR data sets are managed is appropriate and should continue, the specifications build on this premise to (a) ensure that all data streams have the necessary infrastructure and metadata standards to allow interoperability and (b) that the data could then be drawn on by a centralised system.
b. that critical preparatory work is required to improve data management.
c. two scenarios for consideration using a modular approach, enabling development to be undertaken in phases, according to ambition and available resources.
d. that there are significant costs for OSPAR to continue with business as usual;
e. the development and implementation of an information and data strategy would reduce costs associated with assessments of data and increase the accessibility and potential use of OSPAR data by Contracting Parties for delivering other obligations, including but not limited to the EU Marine Strategy Framework Directive (MSFD).
.
The system will be critical for realising ambitions of integrated spatial analysis, or developing more innovative assessments likely to be required to deliver ecosystem-based assessments. It has been recommended that the OSPAR information system should enable the interrogation of various datasets (both within and outside OSPAR) and present the results of assessments in a highly visual manner to make them understandable for decision-makers and external audiences.
.
A task group has been set up within the OSPAR Coordination Group to guide the development of the system. A strategy for data and information management was adopted in 2013.
.
Additional context:
.
Assessment and monitoring are key activities of the OSPAR Commission. This section sets out how the data and information are generated, how they are used (a) within and (b) outside OSPAR as well as current challenges in data management and use.
a. Data use within OSPAR:
Monitoring and assessment data are collected by Contracting Parties to fulfill obligations under OSPAR to deliver joint assessment and monitoring and includes contribution to the OSPAR Quality Status Reports (QSR), decadal integrated assessments on the quality of the marine environment of the North-East Atlantic, interim-assessments and periodic evaluations. All OSPAR measures (Decisions and Recommendations) also require implementation reporting, generate data sets and compliance reports.
The OSPAR Convention itself also specifies a range of data, monitoring, and reporting obligations. Annex VI to the OSPAR Convention provides for cooperation in monitoring programs across these thematic areas, joint quality assurance arrangements, the development of scientific assessment tools, and the preparation of assessments. The data release arrangement principles stated in Annex III of OSPAR’s 2005 Rules of Procedure state that:
i. OSPAR is committed to making as much information as possible publicly available;
ii. data-handling arrangements should be properly documented;
iii. quality-controlled and comparable data sets are available for use; and
iv. data-handling arrangements should make efficient use of resources, be clear and transparent, while protecting the privacy and confidentiality of individuals and commercial interests.
In 2010, a renewed Strategy for the Joint Assessment and Monitoring Programme (JAMP) was adopted to provide a framework for developing OSPAR’s monitoring and assessment programmes, with an emphasis on supporting work to implement the MSFD. In July 2011, a Report on Data Handling and Assembling within OSPAR was prepared by the Secretariat to assess the current situation, particularly in relation to Annex VI and JAMP. Key findings of the report included that: data streams were established at different times and are at differing levels of maturity; data are handled by different data handlers (e.g. OSPAR Commission Secretariat, specialised data centres, Contracting Parties) using different handling process, formats and standards; data reporting formats are inconsistent and may not always be adequate to deliver the information OSPAR needs; coordinated QA/QC processes are not in place for many data streams; there is no metadata system nor transparent link with final products; and data are held in different formats in different locations, with varying levels of accessibility.
.
b. Data use outside of OSPAR:
Data reported to OSPAR is also used by Contracting Parties to report against, national, regional and international obligations. It is the aspiration that data collected under the auspices of OSPAR should, where appropriate, contribute to the data and information needs for implementation of the EU Marine Strategy Framework Directive (MSFD), in particular of Art.19.3 (With regard to access to environmental information, Directive 2003/4/EC of the European Parliament and of the Council of 28 January 2003 on public access to environmental information (1) shall apply.
In accordance with Directive 2007/2/EC, Member States shall provide the Commission, for the performance of its tasks in relation to this Directive, in particular the review of the status of the marine environment in the Community under Article 20(3)(b), with access and use rights in respect of data and information resulting from the initial assessments made pursuant to Article 8 and from the monitoring programmes established pursuant to Article 11.
No later than six months after the data and information resulting from the initial assessment made pursuant to Article 8 and from the monitoring programmes established pursuant to Article 11 have become available, such information and data shall also be made available to the European Environment Agency, for the performance of its tasks ).
Since marine regions or subregions are shared both between EU Member States and also with non-EU countries, the MSFD states that ‘where practical and appropriate, existing institutional structures established in marine regions or subregions, in particular UNEP Regional Sea Conventions [including OSPAR] should be used to ensure such coordination’. With this emerging role for the OSPAR Convention, there is an urgent need to ensure that existing data streams are interoperable and fit for purpose, and to streamline monitoring and assessment processes, to avoid duplication of effort in assessment and reporting.
At the European level, the INSPIRE Directive established data infrastructures for spatial information established and operated by EU Member States, to ensure that they are compatible and usable in a Community and transboundary context. To facilitate use of OSPAR data by a wider audience and to meet MSFD reporting requirements, OSPAR must strive to achieve INSPIRE compliance.
The OSPAR Convention also provides a regional framework for Contracting Parties to work together towards fulfilling their obligations under other international conventions and processes. Examples include the Convention on Biological Biodiversity (CBD) and the UN Regular Process for Global Reporting and Assessment of the Marine Environment, including Socio-economic Aspects (the World Ocean Assessment). In this broader context, interoperability with similar systems, e.g. those implemented through other Regional Seas Conventions, would also be desirable.
48810000, 72322000
Scenarios considering the hosting of the system should include consideration of Cloud and physical server based options. Provision should be made of ongoing costings of maintaining a physical server based option in comparison with a cloud based option- this can include the sub contraction of a service provider.
Due to the decentralized nature of OSPAR data management, not all raw data is held by the OSPAR Secretariat. Data is therefore fed to the system via the following three routes:
a. Data Centres, e.g. ICES;
b. hosted by a Contracting Party, e.g. MPA data from France; or
c. directly sourced from data streams compiled in house.
Because of this, a single point upload tool will not be fit for purpose as not all raw data will be directly accessible; the module must be able to handle direct data services from sources external to the Secretariat, as well as direct upload by the system administrators. There is variation in the way data is offered from the numerous sources; the system must therefore be flexible enough to cope with this and to allow the addition of new connections over time.
The following are a list of key modules, with explanations, that the Consultants Report outlined as being needed as a minimum to achieve the goals of implementing the system. This list is not exhaustive; it is merely a guide as to the minimum expected functionality:
Upload tool – A mechanism for data upload- a possible solution would be an FTP based routine. This should allow passing of data onto the web server through an associated basic web interface for upload within the web application to incorporate the data into the database. The web interface could allow manual entry of associated metadata unique to the dataset though the upload routine and should populate the metadata catalogue simultaneously, utilising as much as possible, automated methods. Quality control and validation against agreed reporting formats (to be provided) should be applied at this stage, including functionality to allow administrators to update and adapt validation routines as necessary. Data will be supplied to the tool in the native format for each data stream. Adjustment of the reporting format and therefore the structure that is passed to the upload tool must be adaptable as updates and adjustments to the reporting format are anticipated over time.
Data management tool – This tool is expected to take the form of an interface page where administrators can manage data and services associated with individual data streams. There will be full access to all individual data entries published through the interface- a full listing of data uploaded to the system along with editing capabilities for metadata and removal of entries should be generated.
There should be a ‘holding area’ for data which has been passed through the quality assessment and quality control module, prior to data being published online. This will allow revision and correction of data before publication to the active site once it has been signed off by the responsible body.
Included should be functionality for provision of new data services, editing of existing services and deletion of those that are no longer relevant. Within this, there should be functionality that allows active services to be monitored by the administrator- i.e. to check that services are available and working and an interface for any issues to be resolved.
Map layer creation tool – This tool should automatically convert assessment product data into map layers that can be served online through the map interface. These layers will be made available through both ODIMS and other applications (via web services). There should be an interface for the administrators to oversee this process. This is a technical module that is required in the back-end of ODIMS to enable delivery and visualisation of the data.
Map styling tool – This tool will allow the data administrators to style the map layers created using the ‘map layer creation tool’. The tool should be web based, structurally similar to the rest of the application and should immediately update the styles of data layers when applied.
Web application – This is the basic website landing page of ODIMS which includes the design and lay out of; home, about, help and bibliography pages. All other modules are to sit within the framework of this web application.
This will be a web based user facing introduction to the OSPAR Data and Information Management System which will include clear direction to the Map Viewer along with other supplementary information. Branding of the page is to follow the standard OSPAR template and colour scheme.
Data download functionality – Users will be able to search and download raw data and assessment product data layers in a variety of native formats along with associated metadata. This is to include, where possible, a geospatial format as well as the standard format of the data stream. The method of search will be based on spatial location (selection by area) but should also include a keyword based search function and more advanced search functionality where the chosen software supports this. The management of OSPAR datastreams is decentralised, it is therefore important that OSPAR data held externally to the Secretariat should also be easily accessible via the data download tool. OSPAR data is both spatial and non-spatial and user accessibility should be considered for both.
Assessment product data services – A webpage should be developed allowing users to search for data services. For each data service metadata and documentation on how to access the services will be displayed, including code snippets and recommended software. This will be aimed primarily at technicians aiming to use the data services for analysis or including the data in their own websites. The feature service should be described using an ISO standard, to be confirmed and to be in line with the chosen base software, e.g. Geonetwork. Provision of WFS and WMS services are classed as a minimum requirement.
Map viewer – A map viewer will be developed which will allow users to view each of the data streams and assessment products in a geospatial format. Navigation will include panning and zooming around the OSPAR region with functionality allowing users to click on data layers to find out additional information. The map should take the form of an interactive visualisation of the region using the latest web mapping technology. From the map, the user should be able to access the ‘raw’ assessment product data so they can use the data in their own analysis. Where available, the user should be able to link to data services. The ability to access non-spatial data should be taken into account. This could take the form of a separate interrogable metadata catalogue, or utilising the map viewer.
System training – Provision should be made for training of the administrators in the structure and use of the system. Training should include provision of a manual and is deliverable upon completion of the contract.
Anticipated tasks and products:
The response to the call should incorporate the following elements:
a. Detailed technical specification document for the data and information system
b. System architecture: description of the underlying database system, reasoning for the choice, rejected options and implications for systems operations (does OSPAR have sufficient existing capacity to operate and maintain the chosen option?)
c. System infrastructure, taking into consideration a cloud based approach
d. Implementation plan: an action plan for the build and maintenance phase.
e. Detailed project budget breakdown (on the basis of the recommendations of the Consultant’s report, and the guidance from OSPAR in the anticipated scope for this first phase, the expectation would be that the maximum budget would be in the region of £250 000 for the build, implementation and first two years of maintenance)
f. Project timeline, including milestones for consultation/ interaction with the OSPAR Information System Task Group/ update with relevant OSPAR subsidiary bodies/ iterative consultation process of product;
g. Costed proposal for on going maintenance post build phase- including itemised costings of likely required works and technical support.
h. Examples of relevant previous experience.
Estimated value excluding VAT: 257 000 GBP
Section III: Legal, economic, financial and technical information
Section IV: Procedure
The most economically advantageous tender in terms of the criteria stated below
1. Budget. Weighting 20
2. Evidence of relevant previous experience. Weighting 20
3. Feasible project timeline including projected completion date. Weighting 15
4. Knowledge of the role of OSPAR within the North East Atlantic. Weighting 5
5. Experience of relevant policy drivers and associated data infrastructures, including EU. Weighting 15
6. Understanding and consideration of OSPAR capacity. Weighting 10
7. Understanding of existing infrastructure including data and information management within OSPAR. Weighting 15
Payable documents: no
Section VI: Complementary information
VI.5)Date of dispatch of this notice:21.1.2014