managing knowledge a prototype regular process clearing...
TRANSCRIPT
1
MANAGING KNOWLEDGE: A PROTOTYPE REGULAR PROCESS CLEARING HOUSE MECHANISM
REPORT BY GRID‐ARENDAL AND UNEP‐WCMC TO UNEP DEWA AND IOC‐UNESCO
DECEMBER 2009
EXECUTIVE SUMMARY The United Nations General Assembly in 2005 endorsed the need for a Regular Process for the global reporting and assessment of the state of the marine environment, including socio‐economic aspects in response to global concern about the intensification of the uses of the marine environment and the adverse impacts being observed on the ability of seas and oceans to continue to provide the benefits on which human kind depends.
Communication, outreach and information management are core components needed to address the requirements of a process that is to provide regular, ongoing assessments of the global marine environment. At its base, a regular assessment process unequivocally depends on the ability to uptake, evaluate, synthesize and output data and information in a manner that best supports the desired outcomes of a Regular Process. In order to achieve its goals, in a credible, transparent, legitimate and salient manner, the Regular Process will inherently be dependent on a well‐structured and user‐friendly data and information management system.
The proposed prototype Regular Process Clearing House Mechanism (RP CHM) would provide an authorised interface for the sharing of data and information essential to the delivery of the Regular Process assessment cycles. It will do this by:
a. Bringing together national and regional datasets to provide a global perspective;
b. Visualisation and integration of information;
c. Building capacity of States and organisations to help them engage in and contribute to the Regular Process;
d. Increasing understanding through knowledge and experience sharing.
The key focus will be on accessibility and ensuring that the CHM carries out its function as a capacity building tool to facilitate the engagement of States and organisations in the Regular Process. In addition, this user‐friendly interface will maximise opportunities for increased communication, education, and public awareness concerning the status and trends of the marine environment and the action being taken by the international community through the Regular Process.
2
This report presents the outcomes of this project to develop the prototype CHM, which has been a collaborative effort of UNEP/GRID‐Arendal and UNEP‐WCMC, funded by the Norwegian Government through UNEP to support UNEP and IOC‐UNESCO in their role working towards a Regular Process. This tool has developed as a result of close and detailed collaboration, to present viable options. The attached documents are presented in their full detail to ensure that the decisions taken are transparent, and the rationale can be tracked should the prototype be further developed.
Project Outputs
1. Prototype site and design options
The design and development of a prototype Clearing House Mechanism for a Regular Process: the development site is currently available at:
http://development.unep‐wcmc.org/mura/rpchm/index.cfm.
Many features of the site have are functioning and can be explored, including documents, the AoA site content and the GRAMED Database, as well as new features such as member discussion fora and a new flash plug and play information feature “Why a Regular Process”. The content that has been developed is intended to inform further decisions regarding the next phase of the RP CHM and to demonstrate functionality. Figure 1 shows the proposed home page design, the rationale for which is included in the specifications document (Chapter 2)
2. Technical and content specifications
A detailed outline the proposed scope and content for the different elements of the new Regular Process Clearing House Mechanism (RPCHM) website are presented in Chapter 2. This document accompanies the online website prototype and the Data Management Centre Specification
3. A detailed consideration of data management issues
The Data Management Centre represents a key feature of the CHM and will provide the primary assessment data interface for the Regular Process. The development of the Data Management Centre will require a great deal of research and must continue to be informed by the next stages of the Regular Process. Chapter 3 presents the possible options that would best serve the data management requirements for a Regular Process, and illustrate the respective benefits and caveats of each approach. This Chapter will serve to guide the discussions and inform decisions that will need to be taken by Experts charged with preparing for the implementation of the Regular Process.
4. Key Considerations and recommendations
Chapter 4 synthesizes some of the decisions that are required in order to move forwards with the concept of a knowledge management system for the Regular Process including a proposal for a 2.5 day workshop to consider the RP Clearing House Mechanism (Annex 1). The table presents to the reader the issues for consideration, the decisions required, some considerations that need to be taken into account and recommendations, where appropriate based on experiences of the team and in the development of the prototype. The table also directs the reader to the chapter and section where more detailed information can be found. It is critical that these questions are considered and decisions taken at the planning stage in order to ensure that the components of the regular process will be credible, legitimate and transparent.
3
5. Updates to the GRAME Database for integration into the RP CHM
The updates to the GRAME Database are presented in Annex 2. The document provides a summary of all the updates to the Global and Regional Marine Assessment Database (GRAMED) undertaken by the United Nations Environment Programme‐World Conservation Monitoring Centre (UNEP‐WCMC) as specified by the Terms of Reference provided by UNEP/GRID‐Arendal for the project “Assessing our oceans and update of the GRAME Database”.
Looking forwards to the next steps:
The outputs of this project in combination with the experience of developing the GRAME Database have highlighted that there is a need for more detailed consideration of how information and data inputs and outputs of any components of a Regular Process will be managed to support the first cycle of a regular process and beyond. A strategic, planned approach is required for accessing, sharing, processing and archiving data and products for global assessments that fulfill criteria to be considered transparent, legitimate and credible. It is the intention of this project to use to the prototype RP‐CHM to demonstrate some of these issues, and some potential options to be considered.
It is proposed that the next step in this process would be an expert workshop (Annex 1), bringing together those parties responsible for the implementation of the first cycle of the Regular Process, with experts in data and information management for large scale, regular processes.
The Prototype RP CHM would require a number of decisions to be taken, as well as additional resources to be developed into a phase 2. It would be feasible, if requested to produce a proposed costing for a phase 2 prior to the proposed workshop.
4
CONTENTS
Executive Summary ............................................................................................................................. 1
Chapter 1: Introduction........................................................................................................................ 5
1.0 Background......................................................................................................................................... 5
Chapter 2: Requirement Specifications for a prototype Regular Process Clearing House Mechanism.... 8
1.0 Prototype Website Design Principles ................................................................................................. 8
2.0 Overview of Functional Requirements .............................................................................................12
3.0 Overview of Content.........................................................................................................................15
4.0 Considerations when building the website and choosing the CMS .................................................21
5.0 References ........................................................................................................................................23
Chapter 3: Conceptualization of a Data Management System for the Regular Process Clearinghouse Mechanism ........................................................................................................................................ 24
1.0 Why consider a data management strategy?...................................................................................24
2.0 Data and Information Management for the Regular Process: The Fundamentals ..........................25
3.0 General Approaches to Hard Data Management .............................................................................25
4.0 Summary...........................................................................................................................................35
5.0 Recommended reading ....................................................................................................................35
Chapter 4: Key Considerations and Recommendations....................................................................... 37
Annex 1: Proposed 2.5 day workshop for presentation and consideration of the RP CHM ......................41
Annex 2: Summary of GRAME Database Updates as of December 2009 ..................................................43
1.0 Expected Outputs .............................................................................................................................43
2.0 Update Summary..............................................................................................................................43
Annex 3: Multimedia presentation feature demonstration: Why do we need a Regular Process? ..........47
5
CHAPTER 1: INTRODUCTION
1.0 BACKGROUND More than ever, the impact of human activities and climate change is affecting the state of our marine environment. The formulation of sustainable, ecosystem‐based policies and measures for oceans and coasts needs to be supported by sound scientific assessments at national, regional and global scales. In response the United Nations General Assembly endorsed in 2005 the need for a Regular Process for Global Reporting and Assessment of the State of the Marine Environment, including socio economic aspects (Regular Process), both current and foreseeable which builds on existing regional assessments. That signifies the recognition of the needs for global concerted efforts to protect and sustainably manage the world's global commons and also marked the beginning of a concrete, action oriented process that will ensure sustained, long‐term and targeted efforts. Documentation for the progress towards a Regular Process can be found at http://www.unga‐regular‐process.org.
The proposal for the first, five year cycle of the Regular Process is currently being considered by the Ad Hoc Working Group of the Whole, and recommendations will be made to the 65th Session of the UNGA, including on the modalities for the implementation and institutional arrangements as well as the scope and objective of the first cycle.
One of the major components that will be a prerequisite for successful design and implementation of this first cycle will be to understand the requirements for and develop a well structured and user friendly tool for managing the data, information and knowledge that is required for and generated by assessments within the Regular Process. The experts responsible for this task will need to consider the available options and take decisions to ensure that knowledge management is able to support a credible, legitimate and salient assessment process.
Following the recent Ad Hoc Working Group of the Whole in New York (September 2009), convened to develop recommendations resulting from the submission of the work of the Group of Experts on the Assessment of Assessments, it was proposed that GRID‐Arendal and UNEP‐WCMC work to develop a prototype clearing house mechanism that could be used by a Regular Process to help manage data, information and knowledge.
1.1 PURPOSE The purpose of this document is to outline the proposed scope and content for the different elements of the new RP CHM website and data management centre, and accompanies the online website prototype. The document also provides recommendations, decision points and proposed next steps.
1.2 INTENDED AUDIENCE The prototype is being developed at the request of UNEP and IOC‐UNESCO, the lead agencies of the Assessment of Assessments process. It is intended to provide options to inform further discussions on the development of a fully‐functional Regular Process Clearing House Mechanism (RP CHM) and will be presented to the lead agencies and an expert group regarding this issue in 2010. This intended end user will likely be policy fluent rather than technically proficient.
6
1.3 SCOPE GRID‐Arendal and UNEP‐WCMC will work together to develop a prototype clearing house mechanism that could be used by a Regular Process for the global reporting and assessment of the state of the marine environment, including socio‐economic aspects, in order to help manage data, information and knowledge.
It is hoped that the prototype will provide the Secretariat charged with taking forward the Regular Process, and the experts identified to support them in this role, with information and options required to take decisions on the information and knowledge management required, and the requirements to build the final website for the RP CHM.
1.4 TEAM MEMBERS AND CONTACT INFORMATION
Name Institution Contact
Yannick Beaudoin GRID‐ Arendal [email protected]
Katie Cadge UNEP‐WCMC [email protected]
Emily Corcoran* GRID‐ Arendal [email protected]
Itchy Cvetanovski GRID‐ Arendal [email protected]
Francine Kershaw* UNEP‐WCMC Francine.Kershaw@unep‐wcmc.org
Riccardo Pravettoni GRID‐ Arendal [email protected]
*Respective institutional leads
1.5 ASSUMPTIONS AND CONSTRAINTS Assumptions:
• Continuation of States’ support to the implementation of a Regular Process;
• Funding being made available for knowledge management required to support a Regular Process assessment cycle;
• Decision taking, engagement and support from the Secretariat and mandated group of experts on the need for information, data and knowledge management at a centrally accessible location.
Constraints:
• The data requirements and detailed methods for the implementation of the first assessment cycle are still being developed. The development of a data and information management system requires that certain decisions regarding approach and method are addressed. A fully‐functional website, including data and information management systems, cannot be developed without certain decisions being taken. A
7
summary of the required decisions identified in this document are presented in the main body of the report.
• The website produced as an output of this project is aa prototype to demonstrate to decision‐makers and experts the design and functionality that could be achieved if a full website was developed to serve the RP CHM. The prototype is not a fully functional site. Where decisions are required, options are presented. It is intended that it will provide a basis for discussion and for further ideas, and be illustrative to a non‐technical audience to what can be achieved.
• The delivery date for the finished prototype is the 22nd December 2009.
8
CHAPTER 2: REQUIREMENT SPECIFICATIONS FOR A PROTOTYPE REGULAR PROCESS CLEARING HOUSE
MECHANISM
1.0 PROTOTYPE WEBSITE DESIGN PRINCIPLES The brief for the design was to resemble the current UNGA/GRAME web sites and the initial layout prototype was
directly derived from these approaches. The design team was encouraged to stay within certain bounds − maintaining the same look and feel − in the new RP CHM web site. However, this posed significant challenges due to the relatively outdated design and logical structure. The design team’s solution was to create a hybrid layout of the RP CHM web which was partially based on the UNGA/GRAMED web sites but was modified to allow for the increased needs of a CHM website. The new proposed layout both looks and feels sleek and modern by introducing fresh colours and intuitive navigation. The elimination of clutter and distracting elements have been explicitly been considered, hence the minimalistic approach. In the case of web design, desirability must be fused with technical feasibility and economic viability and successfully creating an open and well balanced product.
Through the application of design there is the opportunity to rethink and approach differently existing problems, and novel solutions can be developed. With the need of tackling global and local problems there are some basic rules that can be observed that have been implemented in our proposed prototype:
• User centred ‐ what does the user need, usability etc;
• Ergonomics ‐ understand people, culture and content;
• Learning by making ‐ build in order to think, prototyping, learn strengths and weakness, and apply scalability for the future.
1.1. STYLE The proposed design of the Regular Process CHM has been styled to reflect the current existing sister sites http://www.unep‐wcmc.org/GRAMED/ and http://www.unga‐regular‐process.org/ whilst taking into account that the site design will need to be adapted to reflect the larger expectations and size of the CHM. This will provide for the continuation of the Regular Process “brand” ensuring a clear relationship to previous work undertaken.
1.2 COLOR SCHEME The presented color scheme is based on marine colors and appealing fresh hints of green to convey an environmental look and feel. The colour pallette has been chosen to create a dark theme to the site which lowers energy consumption for viewing and makes the site more environmentally friendly.
Figure 1: Proposed homepage design for the RPCHM
9
1.3 LOGO DESIGN Four alternative RPCHM logo options were designed for consideration by the experts and Lead Agencies.
1.
2.
3.
4.
1.3.1 LOGO CONCEPT The graphical profile is based on contemporary minimalism. It is simple but yet memorable and versatile. The Regular Process logo consisting of a symbol and text conveys a continuous flow knowledge. The placement of the logo within a square ensures a discrete look and feel. Additionally, it is also optimal for creating "favicons" which are used by web browsers for bookmarking pages. The logo’s square shape differentiates it from the background making it stand out on even uni‐coloured/greyscale surfaces.
1.3.2 LOGO GEOMETRY The logo uses geometry to illustrate a state of constant forward movement. This approach is carved out by a "perpetual motion/never ending state" of movement where a whirlwind of clearing house roofs are depicted as primary coloured triangles to convey the flow of motion.
1.3.3 LOGO COLOUR SCHEME The various shades of the colours are optimal for desaturated use, i.e. the symbol stands out well in a monochrome colour palette; therefore it also blends well with both dark and light uni‐coloured backgrounds. Pure
10
11
solid colours are used to ensure safe printing on various materials such as paper and textured media. No gradients are used because some portions of the colours become washed out on various materials and surfaces.
1.3.4 FONT The primary font used is Myriad Pro which is a sans‐serif developed by Adobe. It is available on most computer platforms. It brings a modern, fresh and decorative look and feel to the overall brand of the Regular Process.
1.4 NAVIGATION The navigation system was derived from an extensive prototyping and mind mapping exercise to identify a recommended set of information containers. The main approach was to create new solutions by combining expertise within ocean management, computing and design technology.
1.5 COMMUNICATING QUANTITATIVE INFORMATION The Regular Process will be inherently quantitative, creating and synthesising scientific and socio‐economic datasets. Techniques for communicating quantitative data and findings can be employed to increase the accessibility of the website for the user. ‘Communication’ does not only mean making information available, but transferring real understanding in a reasonably short amount of time. The receiver needs to access the information on a logistical level — e.g. a piece of paper or an emailed PDF – and then on a perceptual level — i.e. one data
point in a chart − and finally, they need to translate those visual inputs into something meaningful — i.e. that the market share of one product is overtaking another which is illustrated in a chart. For successful communication to happen, all three of these levels must be met.
In summary, the vision of the prototype is to make it as easy as possible to visually communicate the quantitative ideas contained within it. In this project we aim for visualizing concepts and processes to ease the digestion of information in the concrete form of charts, maps and illustrations.
1.6 FEEL AND ACCESSIBILITY The CHM has an obligation to be as accessible and user‐friendly as possible with an interface which belies the complexity required to manage and draw conclusions from a large number of data sources, in order to engage the full spectrum of States and organizations and to ensure that the Regular Process can be undertaken effectively and efficiently. Accessibility features range from ensuring intuitive navigation around the site through to the provision of help and interactive tutorials to demonstrate, for example, data entry procedures.
The site will be designed with different levels of accessibility depending on the user:
• General public access
• Registered user (member) access
• Secretariat access
• Administrator access
12
2.0 OVERVIEW OF FUNCTIONAL REQUIREMENTS
2.1 LANGUAGE The site should, preferably be available in all the six UN languages, namely Arabic, Chinese, English, French, Spanish and Russian. This could be achieved using automated translation software to translate content that is originally entered in English to the 6 languages, giving visitors a choice of which language they would like to view the site in when they arrive. Building on the key considerations outlined below, it will need to be decided whether to provide the website just in English or in the six UN languages.
Considerations:
• There will inevitably be some incorrect translations and inaccuracy which would require some manual human interaction to correct.
• A content management system would be needed which had the ability to support multiple languages.
• It is now possible using most search engines to view pages in your chosen language, for example, through Google. This achieves automated translation of any web page into any language without the overhead of processing and storing the multiple language versions.
2.2 HOSTING OF THE PROTOTYPE WEBSITE The prototype is hosted on existing windows servers at UNEP‐WCMC in Cambridge, UK and is running on ColdFusion MX7 and SQL Server which are also hosted at this location.
2.3 CONTENT MANAGEMENT SYSTEM The content of the website will be managed through a content management system (CMS). This will facilitate non‐technical staff being able to alter website content without the intervention of a web developer. This will include the ability to add, edit and delete content, documents and images as required via the CMS without manipulating any HTML or scripting code. Text editing and formatting is done with a ‘What you see is what you get’ (WYSIWIG) editor.
Users will access designated templates and easily update information in pre‐designed formats. Databases will be responsible for holding dynamic information which will include formatted text, hyper‐links and digital pictures. Together, the website and CMS will provide the ability to upload and download documents in Word, Excel, PDF, and other formats. As most documents will age and lose relevancy over time they will need to be routinely updated or removed. Again, this will all be controlled by the non‐technical administrators of the website.
Each user of the CMS has a role: administrator, approver and editor.
• The administrator may add or delete users, set users privileges, add, edit, delete and approve content, change navigation, design forms, view feedback and have full control over the CMS.
• The approvers (e.g. Secretariat) may add, edit, delete and approve content.
13
• The editors (e.g. registered users) may only add, edit and delete content. Their changes will need to be approved by an approver or an administrator before they go live.
This system will be simplified for the prototype in order to facilitate ease of use and learning. However, once the website is launched these roles will enable a quality assurance procedure to be established for data which is being entered. Submitted information can then be validated before being displayed on the live site. It is suggested that the original submitter will receive an e‐mail notification when their data has gone live.
The CMS chosen for the development of the prototype is MURA (http://www.getmura.com/). It is freely available, has the features required for the development of a prototype CHM, is open source ColdFusion code which means it can be edited to evolve with the needs of the Regular Process and can be fully supported by the Secretariat and/or Administrators going forward. MURA is also compatible with SQL Server databases and ColdFusion MX7, which is the version currently in use at UNEP‐WCMC where the site will be hosted.
2.3.1 MURA CMS OVERVIEW Capabilities:
• WYSIWYG content editing (enables users to edit and add content without having any knowledge of HTML);
• Preview content before publishing;
• Enable approval of content before publishing;
• Document and image management;
• Audit trails;
• SEO‐friendly URLs
• Personalize content for different audiences (may be useful after prototype stage);
• Create forms and capture data (e.g. surveys, user feedback);
• Create editorial permissions for different content ;
• Create and manage email marketing campaigns;
• Track site users;
• Reuse customizable content components like images, navigation bars, etc.;
• Manage unlimited drafts and versions of content, with one‐click rollback;
• Create sitemaps with automatic updating.
Limitations:
The main limitation of the MURA CMS is that it doesn’t provide integrated translation or multi‐lingual support as this was deemed outside the scope of the current project. It does however allow management of several sites through one interface so there may be a way of using this functionality to manage multi‐lingual sites in the future.
14
A more appropriate option, if the prototype is successful, may be to migrate the site content to an alternative CMS with integrated, multi‐lingual functionality.
2.4 SITE NAVIGATION AND ORGANIZATION The user interface should intuitively guide the visitor to the information they seek, thus the site should include the following navigation strategies:
• Menu System as the primary navigation method of the site that is always displayed at the top of each page including the homepage. Each item on the primary navigation leads to a secondary “section” of the website.
• A hierarchical left menu, dependant on the secondary section chosen from the primary (top) navigation. The left‐hand menu will change dependant on the specific section chosen.
• Each section must have a main page where visitors can navigate to the sub items under the sections, but still be able to get back to any of the other main section home pages. This will be achieved as the top primary menu will always be visible.
• A full simple site search will be provided and will be included on each page.
The administrators of the website will be able to alter the navigation items via the CMS. This provides flexibility for change and growth as the website evolves.
At the bottom of each page will be a common footer containing the funder and partner organisations logos, About Us, Contact links and the copyright.
2.5 SITE LOGIN AND SECURITY The main site will be available to the public as visitors. All visitors will be encouraged to register as a member and login when they visit the website. A login box for registered users will be included in the left hand column on each page
Some level of personalisation is desirable, especially for regular users, and could potentially include a “Members Area”, discussion forums and other features for logged in visitors (members).
As there will be a variety of different types of contributors to the website there will be various levels of security for members. Note that members of the website are different to users of the CMS and the security used for members to login to the website is completely separate.
It is recommended that the CMS admin system have its own URL with no login link from the public facing part of the website. This is crucial if the prototype does become a fully functional public site for security purposes, as the administration URL can be secured to prevent unauthorised access.
2.6 HELP AND SITE TOUR
2.6.1 VIRTUAL SITE TOUR The virtual site tours will be multimedia tours of the site which demonstrate what can be undertaken, found and used on the website. Apple Mac recording software will be used to produce these for the prototype CHM site.
15
2.6.2 HELP BUTTONS The website should be as intuitive as possible, and help will be provided throughout the website, mainly through pop‐up windows, where it is deemed to be needed, for example, on data entry forms. Particular areas where help may be needed is in explaining technical terms related to RP CHM and explaining exactly what sort of data input is required, although these aspects will be further developed through the consideration of the design of the Data Management Centre.
2.7 WEB SITE REPORTING AND STATISTICS In order to maintain a quality site that continues to meet the needs of the Regular Process, a quality web site reporting system that provides types and features of management reports, including traffic counts, origin or domain name sources of visitors, or other useful information regarding the website, is required.
Investigation is required into whether the free statistics provided by MURA and/or by Google will be sufficient. If and when further more detailed statistics are required, it is possible that “Webtrends” may be used. This software can provide excellent in depth statistical information as required, and is the market leader in this field. Although web site reporting is not essential at the prototype stage it will still be useful for assessing future reporting needs.
2.8 SEARCH ENGINE OPTIMISATION Search engine optimization is not required for this website prototype as it is for internal use only, however, it is worth considering some basic guidelines when creating pages and content so that should the prototype become a public site in future, it will already be well constructed for search engine optimisation.
Recommendations:
• The title of each page should be unique to each page and not be longer than 70 characters.
• Each item of content on the website should be customized with META‐DESCRIPTION and META‐KEYWORDS within the CMS.
• All page URLs, especially dynamically generated ones, must have friendly URL aliases so that they are picked up by search engines. i.e. not urls such as www.unep‐wcmc.org/content.cfm?id=34673647.
• The CMS must employ semantic HTML (h1, h2, p, etc.) . This means all HTML should be well formed.
• ALT text should be provided for all images.
3.0 OVERVIEW OF CONTENT The RP CHM by necessity will be a multi‐faceted tool, aimed at multiple user‐types and will involve the following 2 core types of “data”:
a. Soft data: this is defined as the broad range of information related to theme or topic. Soft data assembles scientific literature, bibliographic information, mainstream knowledge, commentary, news, multimedia materials, amongst other types of information all linked to an identified theme or related themes for which a management system is dedicated to service.
16
b. Hard data: this is defined as the real, numerically based datasets that represent the results of scientific and/or investigative research specific to a theme or topic. Hard data assembles datasets from experimental, field and instrumental observations, theoretical modeling and other scientific and applied technical data types from various sources.
It is essential in the development process of a data and information (or “soft data” and “hard data” management system) to properly consider all aspects of the expected system cycle including
• Input and output;
• End‐ and front user accessibility;
• Storage;
• Security;
• Financial aspects;
• Infrastructure considerations.
The RP CHM will allow users to search for information including past and existing assessments, standardised assessment methodologies, national, regional and organisational contacts; act as a repository for documents and resources relevant to the Regular Process; and provide a data interface for the Regular Process assessment results in order to contribute towards the global reporting mandate of the Regular Process.
It will provide a number of interactive features, including a forum facility to support the continuing work of experts as well as those undertaking and coordinating assessments within regions. Automated national and regional summaries of CHM contents and findings will be presented to allow the monitoring of progress. Details of the proposed content for the main sections of the website, alongside any technical requirements for each section, are outlined below.
3.1 HOME PAGE The home page will contain a limited amount of text, but with accessible links to more in depth information. It will be visually appealing using images, graphics, and perhaps multimedia flash movies. The main image/movie can be updated regularly via the CMS to keep the home page fresh for regular users.
Automated links from the homepage to the latest content and news items will be displayed in order to keep the homepage current without any manual updating. There will also be a link through to the Diary of Events and two feature sections which the web site administrators can update to highlight and link through to items of particular importance at any time.
3.2 THE UNGA REGULAR PROCESS These pages will predominantly provide information on the UNGA Regular Process and its Secretariat with a combination of text and links to agreed, static documents. This component of the CHM will be a ‘living’ resource with the most up‐to‐date background and meeting documents, negotiated text, notifications, and reports being uploaded on a regular basis. It will need active management and updating to remain current.
17
3.2.1 INTRODUCTION AND ‘WHY A REGULAR PROCESS’ PLUG‐IN This section will contain material to provide the user with an introduction to the UNGA Regular Process and will also be used to engage, educate, and promote buy‐in for the Regular Process among non‐technical users through an online, flash, multimedia resource entitled “Why a Regular Process?”1 This electronic resource will also be made available as a standalone promotion tool which will present the concept of a Regular Process, why it is needed, and the consequences of failure.
This tool will draw on information from the Assessment of Assessment phase and illustrations from the GRAMED database. It will be static, in that once it is produced it will be approved and the content finalized (see Annex 3).
3.2.2 HISTORY This section will outline the history of the Regular Process, from its original conception and through the key meetings and events which have contributed to its development and progress. A graphical timeline will also be included to increase understanding by the reader.
3.2.3 BACKGROUND DOCUMENTS This section will contain background documentation on the decisions and resolutions from UN processes as well as from internal processes (Ad hoc bodies, groups of experts) as well as any supporting documentation about the process or the decisions made.
3.2.4 MEETINGS AND DOCUMENTS An archive of all meeting documents and final reports pertaining to the Regular Process. Tools will include a facility to search meeting documents, and links to all meetings to provide the user the ability to browse available meetings.
3.2.5 AOA: THE START‐UP PHASE A description of the Start‐Up phase of the Regular Process. It is envisaged that all key information currently hosted by the www.unga‐regular‐process.org site will be migrated to the RPCHM. Links to the AoA report, meetings, documents, and background information will all be included.
3.2.6 REPORTS This will be searachable archive for reports coming from partners (National, regional, expert etc.). It may be that a standardised reporting format is developed. The types of reports required will depend on the modalities set out for implementing the first cycle but may feasibly include: national capacity status; progress reporting; consultant, and working group reports among others.
1Working title
18
3.3 THE REGULAR PROCESS CHM This section of the CHM provides for the transparency and legitimacy of the site. Its focus is on the provision of information regarding the Regular Process Clearing House Mechanism.
Meeting documents will be provided and automated user statistics will be integrated, including the extent of site use and tracking of site content. Users will also be able to provide feedback on any aspects of the CHM directly through these pages.
3.3.1 MODALITIES A series of information pages, which will be controlled by the content management system. These pages will include information on the structure of the CHM, the mandate (what it is designed to do), development history of the site and also site policies (e.g. policies for privacy, copyright, data use and sharing, disclaimer, use of external websites etc.). It should also contain information on the administrative arrangements, i.e. how the site is run, monitored, evaluated, and reviewed, as well as the technical specifications for the site.
3.2.2 PROGRAMME OF WORK The Programme of Work for the RP CHM will be included on approval by the Secretariat and relevant bodies.
3.3.3 MEETING DOCUMENTS Archive for documentation and reports from meetings specifically pertaining to the management of the RP CHM.
3.3.4 DEVELOPMENT HISTORY Text to outline the development process of the site, the organisations involved, and key funding bodies and partners. This will include the development history and aims of the prototype RP CHM.
3.3.5 USER FEEDBACK An online user feedback form for questions and comments. Forms will be sent to the Secretariat or other relevant body.
3.3.6 USER STATISTICS Summary statistics will be provided to illustrate, for example, user numbers and their geographical distribution. More complex user statistics may be made available online or exclusively to the Secretariat or other relevant body in order to closely monitor site usage.
3.4 INFORMATION PORTAL The information portal is expected to be the most in depth and widely used part of the website.
3.4.1 PAST AND EXISTING ASSESSMENTS This page will either link to or embed the GRAME Database www.unep‐wcmc.org/gramed. This database contains metadata on over 900 past and existing activities and assessments in the marine environment. The GRAMED site architecture allows for the upload of new information as new assessments emerge. The scope of this database has been streamlined to hold 15 fields of summary information.
19
3.4.2 COUNTRY PROFILES This will provide metadata for information that has been submitted by participating countries will be archived and made available on these pages. Users will be able to see which countries have contributed to which assessment cycle, when they last contributed to the RP, the number of documents and types of information that are available.
3.4.3 RP CHM CONTACTS DATABASE A database will be developed to hold the various contacts related to the RP CHM. These contact details need to be fully searchable. Exact details of what data will be held for each contact are yet to be decided and will depend on access. The database would most likely include national, regional, global and organisational focal points.
3.4.4 EXPERTS DATABASE A database similar to the contacts database will be developed to hold relevant details of the experts involved in the RP CHM. These experts’ details need to be fully searchable. Exact details of what data will be held are yet to be decided. The datasets will include the Group of Experts, national, regional, global, supra‐regional and field experts.
3.4.5 DIARY OF EVENTS An online diary where the administrators can enter dates of interest, meetings, deadlines etc. These are displayed in a standard diary or calendar format.
3.4.6 NEWS ARCHIVE New and archived news items, latest additions and notifications added to the website pertaining to the RP CHM will be displayed and searchable. It is also intended that there will eventually be a news management module in the CMS for users to add, edit and delete their own news items.
3.4.7 EARTHWIRE MARINE AND SEAWEB It is proposed that news from the media and latest scientific publications will be drawn into the site through established external tools such as Earthwire Marine and the SeaWeb Marine Science Review. This will require collaboration with the originators of these tools. Benefits include the integration of automatically updated, credible material, which will help to keep the website up to date with minimal effort or expense.
3.4.8 MULTIMEDIA RESOURCES The Information Portal will also present a location for the development, testing and trial of new and innovative ways in which to visualise and disseminate information (this could be for example Youtube videos, flash presentations or animations, new graphics, etc.). The intention is that this will help the RP CHM keep pushing for the inclusion of new technologies and help the website pages remain fresh and up to date.
3.5 MEMBERS AREA
3.5.1 USER SIGN IN AND REGISTRATION The ‘Members Area’ will be available to visitors of the CHM once they have registered and created a profile with user‐name and password details. These steps provide security measures, providing different levels of access to different user types, and also allow the monitoring of use of the CHM. Registration will also allow certain types of users to upload data and information to the CHM. This will include an area for reminding users of their password, to amend their user profile.
20
3.5.2 MY CHM Members will also have the option to access a “My CHM” function and allowing them to modify the CHM interface to reflect their needs and access the information they are seeking more rapidly (e.g. iGoogle).
3.5.3 FORUMS Online discussion forums will be provided for members to discuss any issues of interest related to the website, the Regular Process or the Clearing House Mechanism. Members will be able to upload documents, with the forum as an informal workspace for individuals and groups.
3.5.4 ONLINE MEETING SPACE The online meeting space will require some additional software which can be plugged into the website. It is envisaged that users will be able to conduct online meetings and conferences, upload and edit materials, and demonstrate work. This will contribute to accessibility of the RP CHM, enabling groups from different regions to communicate and collaborate using minimal resources. This needs further investigation, but it may be that UNEP‐WCMC already has some suitable software for this.
3.6 DATA MANAGEMENT CENTRE (for more detailed analysis see Chapter 3)
The Data Management Centre represents a key feature of the CHM and will provide the primary assessment data interface for the Regular Process. The development of the Data Management Centre will require a great deal of research and must continue to be informed by the next stages of the Regular Process.
Ideally, the Data Management Centre will represent a fully interoperable system, sourcing and synthesizing data from existing activities and from new assessments undertaken through the Regular Process. Complex data structures will need to be established “behind‐the‐scenes” in order to ensure the interoperability of decentralized and submitted data, and to provide the additive statistical ability to meaningfully process national results into regional and then global data summaries. These structures are dependent upon the specific Regular Process methodologies which are yet to be decided.
Capacity building will form an important component of the Data Management Centre. The interface will be accessible and intuitive, and training modules and interactive online tutorials will be made available. These modules should be linked to National commitments for engagement and should focus on assisting National entities to participate and contribute towards a global Regular Process by providing guidance on managing, handling, and accessing data.
Chapter 3 presents the possible options that would best serve the data management requirements for a Regular Process, and illustrate the respective benefits and caveats of each approach. This annex will serve to guide the discussions and inform decisions that will need to be taken by Experts charged with preparing for the implementation of the Regular Process.
3.7 HELP PAGES The RP CHM will be supported by an extensive Help library which will be accessible from every page of the site. A PDF ‘help tree’ will provide the core help facility will be made available with detailed descriptions of each of the CHM components, and this will be complemented by clickable information ‘buttons’ which will connect help files
21
to specific locations on the site. Given the complexity of the CHM, an online virtual tour of the site will also be made available through the help page.
3.8 SECRETARIAT VIRTUAL OFFICE A secure access area for the members of the Secretariat to work within themselves and with contractors, experts and specially formed groups charged with assisting the Secretariat in their work. This will operate in a similar way to the Virtual Office system used for the AoA Phase.
4.0 CONSIDERATIONS WHEN BUILDING THE WEBSITE AND CHOOSING THE CMS There a several questions which need to be more thoroughly explored before deciding on how to go ahead with the build of actual fully‐functional Regular Process CHM website, i.e. following the prototype stage of the project. The prototype is hoped to be a useful tool to understand what is required for the final build and it may or may not be used as the basis to build the final website upon. It may also be the case that some components or functionality of the prototype may be maintained in the final build whilst some are updated, removed or replaced.
It is important to consider questions such as who will be using the site, how heavy will the traffic be, how easy to use/complex should it be, what are the main features of importance, how quickly does it need to go live, how important is performance, and what is the budget. These questions can not all be answered at this stage but are worth be raised for discussion prior to developing a fully‐functional site.
4.1 WHO WILL BE USING THE SITE? In this case the site must be accessible to the public and ideally to speakers of the six official languages of the United Nations which are Arabic, Chinese, English, French, Russian and Spanish. Its expected users will mainly be decision‐makers working for national governments, intergovernmental agencies and international non‐governmental organizations, conventions, assessment processes (e.g. TWAP, GEO) researchers etc. however, the information is also to be available to the general public. When designing the user interface, the needs of these all these user‐types must be considered.
Parts of the site may only be available to professional members. These areas of the website will need to be secured with a user authentication and authorisation system, and there may be the need for various levels of users, i.e. different users or members may have different rights. This needs to be further explored.
The CMS administration interface is separate from the website and should, for proper security, be secured using a separate user logging on procedure. Who will have access to the CMS? Will it be locked down to a few key users at UNEP‐WCMC and GRID‐Arendal or will there be any other people who will need access to it?
The CMS also needs to be assessed for usability as most users will be non‐technical.
4.2 EASE OF USE OF THE WEBSITE AND THE CMS Due to the need to make the information on the website publicly available we have to ensure that we make the user interface simple enough to use, so that anyone can use it to get at the basic functionality and information. It
22
may be necessary to provide professional users with more complexity and complicated functionality for their needs.
4.3 WHAT ARE THE MAIN FEATURES OF THE WEBSITE? What are the main functions of the website that are most critical for its success? We need to look at these and ensure that the CMS and technology chosen for the build will meet our needs. How will assessments be entered, assessed and approved? How would we like statistics to be displayed? What data will be captured, manipulated and displayed by the website and how? How easily and gracefully can your most important features be built into the chosen CMS framework? Most CMS frameworks offer the ability to build your own plug‐ins to create the functionality required. The support for and complexity of these plug‐ins varies from CMS to CMS. During the build of the prototype it will be determined whether the necessary plug‐ins for the RP CHM can be built with the Mura CMS. It may be necessary to evaluate other CMS systems for comparison.
4.4 HOW QUICKLY IS THE WEBSITE NEEDED AND WHAT IS THE BUDGET? How critical is time? Is the website required to be up and running quickly? A custom built CMS takes much longer to build than customising an off the shelf pre‐built one, such as Mura.
A custom build usually costs a more to get up and running, in terms of time and money, versus a pre‐built CMS. It may be decided that the extra investment at the start of the project to build your own CMS is worth it to ensure you can easily change or extend the website over time. If a pre‐built CMS is going to be harder and more expensive to customise to meet future needs, then even though its quicker to get the site up and running with the pre‐built CMS it might end up costing more down the line to customize it for your needs. All of the points in this section need to be considered when making a decision, and not just time and money.
4.5 FUNCTIONALITY OF THE CMS ADMINISTRATION INTERFACE Who will be using the CMS administration interface? There is a need to think about who will be creating and maintaining content via the CMS administration interface. How computer literate will they be? This is important as if the users are expected to be programmers or web developers then the interface can afford to be more complicated and less user‐friendly than if the users will be non IT. This still needs to be clarified for this website, and we also need to think about how heavily the CMS will be used, an how often content will be created or changed. We will need to assess this against the chosen CMS for the final build, to ensure it meets our users' needs.
4.6 WEBSITE STATISTICS What statistics do we need about the traffic coming to the website? This needs to be considered so we can assess whether the CMS chosen provides sufficient (if any) statistics, do we need to supplement the statistics provided with something more complex such as WebTrends? This is something that may change over time and become more important as the website gradually grows in usage.
4.7 SEARCH ENGINE OPTIMISATION (SEO) Search engines find websites by sending out spiders to crawl the web and index sites as they go. Sites are ranked according to many different criteria. For most websites it is of extreme importance to be highly ranked, for example a site selling t‐shirts would ideally want to get to the first page of google. This need may not be so
23
important for this site, but it does need to be considered and assessed against the CMS and whether it will be possible to build a website with it that is sufficiently SEO friendly.
4.8 PREFERRED TECHNOLOGY There may be a case for selecting a particular technology because there are already other applications running on that technology which we would like to integrate with the CMS, in this case we already have the GRAME database built in SQL Server and ColdFusion. Another case could be that going forward a particular technology choice will be easier to support.
5.0 REFERENCES • Notes from Working Meeting (Arendal, Norway, 14‐18th September, 2009) by Emily Corcoran.
• Concept and Mind Map originally developed by Francine Kershaw and further refined at the Working Meeting in Arendal.
• MURA documentation.
• Judy A. Roberson, et.al, Energy Use and Power Levels in New Monitors and Personal Computers, July 2002.
• Black Google Would Save 750 Megawatt‐hours a Year, http://ecoiron.blogspot.com/2007/01/black‐google‐would‐save‐3000‐megawatts.html.
24
CHAPTER 3: CONCEPTUALIZATION OF A DATA MANAGEMENT SYSTEM FOR THE REGULAR PROCESS
CLEARINGHOUSE MECHANISM
1.0 WHY CONSIDER A DATA MANAGEMENT STRATEGY? When evaluating a strategy for managing information and data pertaining to the Regular Process, key elements inherently need to be considered. These include:
• Assessments need data and information;
• The need to be able to determine and communicate change by comparing data subject to temporal and spatial variations;
• The gathering of disparate data sources, and/or establish global standards, in order to consider global;
• The need for the information on which the assessment is based to be derived in a credible and transparent manner, in order to ensure the credibility of the assessment;
• Data and information used and generated during the Regular Process must be traceable, and assessments must be archived.
In order to achieve its goals, in a credible, transparent, legitimate and salient manner, the Regular Process will inherently be dependent on a well‐structured and user‐friendly data and information management system.
The Data Management Centre represents a key feature of the CHM and will provide the primary assessment data interface for the Regular Process. The development of the Data Management Centre will require a great deal of research and must continue to be informed by the next stages of the Regular Process. This section focuses on the possible options that would best serve the hard data management requirements for a Regular Process and illustrate the respective benefits and caveats of each approach.
It is intended that this document will serve to guide the discussions and inform decisions that will need to be taken by Experts charged with preparing for the implementation of the Regular Process.
The recommendations presented here are provided in the context of the experiences of UNEP/GRID‐Arendal in developing a number of data and information management systems including: 1) the UNEP Shelf Programme’s One Stop Data Shop (OSDS, www.continentalshelf.org)) in itself a Clearinghouse Mechanism founded on a partnership involving 12 of the world’s top public marine geoscientific institutes and 2) State of the Environment web‐based tools (i.e. Government of Abu Dhabi).
25
2.0 DATA AND INFORMATION MANAGEMENT FOR THE REGULAR PROCESS: THE FUNDAMENTALS
2.1 STARTING POINT: KEY ISSUES TO BE CONSIDERED To help guide the development process of a data and information management system for the Regular Process, we provide as a starting point, a series of key issues that the expert group need to be clear on when considering a roadmap towards an appropriate platform:
1. What are the key data needs (inputs and outputs) to be addressed by the data and information management system?
2. What are key challenges to be considered?
It is important to emphasize that all identified needs with respect to data and information management must be in line with the overall vision and strategy of the Regular Process’ Clearinghouse Mechanism. The needs and challenges exemplified below merely act as a starting point for the Group of Experts that will be tasked with deciding on the approaches and methods for implementing the Regular Process.
2.2 KEY NEEDS:
• A system that can receive, hold and share the “hard” data and its associated metadata collected by all contributors and partners to the Regular Process and deliver products in a consistent, transparent and efficient manner to all users.
• A system that can collect the “soft” data from all contributors and partners to the Regular Process and deliver them in a uniform, transparent and efficient manner to all users (this aspect of the system is the focus of other areas of the CHM and is dealt with in Chapter 2).
Similar to the Intergovernmental Oceanographic Commission’s (IOC) Strategic Plan for Oceanographic Data and Information Management (2008‐2011), a data and information management system for the Regular Process should, in the least, enable regular, credible and salient assessments of the marine environment through the use of:
Assembled, quality controlled and archived information based on a broad range of credible, scientifically derived data adhering to sound, well‐documented standards and formats;
A mechanism providing for timely dissemination of diverse types of data and information derived from observations and model outputs and linked the needs of various user groups and their respective technical capabilities;
A platform ensuring the easy discovery and access to multithematic and multidisciplinary data and derived products by users with a broad range of capabilities and understanding (e.g. scientists, media, general public, policy makers)
3.0 GENERAL APPROACHES TO HARD DATA MANAGEMENT
26
The above elements form the basis for a holistic examination of an integrated system that manages all types of data and information that will flow through the CHM. As the issues revolving around the management and use of “soft data” are examined in a different section, we will focus here on elements of “hard data” management and in particular how these are inextricably linked to the dependence of the regular process on the development of various indicators that will be based on access to concrete, credible data from multiple sources.
3.1 “HARD” DATA MANAGEMENT: THE BASICS A key component to the successful implementation of the Regular Process is the assurance of access to credible scientific data and information necessary to develop the various data tools and indicators used to assess, predict and monitor the global ocean environment. The following core assumptions are made when considering a roadmap towards the development of a data and information management system:
1. Data providers for the Regular Process are assumed to be a combination of national focal points (that provide information and data for national indicators) and international scientific institutions/organizations/entities (that provide trans‐boundary information and data for global, regional, sub‐regional and national scale indicators); relevant regional organizations and projects;
2. Data providers for the Regular Process are numerous and are distributed globally;
3. Data providers have a vested interest in the maintenance and longevity of their own data systems;
4. Data providers have limited financial and human resources to dedicate to a technical process designed to adapt their system to an external standard;
5. The Regular Process will require access to historical, new and real‐time (or near real‐time) data, metadata and information from multiple sources;
6. The Regular Process will require a credible, efficient and transparent data quality control mechanism.
Based on the above assumptions, two scenarios are proposed as likely roadmaps towards a data and information management system: Scenario 1 is based on a centralized approach where data from data holders is transferred to a local system managed by a partner of the Regular Process and Scenario 2 is based on a decentralized approach whereby a central data and information inventory is stored locally and actual data remains with the remote data holders. The benefits and challenges of each scenario are presented.
The Group of Experts charged with clarifying the implementing methodology for the Regular Process would need to take a decision as to which data management approach is most appropriate.
Figure 2a: Centralized approach. Data providers (researchers, projects, research cruises, observation platforms) do not have (or have limited) data management capabilities or are unconstrained by certain (e.g. political) data sharing policies. All data is sent to a central physical repository and provided to the user from the central system
27
Figure 2b: Decentralized approach. Each data provider has a data management capability. Data holdings remain with the originating data centre. The data are dynamically accessed via a central distribution system that holds an inventory of the data contents of each provider. The user accesses the inventory, selects the required data, and the central system assembles a compilation by gathering the data from the remote systems. This model provides improved inter‐ agency cooperation and coordination and allows for the institution of uniform data and metadata standards and protocols at the user end
3.2 SCENARIO 1: CENTRALIZED APPROACH A centralized approach involves the development of hardware and software based infrastructure at a chosen physical location. Data is transferred to a system that is held and managed at a particular location (e.g. the Secretariat of the Regular Process, or a designated partner).
Pros:
• Imposed standardized input (caretaker has full control on how data is input); leads to ease of data handling and output (circumvent interoperability issues);
• Centralized quality assurance and quality control (QA/QC);
• Flexibility to develop data tools (e.g. analysis) and data derived products;
28
29
• Embedded commitment of data holders (and data holder overseers) to the Regular Process; common interest in provision and distribution of data via the UN system;
• First hand control of security.
Cons:
• Political barriers to “transfer” of national or institutional data to a non‐national location;
• May be les conducive to development of a process designed to make allowance for accessing restricted data or data under moratorium;
• Long term funding for infrastructure and maintenance staff;
• Burden of interoperability (financial and human resources) placed on data holders;
• Difficulty in handling/distributing the often large volumes of data.
3.2.1 EXAMPLE OF SCENARIO 1 SYSTEMS (CENTRALIZED REPOSITORY): Geophysical Data System (GEODAS); National Geophysical Data Center, USA, http://www.ngdc.noaa.gov/mgg/geodas/geodas.html
GEODAS (GEOphysical DAta System) is an interactive database management system developed by the National Geophysical Data Center (NGDC) for use in the assimilation, storage and retrieval of geophysical data. GEODAS software manages several types of data including marine trackline geophysical data, hydrographic survey data, aeromagnetic survey data, and gridded bathymetry/topography.
The GEODAS system is founded on US‐government mandates requiring that data acquired using public funding be submitted to a central repository. The GEODAS repository itself is divided along thematic lines that include:
• Marine Trackline Geophysical Data;
• Hydrographic Survey Data;
• Aeromagnetic Survey Data;
• Worldwide Multibeam Bathymetry;
• US Coastal Relief Model Grids;
• Great Lakes Bathymetry Grids.
Data providing institutions submit data and metadata in respective formats that are logged into the GEODAS system. The physical data delivery system requires large‐scale data storage, logging and delivery infrastructure that is dependent on secure funding to maintain long term viability.
30
3.3 SCENARIO 2: DE‐CENTRALIZED APPROACH A de‐centralize approach involves the development of a software based system (“black box”) that ensures interoperability between multiple remote data holders and their systems. In practical terms this would involve software systems designed to recognize and read information and data from multiple sources organized according to local architectural specifications and converting the input into a standard architecture or format that serves output needs. An inventory of the data and information is stored locally while actual data remains with the remote data holders.
Pros:
• Fewer political barriers; agreements are based on access to and use of data rather than complete copy/transfer to new “beyond national/institutional control” site;
• May be more conducive to the establishment of a process making certain allowances to accessing restricted data or data under moratorium;
• Lower costs: software development involving specific data types and holders is typically cheaper than building hardware‐based infrastructure; some systems already exist (at least in the marine world; e.g. ArcIMS/SDE);
• Physical site independence; a software‐based “clearinghouse” can be run from any regular server; reduction in long term funding requirements…or more funding applied to data product development and use of data;
• More marketable in terms of imposing “standards” on the data holders; the fewer resources data holders would need to commit to a technical process, the more agreeable they are likely to be to a process;
• Updating of remote databases is reflected automatically in the centralized inventory with minimal effort on the part of the clearinghouse;
• Better “load sharing” of large data volumes between the various data management systems.
Cons:
• High reliance on remote data holders and their capacities (e.g. system troubles, network failure, financial constraints on operations);
• Quality assurance and quality control (QA/QC) may be more difficult to ensure; this is dependent on remote data holders and their capacities.
3.3.1 EXAMPLES OF SCENARIO 2 SYSTEMS (DE‐CENTRALIZED REPOSITORY): The European Marine Observation and Data Network (EMODNET)
URL: www.eurogoos.org/eurogoos/publications/MB_EuroGOOS%20EMODNET%20Vision_final.pdf
EMODNET is an under‐development EU initiative designed to be an end‐to‐end, integrated and inter‐operable network of systems of European marine observations and data communications, management and delivery, supported by a comprehensive user‐oriented toolkit to enable implementation of the Integrated Maritime Policy
31
for Europe. In essence, the vision of the UN Regular Process is a more global version of EMODNET and thus the data and information management approach of EMODNET I perhaps one of the best templates for which to develop the Clearinghouse Mechanism for the Regular Process.
At its core, EMODNET will be based on “a network of existing and developing European observation systems, linked by a data management structure covering all European coastal waters, shelf seas and surrounding ocean basins, accessible to everyone.” Technically, EMODNET will be established as a “system of systems” linking a number of remote systems via an established an agreed upon data sharing standard.
There are 6 key data components to be handled by the EMODNET “system of systems:
• Data from small scale sensors deployed to provide continuous measurements;
• Data from large scale deployed platforms or structures and from satellites;
• Data from sampling and consecutive laboratory analysis;
• Real‐time data communications and transfer systems;
• Data collection and management systems;
• End user, web‐based applications and tools for analysis purposes.
The EMODNET committee has identified a number of distinct actions that will be necessary to build and sustain an effective platform:
• Discovery of existing holdings of marine data relevant to identified needs;
• Performance of gap analyses to determine where the shortcomings in existing data lie for the coastal and open oceans;
• Coordinated, joint investment in sustainable, efficient observing systems;
• Removal of the impediments preventing full, free and open access to data;
• Implementing collaboration and governance arrangements to sustain the EMODNET platform.
These actions would be reflected in similar fashion within the planning and implementation phases of a data and information management system for the Regular Process.
The UNEP Shelf Program One Stop Data Shop
URL: www.continentalshelf.org
The UNEP Shelf Programme has developed a One Stop Data Shop (OSDS) for use by coastal states preparing a submission delineating the outer limits of their continental shelf. The OSDS consists of a global geospatial and metadata inventory of marine geophysical and geological data. In addition to providing users with a single web‐based portal that allows for the analysis of public marine geoscientific data available in a specific area of interest, agreements with participating institutions allow for distribution of data to eligible states on a request basis.
32
Global inventories of 9 key marine data types are handled by the OSDS:
• Multibeam bathymetry
• Singlebeam bathymetry
• Marine magnetics
• Marine gravity
• Marine navigation information (e.g. MGD77 data)
• Analogue seismic imagery (reflection and refraction
• Marine petrological samples
• Marine sediment samples
• Ocean drilling samples and sediment cores
The basic architecture of the OSDS relies upon partnerships established with remote data holders allowing for re‐directed access from the OSDS web portal to their holdings according to specified data access criteria. Eligible users can also request data compilations that rely on an internal geospatial search engine that can search the full inventory according to prescribed parameters and provide a GIS‐compatible data project.
The OSDS also provides a basic, standardized metadata service that relies on internally‐developed information mining software that populates metadata fields in publicly available web forms. This is an in‐direct approach at metadata standardization that does not rely on the remote data holding organization.
Global Earth Observation System of Systems
URL: www.earthobservations.org/gci_gp.shtml
GEO is a voluntary partnership of governments and international organizations. It provides a framework within which these partners can develop new projects and coordinate their strategies and investments. As of September 2009, GEO’s Members include 80 Governments and the European Commission. In addition, 56 intergovernmental, international, and regional organizations with a mandate in Earth observation or related issues have been recognized as Participating Organizations.
The Global Earth Observation System of Systems will provide decision‐support tools to a wide variety of users. As with the Internet, GEOSS will be a global and flexible network of content providers allowing decision makers to access an extraordinary range of information at their desk.
This ‘system of systems’ will proactively link together existing and planned observing systems around the world and support the development of new systems where gaps currently exist. It will promote common technical standards so that data from the thousands of different instruments can be combined into coherent data sets.
The ‘GEOPortal’ offers a single Internet access point for users seeking data, imagery and analytical software packages relevant to all parts of the globe. It connects users to existing databases and portals and provides
33
reliable, up‐to‐date and user friendly information – vital for the work of decision makers, planners and emergency managers.
Ocean Biogeographic Information System (OBIS)
URL: www.iobis.org
OBIS was established by the Census of Marine Life program (www.coml.org). It is an evolving strategic alliance of people and organizations sharing a vision to make marine biogeographic data, from all over the world, freely available over the World Wide Web. It is not a project or program, and is not limited to data from CoML‐related projects. Any organization, consortium, project or individual may contribute to OBIS. OBIS provides, on an ‘open access’ basis through the World Wide Web.
The OBIS data and information management architecture is based on workflow that provides data contributors with a standardized submission format to allow for incorporation of data into the system. There are two models of data sharing used by OBIS:
Distributed data contributor status (this more closely resembles a Scenario 2 architecture): This means that you keep your dataset locally, and set up a server that can respond to OBIS queries. This requires "mapping" your dataset to the OBIS schema and installing a free software package called DiGIR to communicate with the portal.
Direct data contributor: You provide your data set in electronic form to a Regional OBIS Node, the central data portal, or another existing Data Provider, and it is published from there. In order to enhance standardisation, a template is provided to data contributors.
3.4 CHALLENGES AND ADDITIONAL CONSIDERATIONS FOR DATA MANAGEMENT Based on the experience of UNEP/GRID‐Arendal in developing a dedicated data and information management system and on an examination of strategies developed by other organizations (e.g. IOC, Proceedings of the International Data Exchange Workshop 2008), the following challenges need to be considered early in the system development process and in the detailed methodological design of the first assessment for the RP in order to have a satisfactory data and information exchange system:
Data Access: Gaining access to data via partnerships and agreements inherently touches upon sensitivities including political considerations, justification for the local system (i.e. if data holdings copied to centralized repository, it may become difficult for data holders to justify the resource expenditures required for their own systems), data moratoria (assurance of principle investigators’ rights of first publication) and protection of commercial interests (i.e. some institutions are set up as public with an expectations of generating some income from their data and services).
Data interoperability: Interoperability between global data holders remains an elusive element. The lack of interoperability inhibits the ability to instill complete data discovery (global inventories) regardless of physical location.
Duplication: Data, and data product duplication is an inherent problem when dealing with data and information exchange amongst a number of partners and data holders that may have already exchanged data as part of a
34
previous activity or data sharing initiative. This can lead to a lack of clarity with respect to the status of datasets (e.g. which version is the most up to date?), which in turns leads to user confusion.
Quality: Quality assurance and quality control of data produced by multiple, unrelated data providers is vital issue that lacks any comprehensive, universal solution. This leads to the questioning of distributed data and data products by users who very often do not have access to a proper, standardized quality assurance mechanism.
Different data types: The handling of multithematic and multidisciplinary types of data remains a difficult technical consideration. Data types from disciplines like biology and geology are inherently constructed around each type’s required attributes and handling structure.
Data standards: The question of data standards, between institutions, organizations, countries…etc remains a hotly contested topic in the global scientific data community. Addressing the handling of differing standards and their formats (e.g. ISO, NetCDF) needs to be considered in the development phase.
Data provision/output: Regardless of issues affecting data and information input to the system, data output must be effected in an efficient, standardized and transparent manner. Consistency in data provision, including the inclusion of a data quality assurance mechanism, promotes user confidence, helps ensure ongoing compatibility and allows for long term analysis of data trends. This enhances the “regular” in Regular Process.
Metadata: Metadata or “data about the data” is an intrinsic element of any data package. Without properly reported metadata, actual data can be rendered unusable. Metadata is generally provided according to a chosen reporting standard (e.g. FGDC, Dublin Core, IEEE1451, ISO19115/19139). There is no commonly agreed international standard for metadata in most of the marine disciplines that will contribute to the Regular Process. This means that an appropriate approach to the handling of metadata provided using various standards be considered as an integral part of the development of a data management system.
3.4.1 ADDRESSING ISSUES OF DATA MORATORIA Many institutes rely on periods of moratoria within which new data cannot be shared without explicit permission of the principal investigator(s). This principle will be difficult if not impossible to circumvent regardless of the cooperative desire of an institution or country. It is a cornerstone of the scientific method and should not be a focus of effort to modify. Instead, different strategies (2 examples below) could be used to circumvent the issue while allowing some accessibility to new data that may fall under a period of moratoria. It is understood that many data tools and general indicators for the Regular Process would be highly dependent on access to the latest, most up to date data and information.
Example 1:
New web‐based applications are available that allow data derivatives to be produced from a restricted dataset without the actual raw data being distributed. A remote user can access a database and request a product that may include restricted data or data under moratorium. A back‐end (internal to the data system) application will then prepare that product (in real time or with delay) and provide it to the remote user via a web application. The user can then visualize a derivative of the restricted data without being able to access the raw data. In some cases, the user can even add their own data from their local system to the mix.
35
Example 2:
In conjunction with the principle investigator(s) associated with restricted data or data under moratorium, a list of registered users (individuals or organizations) can be agreed upon for whom access to the data in question is permitted in accordance to established protocols. This could be a mechanism allowing for work on updating critical indicators or the production of other relevant data products can proceed with the incorporation of the latest available data.
3.4.2 MULTIDISCIPLINARY DATA INTEROPERABILITY It is clear that with the advent of today’s vast data collecting capabilities combined with the contents of existing global data archives, a voluminous amount of information from a wide range of disciplines is available to contribute to the Regular Process. An important challenge when establishing a methodology for implementing the data management component of the Regular Process involves insuring that these different “data families” (e.g. biological/physical vs socio‐economic) are fully interoperable with each other. In others words, as the assessments of the Regular Process will be dependent on analyses conducted on a number of multidisciplinary datasets having to be examined together, any data management system must ensure that some common denominator (e.g. geospatial) exists for these datasets so that they may be examined and analysed as a coherent assemblage.
4.0 SUMMARY The above document has served to highlight the various key issues and challenges involved when evaluating concepts for the development of a data management system for the Regular Process. In addition, certain case studies presented serve to provide “real‐world” examples of functioning data management systems.
4.1 RECOMMENDATIONS FOR ACTIONS TO BE TAKEN The following actions points represent the recommended decision‐making elements needed in relation to the development of a data management system to serve the needs and priorities of the Regular Process:
1. Assess the human, financial and technical resources that will be available for both the development AND long term viability of the data management system (i.e. infrastructure, technical expertise);
2. Evaluate all potential synergies with other large scale marine data portals (e.g. GEOSS, EMODNET) to avoid duplication of work and, where relevant and possible, take advantage co‐development opportunities;
3. Evaluate the data management conceptual models (e.g. centralized, de‐centralized, mix of both) in the context of: a) the core goals of data management for the Regular Process and b) action point 1.
5.0 RECOMMENDED READING • Information sheets on the development and implementation of the Global Earth Observation System of
Systems: http://www.earthobservations.org/about_geo.shtml
• IOC Manuals and Guides No.5‐2n revision: Guide for Establishing a National Oceanographic Data Centre: http://www.iode.org/index.php?option=com_oe&task=viewDocumentRecord&docID=886
36
• Intergovernmental Oceanographic Commission Strategic Plan for Oceanographic and Information Management (2008‐2011): http://www.earthobservations.org/about_geo.shtml
• Strategic document for the European Marine Observation and Data Network: http://www.eurogoos.org/eurogoos/publications/MB_EuroGOOS%20EMODNET%20Vision_final.pdf
37
CHAPTER 4: KEY CONSIDERATIONS AND RECOMMENDATIONS The following table synthesizes some of the decisions that are required in order to move forwards with the concept of a knowledge management system for the Regular Process. The table presents to the reader the issues for consideration, the decisions required, some considerations that need to be taken into account and recommendations, where appropriate based on experiences of the team and in the development of the prototype. The table also directs the reader to the chapter and section where more detailed information can be found. It is critical that these questions are considered and decisions taken at the planning stage in order to ensure that the components of the regular process will be credible, legitimate and transparent.
Table 1: Considerations, Decisions, and Recommendations for developing a knowledge management tool to support a Regular Process
Issue Decision required Considerations for reviewers/ Group of experts
Recommendations More information
Need for knowledge management to support the Regular Process (RP)
Is a knowledge management system, such as a clearing house mechanism (CHM), required to support the Regular Process?
Availability of resources, budget, developer, web manager;
The current prototype cannot develop further without approval and resources.
Consider further development of this prototype CHM;
The Prototype RP‐CHM is presented at a technical workshop.
This document and http://development.unep‐wcmc.org/mura/rpchm/index.cfm
Workshop outline: Annex 1
Prototype website vision and design principles
Approval of design
Should the site be a carbon neutral site?
Is the style, look and feel appropriate for a Regular Process Clearing House Mechanism?
Use a dark colour palette and the proposed site design.
Executive Summary, Figure 1;
Chapter 2, 1.0
Approval of logo choice Which logo design should be used?
Square logo with no colour gradients Chapter 2, 1.3
Accessibility Is the site to be multi‐lingual?
If so, should this be implemented through the CMS or using automated tools such as Google translate?
Suggest an auto‐translate tool, such as via Google Translate, which although will inevitably have some inaccuracy, does not involve the costs of processing and storing
Chapter 2, 2.1
38
multiple language versions
Ease of navigation Is the navigation system accessible?
Is the website organised in an intuitive manner?
The user should feel comfortable to access all pages on the site from the top menu and this is available on every page
Chapter 2, 1.4 and 2.4
Are the help resources adequate?
Can the user access assistance if required.
Provision of visual help tools, e.g. online tutorials, for the more complex aspects of the site as well as text in PDFs to increase accessibility to users
Chapter 2, 2.6
Technical considerations
Approval of the choice of Content Management System (CMS) and technology for tool development
What is the preferred technology?
Off the shelf CMS recommended if limited time and resources and limited need to customise. Develop bespoke CMS if high resources and need for significant future customization
Chapter 2, 4.0
Administration and hosting
Where should a RPCHM be located (internet location/URL)?
Consider existing resources and sites, and the need to consolidate rather than create too many locations
Use of the www.unga‐regular‐process.org url for the CHM
Where should such a tool be hosted?
Who will be the administrators of a RP CHM?
Hosting would require a suitable server and technical capacity; there will be associated maintenance and update costs.
Should there be a dedicated web developer to maintain and update the site?
For discussion by lead agencies/relevant experts.
The decision should look forwards to the next 5 years as a minimum time frame.
The site has been designed using a system that does not require the services of a web programmer, however there should be resources for technical capacity/training to ensure that the tool can be maintained
Chapter 2, 2.2
39
Who should be able to access the site?
Different access rights will be required by different types of users;
Security arrangements to protect the back end and databases;
Proposed that there should be four user types with different access rights;
Recommended that the CMS admin system have its own URL with access limited to a few users and with no link from the public site for security purposes and to prevent unauthorized access
Chapter 2, 1.6
Content and the CHM Are there any significant gaps in proposed content?
Review the prototype site and the content specifications to identify potential gaps.
Chapter 2, 3.0
http://development.unep-wcmc.org/mura/rpchm/index.cfm
Considerations for data management and design of a DMC
What are the key data needs (inputs and outputs) to be addressed by the data management centre?
The DMC must be designed so it can assist in the delivery of assessments
What type of information and data will be required for these assessments?
Who will the data providers be?
Transparency, credibility and efficiency of data access for the RP
Two scenarios are proposed for consideration by the relevant experts: a centralized or decentralized approach to data management. Pros and cons are presented for each, with examples.
Challenges that need to be considered in data management are also presented
Chapter 3
Is a strategic plan for data and information management within the RP required?
The data requirements to enable a global assessment will be complex.
Consider the need for a strategic plan for data management before the DMC is constructed to ensure that it can deliver what is required by the assessment cycles.
Chapter 3, 2.2
The human, financial and technical resources available for data
Need to consider the development and running of such a DMC.
Before the DMC can be designed, there needs to be clarity to the questions identified in chapter 3 of
Chapter 3
40
management What infra structure is required?
What technical capacity is required?
Are there opportunities for synergies with other large scale data management initiatives?
this report.
Where possible synergies and linkages should be investigated with other existing initiatives for managing marine data.
Site Feedback and Reporting
What kind of web reporting is needed?
Is there a need to employ Webtrends to get regular feedback on usage of the site?
Need to track user satisfaction to keep the tool relevant.
Recommended that in order to maintain quality and continue to meet user needs, the site is monitored (including web counts, origin etc);
Free statistics are available – these need to be evaluated for suitability
Chapter 2, 2.7
Visibility and marketing How important is search engine ranking?
How easily can users find the site?
If search engine ranking is important then Search engine Optimisation (SEO) techniques should be employed
Chapter 2, 2.8
41
ANNEX 1: PROPOSED 2.5 DAY WORKSHOP FOR
PRESENTATION AND CONSIDERATION OF THE RP CHM Context:
In preparation for the first cycle of a Regular Process for global reporting on the state of the marine environment, including socio‐economic aspects, UNEP and and IOC‐UNESCO have requested that GRID‐Arendal and UNEP‐WCMC develop a prototype Clearing House Mechanism that could serve as an online and living knowledge management tool. The first draft of the prototype was presented to UNEP in December 2009 for consideration.
Workshop Aim:
To present the prototype Clearing House Mechanism, its design features, functionality and questions that require decision making to continue the next phase of its development.
The online protoptype will form the basis of discussion regarding key decisions that need to be made both on the value of a clearing house mechanism, and how it will support the Regular Process if the first cycle Regular Process is adopted by the UN General Assembly.
Outputs:
1. Agreement as to whether or not a Clearing House Managment tool is required for the Regular Process;
2. Decisions on key aspects of the approach and methods for implementation of the first cycle of the regular process, to inform the next phase of the RP CHM development;
3. Agreement on the technical and content specifications for a Regular Process CHM in order to finalise the design and functionality
4. Next steps with regards to develoment of the RPCHM, in particular with respect to the DMC (including resourcing and timelines)
Participants:
Lead Agencies; Experts in data management selected by the Lead Agencies through UN process; Representatives from UNEP/GRID‐Arendal and UNEP‐WCMC (max 20)
Estimated budget :
Including DSA (3 days), Travel, refreshments, logistics, and project staff time for preparation and follow up: USD 100,000
N.B. Funding and organisation of such a workshop is dependent on approval by the lead agencies and the identification of funds.
Timing:
Latter part of Quarter 1 or early part of Quarter 2, 2010
42
Proposed Agenda:
Item 1. Welcome and Opening
Item 2. Adoption of Agenda
Item 3. Introduction of Participants
Item 4. Presentation of the project approach and the prototype RP CHM; discussion
Item 5. Presentation of key decisions needed
Item 6. Consideration of key decisons
Item 7. Presentation of considerations for a DMC and overview of key decisions needed
Item 8. Consideration of key decisions
Item 9. Review of Decisions made
Item 10. Define next steps
Item 11. Any other business
Item 12. Close of meeting
43
ANNEX 2: SUMMARY OF GRAME DATABASE UPDATES
AS OF DECEMBER 2009 This Annex provides a summary of all the updates to the Global and Regional Marine Assessment Database (GRAMED) undertaken by the United Nations Environment Programme‐World Conservation Monitoring Centre (UNEP‐WCMC) as specified by the Terms of Reference provided by UNEP/GRID‐Arendal for the project “Assessing our oceans and update of the GRAME Database”.
1.0 EXPECTED OUTPUTS UNEP‐WCMC lead an update of the GRAME Database to reflect the finalization of the ‘Assessment of Assessments’ publication, increase and improve functionality, support a Quality Control and Assurance procedure for data entries, and streamline the database for long‐term sustainability, through the following activities:
• Input of most up‐to‐date assessment data in order to ensure content is increased for currently under‐represented regions such as the Black Sea and that the best available data is included in the statistical analyses available through the site.
• Revise content to reflect the finalisation of the ‘Assessment of Assessments’ (AoA) report.
• Incorporate the interactive regional map originally developed by GRID‐Arendal in support of the ‘Assessment of Assessments’ process. The map will allow the assessments held within the database to be spatially referenced and provide the user with the ability to explore database statistics geographically in a way that reflects the Assessment of Assessments report.
• Support a Quality Control and Assurance (QC & A) procedure for assessments within the Database to be undertaken by Experts.
• Streamline the database, only making available the 15 key summary fields for all assessments not entered and reviewed by Members of the Group of Experts.
2.0 UPDATE SUMMARY
2.1 DATA ENTRY Details of over 500 marine assessment activities were entered into the database over a two month period building the number of activities held to 968 by December 2009. The activities were sourced from an existing spreadsheet containing details of those identified by the Group of Experts and also from a web‐based review to ensure that the most up‐to‐date assessments were also included. The assessments added were prioritized so that the most under‐represented regions in the database, for example, the Black Sea, were entered first followed by the other assessments in the spreadsheet and finally the most recent activities.
2.2 REVISION OF CONTENT TO REFLECT AOA REPORT
44
The finalization of the Assessment of Assessment’s report prompted a number of changes to the database to ensure that information was standardized between the two products. A summary of these updates are listed below:
• Changed the region names to the ones agreed for the AoA report throughout the website and the database;
• Created a new page with the finalized Region Definition Table in order to assist users of the database with data entry and examination of the data.
• Links to the Region Definition Table were included on various pages of the site, such as the glossary and data entry forms;
• ‘About Us’ text was updated to reflect the finalization and launch of the AoA report.
2.3 INCORPORATION OF REGIONAL MAP The map of the 21 Assessment of Assessment regions was integrated into the website on a new page accessible through the primary menu. Functionality was added to the map so when the user clicks on a region statistical outputs from the database for that region are displayed in a pop‐up box. Pop‐up boxes can be repositioned by the user and more than one can be displayed at a time to enable inter‐region comparison. Links to the map were also included in a number of suitable places on the website including the Glossary and the data entry forms.
2.4 QUALITY CONTROL AND ASSURANCE PROCEDURE A Quality Control and Assurance (QC&A) procedure has been called for by the Lead Agencies, UNEP and IOC‐UNESCO. It is envisaged that a number of the members of the Group of Experts will undertake a review of all expert‐entered activities to ensure that the information is of a consistent high standard. UNEP‐WCMC will provide technical support to the Experts undertaking this process once it is underway. In the interim, all assessments entered by experts will be limited to the 15 primary fields until they have been subjected to review through this process.
2.5 STREAMLINING GRAMED In light of the quality control circumstances described in section 2.4, and also given the large amount of empty fields in the activity data forms, it was recommended to the Lead Agencies that for all activities apart from those subjected to expert review; the data made available to the user will be limited to the first 15 compulsory, summary fields:
1. Scale
2. Region
3. Name of Assessment
4. Acronym
5. Full Reference
6. Full Text Reports/Output URL
7. Assessment reviewed by GoE member
8. Classification/Type of Activity
45
9. Organisation
10. Justification/Context of the Assessment
11. Objectives of the Assessment
12. Status of Activity
13. Is the assessment repeated?
14. Start Date
15. Finish Date
The entire 60 fields will only be made available for those expert entered assessments which have undergone the QC&A procedure described in section 2.4. This process will ensure the long‐term sustainability of the GRAME Database as a comprehensive and manageable directory of marine assessment activities.
2.6 ADDITIONAL UPDATES A number of additional updates were also undertaken to improve the GRAME Database’s performance and functionality.
2.6.1 ADMINISTRATION AREA Updates were made to improve and increase the efficiency of the Administration Area:
• An option was added to delete incomplete assessments;
• Built a new ‘organisations’ section with options to view, edit or delete organizations, add new organizations and view assessments by organization.
2.6.2 CHANGES TO SEARCH TOOL • Simplified the number of search options so that users can only search relevant fields;
• Added ability to search by ‘organisation type’;
• Fixed the search results so that the user can use the back button on the browser to access their original search results or through the added ‘Back to Search Results’ link. Previously, search results were not stored in this way and serach results were lost if the user clicked away from the results page;
• Search results listed in alphabetical order;
• Errors experienced using the ‘Admin Export’ function was addressed so that all results can now be exported successfully.
2.6.3 DATABASE UPDATES The database had many issues which were staring to cause problems, for example, hanging records when something is deleted from one table that exists in another, duplicate data etc. These issues would have created more significant performance problems as the Database continued to grow in size.
The following activities undertaken to address these problems and will ensure that the Database delivers high performance both now and in the future:
• Primary keys were added to all tables, improving data performance and ensuring data integrity;
46
• Field types were changed from text to something more meaningful where possible;
• Default field values and constraints were created where needed;
• Data clean‐up was undertaken to remove duplicates, address misspellings, and correct bad relationships between tables. ‘Organisation’ data was causing a number of specific problems within the database, including incorrect search results and statistics, and so was a particular focus of data clean‐up, duplicates and unused organizations were removed and bad relationships between organsiations and assessment records were addressed.
2.6.4 FEEDBACK FORM A small change was made to allow users to choose “Make a Comment” from the dropdown menu, previously all feedback options were concerned with updating or requesting an assessment or log‐in so this provides the user with eth ability to make a more general comment concerning the site.
2.6.5 SUMMARY STATISTICS Updates were made to the Summary Statistics to increase accuracy and transparency for the user:
• Any errors in the statistics themselves were corrected;
• A “No Data Provided” field was added to a number of statistical outputs to provide the user with a comparable and more accurate result;
• Beside the statistics which draw from the first 15 summary fields, other statistics were changed so that they only draw from the assessments reviewed by the Group of Experts. Further updates may be needed following the QC&A review.
47
ANNEX 3: MULTIMEDIA PRESENTATION FEATURE
DEMONSTRATION: WHY DO WE NEED A REGULAR PROCESS?
A 3 minute multimedia sequence was developed for this project to demonstrate some of the potential features and communication tools that can be incorporated into the RP‐CHM. The presentation introduces the concept of why we need a Regular Process to assess and report on the state of the world’s oceans to a non‐technical audience. It is anticipated that this will also be of use for presentations as well as web users.
The presentation can be viewed at the following URL: http://development.unep‐
wcmc.org/mura/rpchm/index.cfm/unga‐regular‐process/
1. The oceans of our ‘blue’ planet represent an immense ecosystem. They cover 71% of the earth’s surface – the equivalent to twice the surface area of mars plus almost twice the surface area of the moon, have a volume of 1.3 billion cubic kilometres and embody 97.25% of all water found on earth
2. Our well‐being directly depends on healthy, functioning seas, seas which provide us with food, medicine and energy. They sustain our industries and play an essential role in regulating our global climate. Marine life and landscapes have great spiritual, aesthetic and recreational values.
3. Due to their enormity, the oceans have long seemed impervious to our influence. But today, there are many signs that marine ecosystems are experiencing unprecedented environmental change driven by the activities of man. . The cumulative and interactive effects of these different pressures over time can seriously disrupt whole ecosystems and the services they provide.
4. To effectively combat these problems, we need a better understanding of how human activities interact, and together affect different parts of the marine system.
5. There have been many assessments of the marine environment, which tell us a great deal of valuable information; and yet we still do not have a complete picture of the state of our global oceans. What we need is a systematic effort to keep under continuous, regular review the state of the world’s oceans and how we use them.
6. The United Nations have endorsed the need for a Regular Process , for global reporting and assessment of the state of the marine environment, including social and economic aspects, which will serve as the mechanism to keep the world’s oceans under continuing review by providing regular assessments at global and multi‐regional levels.
7. Based on sounds science, the Regular Process is structured around four fundamental building blocks aiming to: build capacity, improve knowledge and methods of analysis, enhance networks and the transfer of knowledge, and facilitate communication, in order to help improve responses from national governments and the international community to the challenges posed by these changes.
8. In order to responsibly manage our oceans, we need to act now to establish the Regular Process. This will ensure that the current lack of coherence of our assessment activities, which are delivering inconsistent messages to decision makers and doing little to improve the state of our marine environment, will cease and we can begin piecing the puzzle together in order to advance and enhance the sustainable management of the ocean.