##  1\. Execuve Summary

ODYSSEA intends to develop, operate and demonstrate an interoperable and cost-
effecve plaorm that fully integrates networks of observing and forecasng
systems across the Mediterranean basin, addressing both the open sea and the
coastal zone.

The plaorm is prepared to deliver a set of services focused on different
coastal user’s needs (navigaon safety, ports operaons, water polluon prevenon
and response, eutrophicaon risks, search and rescue missions, etc.) enabling
the exploitaon of the added value of integrated Earth Observaon (EO)
technologies (satellite, airborne and ground based), Copernicus Marine Service
and ICT to deliver customized and ready to use informaon. These services will
provide an easy way to access in-situ data, local high-resoluon forecasts and
products and services (e.g. meteo-oceanographic condions at specific locaons,
idenficaon of opmum or crical working windows, support to sea polluon response
acons, etc.) for a broad range of different users and stakeholders.

Taking in consideraon that this plaorm will gather a large number of diverse
data sets (from exisng networks and plaorms and the ODYSSEA-produced data
consisng of results from operaonal numerical models, data from in-situ sensors
and remotely sensed data), the issues of data management and data quality
control assume a central concern. One goal of the plaorm is to ensure that
data from different and diverse data providers are readily accessible and
useable to the wider oceanographic community. To achieve that, the strategy is
to move towards an integrated data system within ODYSSEA that harmonizes work
flows, data processing and distribuon across different systems.

The value of standards is clearly demonstrable. In oceanography, there have
been many discussions for processing data and informaon. Many useful ideas
have been developed and put into pracce, but there have been few successful
atempts to develop and implement internaonal standards in managing data.

This document intends to provide an overview of the best pracces concerning
these aspects and define the guidelines to be followed in themes such as
catalogues, metadata, data vocabulary, data standards and data quality control
procedures. This implies taking acons at different levels:

  * Adopt proper data management procedures to implement metadata, provide an integrated access to data in order to facilitate integraon into exisng systems and assure the adopon of proper data quality control. 

  

  * Enable integraon of more data, improve the enhancement of the services (viewing, downloading, traceability and monitoring) to users and providers, facilitate the discovery of data through a catalogue based on ISO standards, provide OGC services (SOS, WMS, WFS, etc.) to facilitate development; and ensure the visibility of exisng data and the idenficaon of gaps. 

  

As ODYSSEA is an EU supported Mediterranean-focused plaorm, the data
management plan will tune in all specific aspects of ocean data management
within the European context, such as exisng networks of data and requirements
of European industry and other end-users. This deliverable will be the final
and updated version of the Data Management Plan (DMP) for the ODYSSEA Plaorm,
including strategies for improving data management, data privacy issues and
data quality control procedures. In this updated document, problems faced
during the implementaon process, barriers and lessons learnt will be
discussed. It will further elaborate specific relevant aspects for ODYSSEA
namely the "new" data series approach using SOS, further integraon into the
ODYSSEA Plaorm among others.

##  2\. Introducon

ODYSSEA aims to provide a set of services focused on different coastal users’
needs (navigaon safety, ports operaons, water polluon prevenon and response,
eutrophicaon risks, search and rescue missions, etc.) allowing to exploit the
added value of integrated Earth Observaon (EO) technologies (satellite,
airborne and ground based), Copernicus Marine Service and ICT to deliver
customized and ready to use informaon. These services will provide an easy way
to get in-situ data, local high-resoluon forecasts and products and services
(e.g. meteo-oceanographic condions at specific locaons, idenficaon of opmum or
crical working windows, support to sea polluon response acons, etc.) to a
broad range of different users.

This report describes the strategies to be implemented to improve data
management, data privacy and data quality control of ODYSSEA services. The
strategy has four main components:

  * Catalogues, vocabulary and metadata; 

  

  * Data integraon and fusion; 

  

  * Data quality control; 

  

  * Data privacy policy. 

  

The issue of metadata, vocabulary and catalogues is of prime importance to
assure the interoperability and easy discovery of data. A proper data
management plan following widely accepted standards also contributes to the
reducon in the duplicaon of efforts among agencies. Likewise, the plan is to
improve the quality and reduce the costs related to geospaal data processing,
thus making oceanographic data more accessible to the broader public while
helping to establish key partnerships to increase data availability. Aiming to
contribute to these objecves, ODYSSEA will adopt the procedures already
proposed by the most relevant EU iniaves such as CMEMS, EMODNet and
SeaDataNet, especially the standards in relaon to vocabularies, metadata and
data formats. In pracce the gridded data sets addressing either dynamic data
sets (similar to CMEMS) or stac data sets (similar to EMODnet) will follow
procedures similar to the ones adopted by these two services. Regarding the me
series data, SeaDataNet procedures will represent the main guidelines and
NetCDF-CF format will be the standard to be adopted. However, **ODYSSEA will
go one step further and will use these NetCDF files to feed an SOS service,
supported by North 52 soware to assure the interface with the users of the
plaorm.**

The capability of serving me-series through a standard protocol, such as SOS,
will represent a step forward from the exisng services although, as a pioneer,
it is foreseen that ODYSSEA will be required to overcome some barriers. The
service has been tested in the ODYSSEA plaorm V0 Edion and it is one of the
subjects to be discussed and showcased in this updated/final version of the
ODYSSEA DMP.

The data integraon and fusion policies to be adopted in ODYSSEA are also
relevant issues of the project.

Data integraon and fusion deals with the best strategies to adopt when it
comes to merge datasets obtained from different data sources, building the
best available datasets or fusing different data sources to produce aggregated
data (i.e., secondary parameters and indicators). Although not easy,
addressing this issue properly may represent a valuable contribuon to improve
data accuracy and robustness of models’ inial and boundary condions and
provide the users with comprehensive data that merge different data sets based
on reliable criteria.

The data quality control either related with the quality of observed in-situ
data (e.g. dal gauges, wave buoys, weather staons, etc.) or the modelled
forecasts is another relevant aspect that will be addressed by ODYSSEA’s DMP.
In the case of locally acquired data, automac procedures will run regularly to
detect and remove anomalous values from observed datasets. In the case of the
models, the results will be automacally compared with observaons (e.g., buoys
and CMEMS grid observaon products) and the stascal analysis will be provided
on a daily basis to the end users.

Regarding data privacy (data protecon and the rights of plaorm end-users,
customers and business contacts), it is clear that ODYSSEA will respect
personal data under the General Data Protecon Regulaon (GDPR) (Regulaon (EU)
2016/679) which will substute Direcve 95/46/EC on May 25, 2018. ‘Personal
data’ means any informaon, private or professional, which relates or can be
related to an idenfied or idenfiable natural person (for the full definion,
see Arcle 2(a) of EU Direcve 95/46/EC).

In the following paragraphs a more detailed overview, both of the “state of
the art” and the procedures to be adopted in ODYSSEA, will be provided.

##  3\. Ocean Data Management: the European context

Delivery of data to users requires common data storage and transfer formats,
which interact with other standards  (Vocabularies,  data  quality control).
Several iniaves exist within Europe for ocean data management, which are now
coordinated under the umbrella of EuroGOOS. EuroGOOS is the network commited
to develop and advance the operaonal oceanography capacity of Europe, within
the context of the intergovernmental Global Ocean Observing System (GOOS). The
scope of EuroGOOS is wide and its needs are parally addressed by the on-going
development within Copernicus, SeaDataNet and other EU iniaves.

Therefore, to improve the quanty, quality and accessibility of marine
informaon, to support decision making and to open up new economic opportunies
in the marine and marime sectors of Europe for the benefit of European cizens
and the global community, it was agreed at the annual EuroGOOS meeng in 2010
that it is essenal to meet the following needs (AtlantOS, 2016):

  * Provide easy access to data through standard generic tools; where “easy” means the direct use of data without concerns on data quality and processing and that adequate metadata are available to describe how the data were processed by the data provider. 

  

  * Combine in situ-observaon data with other informaon (e.g., satellite images or model outputs) to derive new products, build new services or enable beter-informed decision-making. 

  

The ocean data management and exchange process within EuroGOOS intends to
reduce the duplicaon of efforts among agencies as well as to improve the
quality and reduce the costs related to the geospaal informaon, thus making
oceanographic data more accessible to the public and helping to establish key
partnerships to increase data availability. In addion, the EuroGOOS data
management system intends to deliver a system that will meet European needs,
in terms of standards while respecng the structures of the contribung
organizaons.

The structure will include:

  * Observaon data providers, which can be operaonal agencies, marine research centres, universies, naonal oceanographic data centres and satellite data centres. 

  

  * Integrators of marine data, such as the Copernicus in-situ data themac centre (for access to near real-me data acquired by connuous, automac and permanent observaon networks) or the SeaDataNet infrastructure (for quality controlled, long-term me series acquired by all ocean observaon iniaves, missions, or experiments), ICES and EurOBIS for biodiversity observaons, and the new European Marine Observaon and Data Network (EMODnet) portals. The integrators that will support both data providers, willing to share their observaon data, and users requesng access to oceanographic data (historic, real-me and forecasts). Integrators develop new services to facilitate data access and increase the use of both exisng and new observaonal data. 

  

  * Links with internaonal and cross-disciplinary iniaves, such as GEOSS (Global Earth Observaon System of Systems), both for technical soluons to improve harmonizaon in an interdisciplinary global context. 

  

###  3.1. Towards an integrated EU data system

ODYSSEA aims to contribute to improving data availability for end-users and
stakeholders across the Mediterranean basin, addressing both the open sea and
the coastal zone. One goal is to ensure that data from different and diverse
in-situ observing networks and forecasng models are readily accessible and
useable. **To achieve this, the strategy is to move towards an integrated data
system that harmonizes work flows, processes data according to exisng
standards and disseminates data produced by the insitu observing and modelling
network system, while integrang in-situ observaons into exisng European and
internaonal data infrastructures** (the so called “Integrators”). Such
Integrators include: the Copernicus INS TAC, SeaDataNet NODCs, EMODnet,
EurOBIS, and GEOSS.

The targeted integrated system deals with data management challenges that must
be met to provide efficient and reliable data service to users. These include:

  * Common quality control for heterogeneous and near real me data; 

  

  * Standardizaon of mandatory metadata for efficient data exchange; 

  

  * Interoperability of Network and Integrator data management systems. 

  

###  3.2. Industry requirements

Presently, there is a need to change the way marine observatories and public
data-sharing iniaves engage with industry and users. The  _Columbus_ _project_
(funded by the EU under H2020 which ended this year) proposes a set of
recommendaons designed to overcome some of the most important gaps and
barriers sll faced by private data users. Taken together, they represent the
basic components of a strategy to open significant opportunies for the marime
industry to both benefit from and engage with public marine data iniaves. This
can ensure the opmum return of public investments in the marine data sector,
notably in support of meeng key EU policy goals under the Blue Growth
Strategy, the Marine Strategy Framework Direcve and the Marime Spaal Planning
Direcve. Some barriers require further analysis and discussion, but there are
already many acons that can be undertaken to improve the situaon on the short
and medium term (Columbus, 2017):

  * Industry representaves should be included in the governance and take part in the enre cycle of decision making, development and operaon of marine observaon and data-sharing iniaves. 

  

  * There is a need for marine data-sharing iniaves to take a more pro-acve approach and move out of the comfort zone of the tradional oceanographic marine monitoring and observing communies. This involves, among others, developing a more “service-oriented approach”, learning new communicaon skills and language, being present and more visible in fora that atract industry and to exploit creave technologies. 

  

  * Data, products and services offered by marine observaon and data iniaves should be presented in a user-friendly, atracve and intuive way which is adapted to the target users. If users from different communies or sectors are targeted, opons to adjust the interface depending on the visitor should be considered. 

  

  * Clear, succinct and open communicaon is crical: it should be instantly clear for industry what data, products and services are offered and what may be made available in the future. Equally important is to provide informaon on what is not available, and the limitaons of the resources offered. 

  

  * More efforts should be made to build upon early achievements and successes: presenng use case examples that can trigger interest where there may previously have been none. 

  

  * There is a significant role for marime clusters in connecng marine data iniaves with industry and vice versa. Marime clusters are an important bridge between private and public sector as they deal with both and have a good understanding of their culture, language, needs and concerns. 

  

  * At European level there is a need for defragmentaon of the plethora of marine observaon and data and informaon sharing iniaves, as well as the online data portals. In the longer term, there is a need for a joint roadmap, agreed by the responsible coordinang and funding bodies including at the European Commission level, to set out the strategic framework. 

  

  * Dedicated data-sharing policies to incenvise the private sector and address their specific needs should be developed. Ways forward could include: stang clearly the added-value or benefits of sharing data, moratorium on commercially sensive data, provision of services in return for data which could support in-house data management, the development of a data-sharing ‘green label’ in recognion of corporate social responsibility. It is clear that implementaon of the recommendaons will require increased commitment and investment of me and resources, both from industry and from marine observaon and data iniaves, but should provide both with significant returns over me 

  

###  3.3. The ODYSSEA approach

The procedures to follow in ODYSSEA regarding this issue of the data
management will preferenally follow the examples from CMEMS, EMODNet or
SeaDataNet. In pracce two major data types will be addressed: the gridded data
produced by ODYSSEA models and the me-series data reported by the ODYSSEA stac
systems. Similarly, for the spao-temporal data produced via sensors integrated
into the ODYSSEA gliders, the SeaDataNet netCDF data standards for profiling
along trajectories will be adopted.

The gridded data may address dynamic data sets (similar to CMEMS) or stac data
sets (similar to

EMODnet). In both cases the procedures to follow will be similar to the ones
adopted by these two services.

Regarding the me series data, SeaDataNet procedures will represent the main
guidelines and netCDF-CF format will be the standard to be adopted. However,
**ODYSSEA will go one step forward and will use these netCDF files to feed an
SOS service, supported by North 52 soware to assure the interface with the
users.**

##  4\. Data quality control

The issue of data quality control will be addressed following the state-of-
the-art recommendaons of different projects such as SeaDataNet or AtlantOS.
SeaDataNet produced a comprehensive document presenng a set of guidelines to
be followed in marine data quality control. According to this document, quoted
below, data quality control essenally and simply has the following objecve: “
_To ensure the data consistency within a single data set and within a
collection of data sets and to ensure that the quality and errors of the data
are apparent to the user who has sufficient information to assess its
suitability for a task_ ”. If done well, quality control brings about several
key advantages (SeaDataNet, 2010):

  * _**Maintaining Common Standards** : There is a minimum level to which all oceanographic data should be quality controlled. There is little point banking data just because they have been collected; the data must be qualified by additional information concerning methods of measurement and subsequent data processing to be of use to potential users. Standards need to be imposed on the quality and long-term value of the data that are accepted (Rickards, 1989). If there are guidelines available to this end, the end result is that data are at least maintained to this degree, keeping common standards to a higher level. _

  

  * _**Acquiring Consistency** : Data within data centres should be as consistent to each other as possible. This makes the data more accessible to the external user. Searches for data sets are more successful as users are able to identify the specific data they require quickly, even if the origins of the data are very different on a national or even international level. _

  

  * _**Ensuring Reliability** : Data centres, like other organisations, build reputations based on the quality of the services they provide. To serve a purpose to the research community and others their data must be reliable, and this can be better achieved if the data have been quality controlled to a ‘universal’ standard. Many national and international programmes or projects carry out investigations across a broad field of marine science which require complex information on the marine environment. Many large-scale projects are also carried out under commercial control such as those involved with oil and gas and fishing industries. Significant decisions are made, and theories formed, on the assumption that data are reliable and compatible, even when they come from many different sources. _

  

ODYSSEA services data flux will be managed automacally by the ODYSSEA plaorm.
The data quality control will start by the execuon of automac procedures
(independently of the adopon of more complex procedures). The data quality
control methodology will focus on in situ observaons and modelled forecasts
and it will be addressed from two perspecves: the data **Quality Assurance**
and the **Quality Control** .

Quality Assurance (QA) is a set of review and audit procedures implemented by
personnel or an organizaon (ideally) not involved with normal project acvies
to monitor and evaluate the project to maximize the probability that minimum
standards of quality are being atained. With regard to data, QA is a system to
assure that the data generated is of known quality and well-described data
producon procedures are being followed. This assurance relies heavily on the
documentaon of processes, procedures, capabilies, and monitoring. Reviews
verify that data quality objecves are being met within the given constraints.
QA is inherently a human-in-the-loop effort and substanal documentaon must
accompany any QA acon. QA procedures may result in correcons to data. Such
correcons shall occur only upon authorized human intervenon (e.g., marine
operator, product scienst, quality analyst, principal invesgator) and the
correcons may either be applied in bulk (i.e., all data from an instrument
during a deployment period) or to selecve data points. The applicaon of QA
correcons will automacally result in the reflagging of data as ‘corrected’.

Quality Control (QC) is a process of roune technical operaons, to measure,
annotate (i.e., flag) and control the quality of the data being produced.
These operaons may include spike checks, out-of-range checks, missing data
checks, as well as others. QC is designed to:

  * Provide roune and consistent checks to ensure data integrity, correctness, and completeness; 

  

  * Idenfy and address possible errors and omissions; 

  

  * Document all QC acvies. 

  

QC operaons include automated checks on data acquision and calculaons by the
use of approved standardized procedures. Higher-er QC acvies can include
addional technical review and correcon of the data by human inspecon. QC
procedures are important for:

  * Detecng missing mandatory informaon; 

  

  * Detecng errors made during the transfer or reformang; 

  

  * Detecng duplicates; 

  

  * Detecng remaining outliers (spikes, out of scale data, vercal instabilies, etc); 

  

  * Ataching a quality flag to each numerical value to indicate the corrected observed data points. 

  

A guideline of recommended QC procedures has been compiled by the SeaDataNet
project aer reviewing

NODC schemes and other known schemes (e.g. WGMDM guidelines, World Ocean
Database, GTSPP, Argo, WOCE, QARTOD, ESEAS, SIMORC, etc.). The guideline at
present follows the QC methods proposed by

SeaDataNet for CTD (temperature and salinity profiles), current meter data
(including ADCP), wave data and sea level data. SeaDataNet is also developing
efforts for extending the guideline with QC methods for surface underway data,
nutrients, geophysical data and biological data.

ANNEX I provides a detailed descripon of the implementaon process procedure to
be followed for QA/QC in ODYSSEA.

###  4.1. Quality Control Flags

According to EuroGOOS (2016), an extensive use of flags to indicate the data
quality is recommended, since the end user will select data based on quality
control flags, amongst other criteria. These flags should always be included
in any data transfer (e.g., from ODYSSEA Observatories to the central ODYSSEA
plaorm) maintaining standards and ensuring data consistency and reliability (
_see Table 1_ ). The same flag scale is also recommended by SeaDataNet.

**TABLE 1: QUALITY FLAG SCALE (REPRODUCED FROM EUROGOOS, 2016).**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Definion**

</th> </tr>  
<tr>  
<td>

0

</td>  
<td>

No QC was performed

</td> </tr>  
<tr>  
<td>

1

</td>  
<td>

Good data

</td> </tr>  
<tr>  
<td>

2

</td>  
<td>

Probably good data

</td> </tr>  
<tr>  
<td>

3

</td>  
<td>

Bad data that are potenally correctable

</td> </tr>  
<tr>  
<td>

4

</td>  
<td>

Bad data

</td> </tr>  
<tr>  
<td>

5

</td>  
<td>

Value changed

</td> </tr>  
<tr>  
<td>

6

</td>  
<td>

Bellow detecon limit

</td> </tr>  
<tr>  
<td>

7

</td>  
<td>

In excess of quoted value

</td> </tr>  
<tr>  
<td>

8

</td>  
<td>

Interpolated value

</td> </tr>  
<tr>  
<td>

9

</td>  
<td>

Missing value

</td> </tr>  
<tr>  
<td>

A

</td>  
<td>

Incomplete informaon

</td> </tr> </table>

  * Data with QC flag = 0 should not be used without a quality control made by the user. 

  

  * Data with QC flag different from 1 on either posion or date should not be used without addional control from the user. 

  

  * If date and posion QC flag = 1 only measurements with QC flag = 1 can be used safely without further analyses 

  

  * if QC flag = 4 then the measurements should be rejected 

  

  * if QC flag = 2 the data may be good for some applicaons, but the user should verify this 

  

  * if QC flag = 3 the data are not usable, but the data centre may be able to correct them in a delayed mode 

  

###  4.2. In-situ observaons quality control

The quality control of observaons can be done in two phases. During the
download of in-situ observaons automac checks should be done such as those
proposed by SeaDataNet (2010) (e.g. global range test, date and me). Aer
quality control, only the valid data is stored in the database. In the second
phase, a tool may be run periodically to perform a scienfic quality control
check (SeaDataNet, 2010). This quality control aims to detect spikes, filter
high frequency noise (e.g. moving average or P50), data with abnormal
variability in me, etc. Specific tools will be running automacally for this
purpose.

###  4.3. Forecasts quality control

The quality control of modelled forecasts can be done by comparing me-series
forecasts with in-situ observaons (e.g., wave buoys, dal gauge, weather
staons, etc.) through automacally-run algorithms.

Similarly, gridded data forecasts may be compared automacally with observaons
(e.g., CMEMS gridded data observaons). As a result, several stascal parameters
may be computed (e.g., correlaon coefficient, bias, RMSE, skill, etc.) to
assess the quality of forecasts.

**QA/QC procedures will be followed as the data from local Observatory PCs
reach the central ODYSSEA plaorm. An extensive analysis of ODYSSEA QA/QC
procedures is provided in Secon 7.3 “Quality Control and Data Processing
Funconality” of Deliverable 2.3.**

##  5\. Data integraon and fusion

###  5.1. Low level data integraon and fusion

Adopng the best strategies for merging datasets obtained from different data
sources, in order to build the best available datasets or fuse different data
sources to produce aggregated data, indices and products, is not simple. A
possible soluon when we have different soluons with different resoluons for
the same area is to fuse these data and offer a unique integrated dataset.
Another opon is to provide all datasets separately with an opon of an
integrated soluon. No mater which soluon is adopted, the final objecve of the
data integraon and fusion is to contribute to improvement of data accuracy and
robustness of models’ inial and boundary condions as well as to provide users
with comprehensive data that merge different data sets based on reliable
criteria.

For example, if a user is interested in operaonal wave data for a specific
site and realizes that for the period of interest, there exist different me
series from different wave buoys, he may be interested in geng a unique me
series by merging different me series data and making them compable. This
process may require complex acons regarding the levels of accuracy of the
different measuring devices, the measuring me rate and units, etc.

###  5.2. Semanc Informaon Integraon and Fusion

Capacity for integraon and fusion of semanc informaon will be provided through
the ODYSSEA plaorm. Semanc informaon is composed of several pieces of
informaon, potenally coming from different semancally rich informaon sources.
The main use of this capacity is for semanc network enrichment and query.

The informaon processed is expressed through graphs of enes related with each
other and contains semanc metadata. The fusion is adapted to the domain of
applicaon. This applicaon domain is described through an ontology of the
domain. The fusion process is also adapted to the quality of the informaon
items, through the use of fusion heuriscs.

The fusion heuriscs integrate domain knowledge and user preferences. They are
the intelligent part of the semanc fusion system. They are end-user defined
funcons used to express the confidence the users have in the informaon
sources, as well as specific strategies that must be followed in order to fuse
informaon coming from different sources.

The two main semanc informaon integraon funconalies are:

  * Inseron of new informaon into a semanc informaon network (Synthesis), 

  

  * Query for informaon in a semanc informaon network (Mining). 

  

5.2.1. Informaon sources

Many valuable open informaon sources can be used and integrated in order to
provide a large and always up to date overview of the ongoing situaon in
specific zones. For instance, we will use informaon provided by the Wikipedia
1  encyclopaedia, the Wikidata  2  informaon base and social networks such as
Twiter. For scienfic data sets, bases such as the EMODnet plaorm can be used
to provide data on main ports acvies, quality of bathing waters … etc.

####  Wikipedia pages

Wikipedia encyclopaedia is a wide collaborave and constantly up-to-date source
of informaon.

Integrang informaon provided by the Wikipedia community enables providing end-
users with a very rich semanc source of informaon. Regarding domains such as
tourism, locaons and marine species, the informaon available on Wikipedia is
parcularly abundant.

####  Wikidata elements

Wikidata is another valuable source of semanc informaon. Contrary to the
informaon stored on

Wikipedia, Wikidata is a knowledge base thus the semanc aspect of informaon is
contained in the informaon source. Concepts and instances are defined in
Wikidata. Semanc relaons among these objects are specified. Therefore,
Wikidata is an open source of informaon of valuable importance.

####  EMODnet Human Acvies

Among providers, EMODnet provides several data portal for marine data. Some of
the portals, such as the

Human Acvies portal, provide informaon with a rich semancs and a high level of
interpretaon. This source may be of great interest in order to be integrated
with other sources of informaon, providing different perspecves on the marine
situaon of the different zones of interest.

####  Twiter

Social media provides a wealth of crowd sourced data on easily observable
physical phenomenon in sengs which lack tradional methods of monitoring and
can even prove to be more rapid and flexible. However, the challenge lies in
mining aconable data from the millions of tweets posted every hour. Hence a
collecon/filtering algorithm will be writen in order to collect tweets which
are contextually and geographically pernent.

The twiter API may be used to retrieve raw data that for further manipulaon
and processing in order to get useful informaon. The raw data supplied by a
Twiter API call consists of JSON objects, which contain a large number of
categories of informaon (an atribute followed by human readable text).

5.2.2. Need for informaon quality enhancement algorithms

If most of the encyclopaedic sources of informaon are reliable and complete,
social media informaon has a very low level quality. However, using social
media is of importance if we want to involve cizens in the monitoring and
protecon of our environment. For example, in ODYSSEA we are building the so-
called “models chain”, where each model is run in a predetermined order and
the data produced by one model are used as boundary condions for the next. In
this chain, several uncertaines may occur, for example the iniaon of the oil
spill model when an oil spill accident occurs. **Through the ODYSSEA semanc
informaon analysis, and more specifically through algorithms searching and
harvesng the Twiter for relevant informaon, a more instant response to a
disastrous event might occur.** Thus, the Oil Spill Model could be iniated at
the exact locaon as early as possible to the event of oil release to the
marine environment. Similar applicaons might include extreme events on
meteorologic/hydrgraphic condions (e.g., storms), eutrophicaon/bloom
incidents, jelly-fish outburst, etc.

One of the issues of using Twiter for instance, is that due to the increasing
digital data privacy restricons the twiter users have to acvely consent to
provide their exact geolocaon when posng their tweets. Otherwise the alternave
is using the self-reported locaon of the profile associated with a given
tweet, but this is usually very generalized (e.g. Europe), and hence unfit for
this purpose. Hence, the only reliable opon for gleaning geographic informaon
of the tweet is by using keywords within the body of the tweet (e.g. @laplaya,
#Madrid, etc.).

To overcome this limitaon and be able to use cizen informaon provided through
Twiter, it is necessary to deeply analyse the meanings (semancs) of the texts
in order to understand it. Regarding locaons, for instance, it is required to
make use of a Named Enty Extracon engine in order to extract the locaon of the
events reported in the tweets, rather than the locaon of the phones that were
used to tweet.

Furthermore, authors of tweets have very different levels of reliability
regarding specific issues. Average cizens won’t know the species of a specific
jellyfish that that see on a beach for instance. They may not be able to
report properly and with all characteriscs, an oil spill they witness. More
serious issues may be encountered with authors that spread rumours or even
create false informaon. A possible acon to overcome such limitaons is to build
lists of referenced Twiter accounts regarding each use case, based on the
accounts that the ODYSSEA end-users trust. For instance, marime governmental
organisaon accounts will be followed and analysed.

##  6\. Data management

###  6.1. Providers code for data

Following the procedures adopted by AtlantOS, the Instuons providing data to
ODYSSEA plaorm should be reported and acknowledged following the EDMO code
recorded in the data file and the ODYSSEA plaorm catalogue. EDMO is the
European Directory of Marine Organizaons, developed under SeaDataNet, and it
can be used to register any marine organizaon involved in the collecon of
datasets

(operators, funders, data holders, etc.). It delivers a code for the
organizaon to be included in the data or metadata leading to the harmonizaon
of informaon (compared to free text) and the opmizaon of the datasets
discovery. EDMO is coordinated by MARIS.

For EU Countries new entries are added by the Naonal Data Centres (NODCs).
Through ODIP (Ocean Data

Interoperability Plaorm) cooperaon, there is also a point of contact with the
USA, Australia and some other non-EU countries. The rest of the world is
managed by MARIS, which also moderates the first entrance in EDMO of new
entries.

The request for a new entry in EDMO is sent to MARIS (current contact: Peter
Thijsse, peter@maris.nl), who verifies if the instuon is already registered.
If a new entry is needed, the basic entry is made by MARIS, aer which the
appropriate NODC is responsible for updang further details and managing
changes.

###  6.2. Data vocabulary

Use of common vocabularies in all meta-databases and data formats is an
important prerequisite towards consistency and interoperability with exisng
Earth Observing systems and networks. Common vocabularies consist of lists of
standardised Terms of Reference covering a broad spectrum of disciplines of
relevance to the oceanographic and wider community. Using standardised ToR the
problem of ambiguies related to data structure, organizaon and format is
solved and therefore, common algorithms for data processing may be applied.
This allows the interoperability of datasets in terms of their manipulaon,
distribuon and long-term reuse.

ODYSSEA will adopt an Essenal Variables list of terms (aggregated level) that
has been defined and was published in June 2016 on the NERC/BODC Vocabulary
Server  3  .

This new vocabulary is mapped to the standards recommended for ODYSSEA
parameter metadata: P01

(parameter), P07 (CF variable), P06 (units) from SeaDataNet controlled
vocabularies managed by

NERC/BODC and the internaonally assured AphiaID from the WOrld Register of
Marine Species (WoRMS)  4  .

###  6.3. Metadata

Metadata refers to the descripon of datasets and services in a compliant form
as it has been defined by the Direcve 2007/2/EC (INSPIRE) and Commission
Regulaon No 1205/2008.

Metadata is the **data about the data** . Metadata describes how, when and by
whom a parcular set of data or a service was collected or prepared, and how
the data is formated, or the service is available. Metadata is essenal for
understanding the informaon stored in and has become increasingly important.

Metadata is structured informaon that describes, explains, locates, or
otherwise makes it easier to retrieve, use, or manage an informaon resource.
Metadata is oen called as the “data about the data or informaon about
informaon”.

Metadata is also data about services. Metadata describes the content, quality,
condion, and other characteriscs of a data set or the capabilies of a service.
Creang metadata or data documentaon for geospaal datasets is crucial to the
data development process. Metadata is a valuable part of a dataset and can be
used to:

  * **Organize** data holdings (Do you know what you have?). 

  

  * Provide **informaon about** data holdings (Can you describe to someone else what you have?). 

  

  * Provide informaon **to data users** (Can they figure out if your data are useful to them?). 

  

  * **Maintain the value** of your data (Can they figure out if your data are useful 20 years from now?). 

  

In the geographical domain we can have a descripon of spaal data ( **spaal
data** metadata), a service

( **service** metadata) or a special analysis process ( **process** metadata).
Most for the standardizaon work is done for data metadata, however service and
process metadata become increasingly important. Metadata is used in discovery
mechanisms to bring spaal informaon providers and users together.

The following mechanisms are recognized:

  * **Discovery** : which data source contains the informaon that I am looking for? 

  

  * **Exploraon (or evaluaon)** : do I find within the data sources the right informaon to suit my informaon needs? 

  

  * **Exploitaon (use and access)** : how can I obtain and use the data sources? 

  

Each mechanism has its own use of metadata. The selected standards should
fulfil the needs to carry out services using these mechanisms. Metadata is
required to provide informaon about an organisaon’s data holdings. Data
resources are a major naonal asset, and informaon of what datasets exist
within different organisaons, parcularly in the public sector, is required to
improve efficiencies and reduce data duplicaon. Data catalogues and data
discovery services enable potenal users to find, evaluate and use that data,
thereby increasing its value. This is also becoming important at the European
level. In addion, metadata received from an external source may require
further informaon supplied to metadata to allow easy process and interpretaon.

In this context for all types of data the following informaon is required
(SeaDataNet, 2010):

  * **Where** the data were collected: locaon (preferably as latude and longitude) and depth/height; 

  

  * **When** the data were collected (date and me in UTC or clearly specified local me zone); 

  

  * **How** the data were collected (e.g., sampling methods, instrument types, analycal techniques). How do we organize the data (e.g., in terms of staon numbers, cast numbers); 

  

  * **Who** collected the data, including name and instuon of the data originator(s) and the principal invesgator; 

  

  * **What** has been done to the data (e.g., details of processing and calibraons applied, algorithms used to compute derived parameters); 

  

  * **Watch** points for other users of the data (e.g., problems encountered and comments on data quality). 

  

The ICES Working Group on Data and Informaon Management (WGDIM) has developed
a number of data type guidelines which itemize these elements that are
required for thirteen different data types (see table below). These Data Type
Guidelines have been developed using the experse of the oceanographic data
centres of ICES Member Countries. They have been designed to describe the
elements of data and metadata considered as important to the ocean research
community. These guidelines are targeted towards most physical-chemical-
biological data types collected on oceanographic research vessel cruises.

Each guideline addresses the data and metadata requirements of a specific data
type.

This covers three main areas:

  * What the data collector should provide to the data centre (e.g., collecon informaon, processing, etc.); 

  

  * How the data centre handles data supplied (e.g., value added, quality control, etc.); 

  

  * What the data centre can provide in terms of data, referral services and experse back to the data collector. A selecon of these guidelines, in parcular for those data types that are not yet dealt with in detail here, are included in Appendix 1 of this document. 

  

This document summarizes the concept of metadata that is intended to be
adopted by ODYSSEA data plaorm, following the commonly agreed INSPIRE data
specificaon template in its relevant parts, i.e., dataset-level, services
metadata and data quality. It also contains detailed technical documentaon on
the XML source-code level and therefore provides specific guidelines to
correctly create and maintain metadata in the XML format.

###  6.4. Metadata Catalogue Service

A **Metadata Catalogue Service** is a mechanism for storing and accessing
descripve metadata and allows users to query for data items based on desired
atributes. The catalogue service stores descripve informaon (metadata) about
logical data items. The Open Geospaal Consorum (OGC) has created the
**Catalogue Service for Web (CSW) standard** to enable the easy data discovery
from a catalogue node.

Catalogue services support the ability to publish and search metadata for
data, services, and related informaon. Metadata in catalogues can be queried
and presented for evaluaon and further processing by both humans and soware.
Catalogue services (and other resources such as bibliographic resources,
datasets, etc.) are required to support the discovery and binding to published
web map services. The CSW standard is extremely rich. In addion to supporng a
query from a user, it can support distributed queries (one query that searches
many catalogues) and the harvesng of metadata from node to node.

Catalogue services support the ability to publish and search collecons of
descripve informaon

(metadata) for data, services, and related informaon objects. Metadata in
catalogues represent resource characteriscs that can be queried and presented
for evaluaon and further processing by both humans and soware. Catalogue
services are required to support the discovery and binding to registered
informaon resources within an informaon community.

The  Internaonal Organisaon for Standardisaon (ISO)  includes  ISO/TC 2112,
which is an internaonal, technical Commitee for the standardisaon of
geographical informaon. TC 211 has created a strong, globally implemented set
of standards for geospaal metadata: the baseline  ISO 19115;  ISO 19139  for
implementaon of data metadata and the  ISO 19119  for services metadata.

These open standards define the structure and content of metadata records and
are essenal for any catalogue implementaon.  ISO 19115  describes all aspects
of geospaal metadata and provides a comprehensive set of metadata elements. It
is designed for electronic metadata services, and the elements are designed to
be searchable wherever possible. It is widely used as the basis for geospaal
metadata services. However, because of the large number of metadata elements
and the complexity of their data model, implementaon of ISO 19115 is
difficult.

The  INSPIRE DIRECTIVE  applies these standards and specificaons in its
implementaon. INSPIRE makes use of three catalogues for unique IDs management:
**(1) SeaDataNet, (2) ICES and (3) CMEMS.** ICES catalogue has a geospaal
component not present in the SeaDataNet catalogue while CMEMS provides the
reference to model results.

6.4.1. Catalogue Service for Web (CSW)

This secon describes briefly the Open GIS Consorum (OGC) specificaon for
catalogue services.

According to this specificaon: “ _Catalogue services support the ability to
publish and search collections of descriptive information (metadata) for data,
services, and related information objects; Metadata in catalogues represent
resource characteristics that can be queried and presented for evaluation and
further processing by both humans and software. Catalogue services are
required to support the discovery and binding to registered information
resources within an information community_ ".

**FIGURE 6.1: GENERIC VIEW OF THE CSW PROTOCOL AND ARCHITECTURE**

The Inspire iniave uses the CSW protocol and the ISO metadata applicaon
profile (AP) for the specificaon and implementaon of the Inspire Discovery
Service. In ODYSSEA, the ODYSSEA ISO metadata profile will be developed and
used as described in the metadata secons of this document.

6.4.2. Harvesng

Harvesng is the procedure of collecng metadata records from other (external)
catalogues and synchronize the local catalogue with the collected informaon.

In the majority of the cases the harvesng process is scheduled and automacally
executed once or at pre-defined intervals. It is usually also possible to
execute a harvesng procedure on-demand, i.e., executed by human request.

The diagram below depicts a sample on how the harvesng procedures could be
seen between the

ODYSSEA plaorm catalogue and other external catalogues. To be noted that the
harvesng procedure uses, within Inspire, the CSW protocol. Within the
catalogue responses to the harvesng requests there are collecons of metadata
records, using the model described in this document (i.e., INSPIRE Datasets
and Services).

**FIGURE 6.2: SAMPLE HARVESTING PROCEDURES BETWEEN ODYSSEA PLATFORM CATALOGUE
AND EXTERNAL CATALOGUES.**

###  6.5. Guidelines on using metadata elements

6.5.1. Lineage

Following the ISO 19113 Quality principles, if a data provider has a procedure
for quality validaon of their spaal datasets then the data quality elements,
listed in Chapter 2, should be used. If not, the Lineage metadata element
(defined in Regulaon 1205/2008/EC) should be used to describe the overall
quality of a spaal dataset.

According to Regulaon 1205/2008/EC, lineage “is a statement on process history
and/or overall quality of the spaal dataset. Where appropriate it may include
a statement whether the dataset has been validated or quality assured, whether
it is the official version (if mulple versions exist), and whether it has
legal validity. The value domain of this metadata element is free text”.

Apart from describing the process history, if feasible within a free text, the
overall quality of the dataset

(series) should be included in the Lineage metadata element. This statement
should contain any quality informaon required for interoperability and/or
valuable for use and evaluaon of the dataset (series).

6.5.2. Temporal reference

According to Regulaon 1205/2008/EC, at least one of the following temporal
reference metadata elements shall be provided: temporal extent, date of
publicaon, date of last revision, date of creaon. If feasible, the date of the
latest revision of a spaal dataset should be reported using the date of latest
revision in a metadata element.

6.5.3. Topic category

The topic categories defined in Part D.2 of the INSPIRE Implemenng Rules for
metadata are derived directly from the topic categories defined in B.5.27 of
ISO 19115. Regulaon 1205/2008/EC defines the INSPIRE data themes to which each
topic category is applicable, i.e., oceanography is the INSPIRE theme for
which the Geoscienfic informaon topic category is applicable.

6.5.4. Keyword

Regulaon 1205/2008/EC requires that, for a spaal dataset or a spaal dataset
series, “at least one keyword shall be provided from the General Environmental
Mul-lingual Thesaurus (GEMET) describing the relevant spaal data theme, as
defined in Annex I, II or III to Direcve 2007/2/EC”. Keywords should be taken
from the GEMET – General Mullingual Environmental Thesaurus where possible.

##  7\. ODYSSEA datasets

This secon describes the structure and the content of the proposed ODYSSEA
metadata profile on the dataset-level and includes general guidelines for the
metadata from two points of view – the first one is the ODYSSEA metadata,
while the second represents ODYSSEA data quality issues.

The structure described in this document is compliant with the exisng ISO
standards for metadata – i.e., especially ISO EN 19115 and ISO 19139\. The
full list of used ISO standards can be found in the List of References at the
end of this document. The primary goal of this part of the deliverable is to
develop a metadata profile for ODYSSEA geographic datasets and me-series
datasets, within the framework of these ISO standards, aiding the support of
the interoperability between the different metadata and/or GIS plaorms.

The metadata model to be adopted in ODYSSEA is described in more detail in
Annex I.

###  7.1. Dataset-level metadata

Metadata can be reported for each individual spaal object (spaal object-level
metadata) or once for a complete dataset or dataset series (dataset-level
metadata). If data quality elements are used at spaal object level, the
documentaon shall refer to the appropriate definion in the Data Quality Info
secon of this document. This secon only specifies the dataset-level metadata
elements.

For some dataset-level metadata elements, in parcular on data quality and
maintenance, a more specific scope can be specified. This allows the definion
of metadata at sub-dataset level, e.g., separately for each spaal object type.
When using ISO 19115/19139 to encode the metadata, the following rules should
be followed:

  * The scope element (of type DQ_Scope) of the DQ_DataQuality subtype should be used to encode the scope. 

  

  * Only the following values should be used for the level element of DQ_Scope: series, dataset, featureType. 

  

  * If the level is featureType  5  then the levelDescripon/MD_ScopeDescripon/features element (of type Set <GF_FeatureType>) shall be used to list the feature type names. 

  

  * Mandatory or condional metadata elements are specified in the next sub-secon, while oponal metadata elements are specified in subsequent sub-Secon. The tables describing the metadata elements contain the following informaon: 

  

  * The first column provides a reference to a more detailed descripon. The second column specifies the name of the metadata element. 

  

  * The third column specifies the mulplicity. 

  

  * The fourth column specifies the condion, under which the given element becomes mandatory (only for the first and second tables). 

  

In **Annex I** a detailed descripon of the metadata is presented.

###  7.2. Service-level metadata

This secon describes the structure and the content of the proposed ODYSSEA
metadata profile on the service-level and includes general guidelines for
ODYSSEA metadata from two points of view – the first one is the ODYSSEA-
specific metadata, while the second represents quality issues of the data
published by the services.

The structure described in this document is compliant with the exisng ISO
standards for metadata – i.e., especially ISO EN 19115, EN ISO 19119 and ISO
19139 (the full list of used ISO standards can be found in List of References
at the end of this document). The primary goal of this secon is to explain the
development in the metadata profile of ODYSSEA geographical data services,
within the framework of these ISO standards. Through this process, the
principle of interoperability is supported and data are easily harvested and
exchanged between various discovery services and different metadata and/or GIS
plaorms.

Metadata can be reported for each individual spaal object (spaal object-level
metadata) or once for a complete dataset or dataset series (dataset-level
metadata). On the other hand, metadata can also be reported for the services
that are publishing ODYSSEA data – i.e., especially INSPIRE view and download
services. This secon only specifies service-level metadata elements.

For some service-level metadata elements, in parcular for data quality, a more
specific scope can be specified. This allows the definion of metadata at sub-
dataset level, e.g., separately for each spaal object type. When using ISO
19115/19139 to encode the metadata, the following rules should be followed:

  * The scope element (of type DQ_Scope) of the DQ_DataQuality subtype should be used to encode the scope. 

  

  * Only the following value should be used for the level element of DQ_Scope: service. 

  

Mandatory or condional metadata elements are specified in the ANNEX I. Oponal
metadata elements are specified in the subsequent sub-secon of this ANNEX.

###  7.3. Data format standards

7.3.1. Ocean Data View data model and netCDF Format

As part of the ODYSSEA services, data sets will be accessible via download
services. Delivery of data to users requires common data transfer formats,
which interact with other standards  (Vocabularies,  data  quality control).
In SeaDataNet it was decided that Ocean Data View (ODV) and netCDF format are
mandatory.

ODYSSEA will follow the SeaDataNet (2017) procedures, as main concepts of this
document are reproduced in the following paragraphs. ODYSSEA will also follow
the fundamental data model underlying ODV format which, in pracce, is composed
of a collecon of rows, each having the same fixed number of columns.

In this model there are three different types of columns:

  * The metadata columns; 

  

  * The primary variable data columns (one column for the value plus one for the qualifying flag); 

  

  * The data columns. 

  

The metadata columns are stored at the le-hand end of each row, followed by
the primary variable columns and then the data columns.

There are three different types of rows:

  * The comment rows; • The column header rows; 

  

  * The data rows. 

  

The CF metadata convenons (htp://cf-pcmdi.llnl.gov/) are designed to promote
the processing and sharing of data files created with the NetCDF API. The
convenons define metadata that provide a definive descripon of what the data
in each variable represents, and the spaal and temporal properes of the data.
This enables users of data from different sources to decide which quanes are
comparable, and facilitates building applicaons with powerful extracon, re-
gridding, and display capabilies.

The standard is both mature and well-supported by formal governance for its
further development. The standard is fully documented by a PDF manual
accessible from a link from the CF metadata homepage (htp://cf-
pcmdi.llnl.gov/). Note that CF is a developing standard and consequently
access via the homepage rather than through a direct URL to the document is
recommended to ensure that the latest version is obtained. The current version
of this document was prepared using version 1.6 of the convenons dated 5
December 2011.

The approach taken with the development of the SeaDataNet profile based on CF
1.6 was to classify data on the basis of feature types and produce a
SeaDataNet specificaon for storage of each of the following:

  * **Point me series** , such as current meter or sea level data, have row_groups made up of measurements from a given instrument at different mes. The metadata date and me are set to the me when the first measurement was made. The primary variable is me (UT) encoded either as: 

    * A real number represenng the Chronological Julian Date, which is defined as the me elapsed in days from 00:00 on January 1st 4713 BC. If this opon is chosen, then the column must have the heading ‘Chronological Julian Date [days]’. 

  

    * A string containing the UT date and me to sub-second precision corresponding to ISO8601 syntax (YYYY-MM-DDThh:mm:ss.sss) for example 2009-02-12T11:21:10.325. If 

  

  

this opon is chosen, the column must have the heading ‘me_ISO8601’. If the me
is not known to sub-second precision, then use the ISO8601 form appropriate to
the known precision. For example, a mestamp to the precision of one hour would
be represented by 2009-02-12T11:00 and a me stamp to a precision of a day by
2009-02-12.

Rows within the row_group are ordered by increasing me. Note that the z co-
ordinate (e.g., instrument depth), essenal for many types of me series data,
needs to be stored as a data variable and could have the same value throughout
the row_group.

  * **Profile data** , such as CTD or botle data, have row_groups made up of measurements at different depths. The metadata date and me are set to the me when the profile measurement started. The primary variable is the ‘z co-ordinate’, which for SeaDataNet is either depth in metres or pressure in decibars. Rows within the row_group are ordered by increasing depth. 

  

  * **Trajectories** , such as underway data, have row_groups made up of a single measurement, making the metadata me and posions the spao-temporal co-ordinate channels. The primary variable is the ‘z co-ordinate’, which for SeaDataNet is standardised as depth in metres. Rows within the row_group are ordered by increasing me; 

  

  * **TimeSeriesProfile** (x, y, z fixed; t variable) but some variables can be measured at different depths at the same me var=f(t, z). The specificaon given is for storage of me series profiles such as moored ADCP. 

  

  * **TrajectoryProfile** (x, y, z, t all variable) but some variables can be measured at different depths at the same me var=f(t, z). The specificaon given is for storage of trajectory profiles such as shipborne ADCP. 

  

The specificaon was then developed through discussions on a collaborave e-mail
list involving parcipants in SeaDataNet, MyOcean, USNODC, NCAR and AODN. The
working objecve focussed on producing profiles with the following properes:

  * CF 1.6 conformant; 

  

  * Have maximum interoperability with CF 1.6 implementaons in use by MyOcean (OceanSITES convenons), USNODC (USNODC NetCDF templates) and two contributors to AODN (IMOS and METOC); 

  

  * Include storage for all labels, metadata and standardised semanc mark-up that were included in the SeaDataNet ODV format files for the equivalent feature type. 

  

Significant list discussion focussed on the version of netCDF that should be
used for SeaDataNet. The conclusion was that netCDF 4 should be used wherever
possible, but that netCDF 3, although strongly discouraged, should not be
totally forbidden.

On ANNEX II some examples of the structure of these files are presented.

7.3.2. Stac data (Bathymetric, Chemical, Geologic, Geophysical, Biological,
Biodiversity data)

ODYSSEA will also adopt the SeaDataNet proposed standards for marine chemistry
(to support the EMODNet Chemistry pilot), bathymetry (to support the EMODNet
Hydrography and Seabed Mapping pilots), and geology and geophysics (to support
the Geo-Seas project and the EMODNet Geology pilot). and marine biology.

Based on an analysis of the present situaon, and currently exisng biological
data standards and iniaves, such as the Ocean Biogeographic Informaon System
(OBIS), Global Biodiversity Informaon Facility (GBIF), Working Group on
Biodiversity Standards (TDWG) and World Register of Marine Species (WoRMS)
standards, SeaDataNet proposed a format for data exchange of biological data.

Key issues that steered the format development were (SeaDataNet III,
publishable summary):

  * Requirements posed by the intended use and applicaon of the data format (data flows, density calculaons, biodiversity index calculaons, community analysis, etc…) 

  

  * Availability of suitable vocabularies (World Register of Marine Species, SeaDataNet Parameter list, SeaDataNet Unit list, etc…) 

  

  * Requirements for compability with exisng tools and soware (WoRMS taxon match services, EurOBIS QC services, Lifewatch workflows, Ocean Data View, etc…) 

  

  * The requirements of the extended ODV format for biological data were defined as follows: 

  

  * The format should be a general and higher level format without necessarily containing all specifics of each data type, but rather focusing on common informaon elements for marine biological data. 

  

  * At the same me the format needs to be sufficiently flexible/extendable to be applicable for at least part of the variety of biological data the NODC’s are managing. 

  

  * It should be possible to derive OBIS or Darwin Core compable datasets from the format. 

  

  * The format should be self-describing, in the sense that all informaon needed to interpret the data should be included in the file format or be available through links to vocabularies or term lists that are part of the format. 

  

A specific ODV extended format for biological data has been defined for
different types of files such as (see for details SeaDataNet deliverable
D8.4):

  * macrobenthos community with density and biomass values; 

  

  * zooplankton community with samples from different depths; 

  

  * demersal fish populaon with densies for different size classes and individual fish measurements; 

  

  * pollutant concentraons in biota specimens. 

  

7.3.3. Open source Semanc Informaon

Semanc informaon may be useful for a myriad of services to the end users.
However, the sources providing semancally rich informaon are very
heterogeneous. Semancally rich informaon can be found on Wikipedia and
Wikidata for instance. EMODnet, through the “Human acvies” data sets, also
provides some semancally rich informaon.

As one can see the sources of semancally rich informaon are very heterogeneous
in their availability, reliability and format. Furthermore, they provide
heterogeneous and parally redundant informaon. No standard model exists for
that type of informaon, as their variability is very high. However, as one of
ODYSSEA plaorm aim is to integrate and fuse this kind of informaon, one must
rely on a shared format in order to analyze and make use of it.

Within the services that will be developed in ODYSSEA, a domain ontology will
be used in order to enable the integraon of semanc informaon sources. **For
each ODYSSEA use case, and for each ODYSSEA product relying on semanc
informaon analysis and integraon, end users of the products will have to
develop, together with ODYSSEA technical partners, an ontology defining the
concepts of interest of the use case.** This ontology will be the pivot
language and representaon format used to integrate heterogeneous open
informaon sources.

**FIGURE 7.1: EXAMPLE OF AN ONTOLOGY DEFINING THE MAIN CONCEPTS USED TO
ANALYZE THE IMPACT OF PORT**

**STRUCTURES ON THE QUALITY OF BATHING WATERS AND FISH PRODUCTION**

##  8\. Data privacy policy

###  8.1. General principles

Basic principles regulated by the Data Protecon Act will be observed namely:

  * ODYSSEA will only hold the personal data which is necessary to offer services provided by its plaorm. 

  

  * Data is only used for the purposes described in the Data Protecon Register Form and the Informed Consent Form. 

  

  * Personal data will only be held for as long as necessary. Once data are no longer needed it will be deleted from ODYSSEA records by the ODYSSEA plaorm Administrator (namely the CLS Chief Technical Officer (CTO) / IT plaorm manager). More specifically, in case a certain period (one year) is passed without the entry of an end-user in the plaorm, CLS will alert him through a standardized electronic message on the destrucon of personal data. 

  

  * Personal data storage will be secured to ensure that data are not accessible to unwanted third pares and are protected against disaster and risk. 

  

  * ODYSSEA will regularly email website news and informaon updates only to those end-users and customers who have specifically subscribed to our email service. All subscripon emails sent by the ODYSSEA plaorm will contain clear informaon on how to unsubscribe from our email service. 

  

  * In any event, no personal data will be shared with any third party for direct markeng. ODYSSEA will never sell, rent or exchange mailing lists of personal data. 

  

  * All ODYSSEA partners shall comply with the data protecon and privacy laws applicable in their country of origin, including their naonal laws applicable to exporng data into the EU. 

  

  * ODYSSEA partners from non-EU countries have provided signed declaraons that they will meet all relevant H2020 ethical standards and regulaons. _Exporng personal data from the EU to non-_

  

_EU countries must comply with the applicable EU rules on cross-border
transfer of personal data._

  * In accordance with the Privacy and Electronic Communicaons (EC Direcve) Regulaons 2003, ODYSSEA will never send bulk unsolicited emails, (popularly known as Spam) to any email addresses. 

  

  * ODYSSEA may send emails to exisng end-users and customers or prospecve end-users and customers having inquired or registered in the ODYSSEA plaorm, regarding products or services directly provided by the ODYSSEA plaorm. 

  

  * All emails sent by ODYSSEA will be clearly marked as originang from this plaorm. All such emails will also include clear instrucons on how to unsubscribe from ODYSSEA email services. Such instrucons will either include a link to a page to unsubscribe or a valid email address to which the user should reply, with “unsubscribe” as the email subject heading. 

  

Details on the protecon of end-users’ personal data and the privacy rules to
be followed by ODYSSEA, the parcipaon of non-EU countries and the Informed
Consensus Procedures are provided in Deliverable

1.1.

###  8.2. Use of Cookies

Cookies are small text files which are placed on your computer by websites
that you visit. They are widely used in order to make websites work, or work
more efficiently, as well as to provide informaon to the owner of the site.

ODYSSEA plaorm may generate cookies in order to work more efficiently. These
will enhance features such as plaorm search and opmized page loading.

ODYSSEA may use Google Analycs to collect quantave informaon on plaorm’s
performance and end-user’s interacon with the plaorm. ODYSSEA will use this
informaon to improve the service and experience offered by the plaorm. The use
of Social Media butons on some of the pages link to third party websites and
services, like Facebook and Twiter also create cookies. These services use
cookies when clicking the buton. Privacy policies will be available for all
these services and users should be able to read them to be informed on how
their informaon is being used, and how they can opt-out, should they wish to.