**DOI data model:** the Application Profile Framework. DOI names (identifying
entities, i.e Microbiome entries per donor or immune data per donor) will be
grouped into application profiles (Work packages). Any single DOI name can be
a member of multiple application profiles. Each application profile will
similarly be associated with one or more services (CURE deliverables): each
service will be made available in multiple ways. This makes it possible to
make a new service applicable to many DOI names, simply by adding that service
to the relevant application profile(s).

Figure 1: Project and data generation flow chart.

**Responsibilities / costing:** Data management responsibilities among
partners will be allocated during the first General Assembly in September
2018. A Data Control Committee (DCC) will be established to take over the role
of data controller in the project. The DCC will be included in the new DMP
version, which will be updated regularly. The DCC will estimate the costs that
will be needed for the project’s data management and propose to the General
Assembly allocation of costs per partner. Costs for open access are eligible
under all H2020 projects.

A detailed dictionary of terms will be available with each dataset.

#  ⮚ Section 1: Organisation of data - common steps among partners

Within CURE, there is a broad range of experimental procedures from multiple
disciplines such as immunology, respiratory medicine, metagenomics,
bioinformatics, microbiology, virology, engineering, microbial ecology and
mathematics. However, a series of steps to standardise the handling of data
from discovery to publication has been designed and is presented in the
following section.

_Organization of data at each centre:_

_Laboratory-experimental data_ : All experiments will be described and logged
in hardcopy and/or electronic lab books. Electronic records will be in the
format of text files, word (.doc), Excel (.xlsx), csv (comma separated
variable) and rtf (rich text format) documents. Raw figure data will also be
saved in JPEG, TIFF or other high-resolution formats (>300 dpi). Raw data
extracted by various platforms such as real-time PCR cyclers, ELISA readers,
Luminex etc. will be saved in .txt or Excel files or appropriate formats. All
experimental protocols will be described in a clear and sufficiently detailed
manner such that protocols can be reproduced, and shared between lab or
consortium members, peer-reviewers upon request or external researchers
following publication. The protocol files will reside within the local servers
and exchanged as necessary. All unprocessed data will be saved in one folder
named **technical unprocessed data (TUD)** which can contain multiple other
sub-folders per user, per process and/or per experiment. Any-type of processed
data will be saved in one folder named **technical processed data (TPD)**
(Figure 2A).

_High throughput sequencing data_ : Raw data produced by any type sequencing
platform will be saved in a separate folder named **high throughput sequencing
unprocessed data (HTSUD)** . These files will contain the raw output (FASTQ or
FASTA) files after demultiplexing. Processed files will be saved in a separate
folder named **high throughput sequencing processed data (HTSPD)** (Figure
2b). This file will include any type of microbial or human annotated FASTQ or
FASTA files. Specifically, for metagenomics at least two subfolders will be
included, one per different strategy of microbial annotation: (1) based on de
novo assembly (metagenome assembled genomes) coded as **MAG** folder and, (2)
based on exact **k-mer sequence annotation** ( **KMA)** . Resulting data like
contigs, sequence derived statistics, dinucleotide odds ratios and metagenome
signatures, taxonomic assignments etc. will be included in a folder coded
**metagenome sequence data** ( **MSD** ) (Figure 2c).

_Publication data_ : Processed data to be submitted for publication and or
presentation to scientific meetings and workshops will be included in a
separate folder named **Publication data.** This folder will serve (a) the
primary folder under any type of reviewing process and (b) the circulation of
specific information of interest among consortium members which might not be
available in a journal’s supplementary data file.

Figure 2: Organisation of experimental data. Common folders, which will be
found at all consortium centres (a) & (b) and, specifically for metagenomics
(University of Manchester) (c).

_Databases:_

A number of databases will be developed, initially corresponding to individual
work package activities and subsequently by merging of these into larger
databases for the analyses and the modelling. A list of provisioned databases
follows:

  1. Clinical database A - cross sectional (Task 1.1., NKUA) 

    1. Clinical, epidemiological, demographic data - coming from questionnaires 

  
  

  

  

(baseline questionnaires, ACT, ACQ)

  2. Clinical measurements: lung function (spirometric, impulse oscillometry, exhaled fractional nitric oxide) e-diary cards, Skin prick tests 

  

  

  2. Clinical database B - longitudinal (Task 1.2, NKUA) 

    1. Clinical, epidemiological, demographic data - coming from questionnaires 

  
  

  

  

(baseline questionnaires, ACT, ACQ)

  2. Clinical measurements: lung function (spirometric, impulse oscillometry, exhaled fractional nitric oxide, methacholine provocation test), e-diary cards, Skin prick tests 

  

  

  3. Clinical database C_cross sectional 

    1. Clinical, epidemiological, demographic data - coming from questionnaires 

  
  

  

  

(baseline questionnaires)

  2. Clinical measurements: lung function (spirometric, impulse oscillometry, exhaled fractional nitric oxide), Skin prick tests 

  

  

  4. E-diary and e-spirometry database 

  

  

a. The data will be stored in Nuvoair encrypted and complaint health cloud and
shared with clinical partners

  5. Immune response database - Innate (Task 2.1, BRFAA) 

  

  6. Immune response database - B-cells (Task 2.1, SIAF) 

  

  7. Primary epithelial cell response database (Task 2.2, SIAF) 

  

  8. In-vitro database - PBMC, immune (Task 2.1, BRFAA) 

  

  9. In-vitro database - Epithelial cell lines (Task 2.2, SIAF) 

  

  10. Phage database (Task 4.1, ELIAVA) 

  

  11. Phage-bacteria interaction information (Task 4.2, 4.3 ELIAVA) 

  

  12. Metagenomics database (Task 3.1, UMAN) 13. Metagenomics metadata database (Task 3.2, UMAN) 14. Merged databases: 

    1. Host response DB 1+3+4+5 (NKUA, BRFAA, SIAF) 

  

    2. Clinical metagenomics correlation DB 1+2+10 (NKUA, UMAN) 

  

    3. Clinical-microbial-immune interactions DB 12a+11 (NKUA, BRFAA, SIAF, UMAN) 

  
  

  

  

Merged databases will be shared between the partners doing the relevant
analyses and forwarded to work package 5 for the modeling.

#  ⮚ Section 2: Flow of human donor information across research disciplines -
encoding of data

⮚ Upon inclusion in the study each donor will get a unique code id. This will
be defined by the centre identifier, i.e. 1 for NKUA and the number of the
donor included, e.g., the first donor to be included in NKUA will be 01. For
the baseline visit B0 will be added eg. 101-B0. For follow up visits, F and
the sequential number will be added, e.g., 101-F1 for the first visit,
101-F2….101-F9 for the ninth visit. Samples that will be processed in any
partner centre will be given locally a new code. In practice, it is easier to
work with short codes given per experiment or experimental procedure. For
example, if the sample obtained from donor 101-B0 is processed for
metagenomics then this sample will be given the relevant coding locally. The
local database will comply with good laboratory practice, high research
standards and the human tissue act. To do so, minimum information including
the central code id, the sample code (or multiple codes used in multiple
experiments), the type of sample (e.g., DNA, protein, RNA, metagenomes), the
type of processing (e.g. cDNA synthesis, whole genome amplification), the
remaining sample volume, and the exact location of storage (e.g., freezer 1, 2
nd  drawer, box 3, position 48) will be logged. The database will be linked
with the material transfer agreements between centres.

#  ⮚ Section 3: Flow of information in the data exchange backbone

The flow of information was outlined in Figure 8 of the project proposal
(reproduced below) and is described in detail in each work package. The major
focuses of information within the consortium are work package 1 (cohort
recruitment and follow up) and work package 3 (metagenomics). All information
will be integrated in work package 5 to be used in the mathematical models.

#  ⮚ Section 4: Data Types, Formats, Standards and Capture Methods

_Overview of Research data_ :

**Clinical data** ;

##  Nature of data

The data consists of the following quantitative, raw data:

  1. Clinical measurements (questionnaires, lung function_spirometry/impulse oscillometry and airway inflammation data_FeNO, diary cards, skin prick test) (clinical database) 

  

  2. Ex-vivo measurements 

    1. Flow cytometric measurements of nasal swabs (surface markers) 

  

    2. Blood cells (composition, response to stimuli) 

  

    3. Epithelial cells (viability, response to stimuli) 

  

    4. Levels of factors in serum (immunoglobulins, specific IgE) 

  
  

  

  3. In-vitro data 

    1. Cell-line response to stimuli (BRFAA, SIAF, NKUA) 4. Microbiological data 

  
  

    1. Bacterial and phage types/ characteristics, such as e.g. bacterial serotypes, identification methods applied: phage morphological classes (TEM images), their relatedness data, etc. 

  

    2. Phage-bacterial network data 

  
  

  

  

  5. Metagenomic data 

    1. Raw 

  

    2. Processed (different ways) 

  

    3. Metadata (OTUs, taxonomy, ecological indices) 

  
  

  

  6. Mathematical data 

  

  7. Model outputs 

  

  

Quantitative data formats are continuous, ordinal, nominal and binary.

###  Data collection

The procedure for the data collection will take place in the study centers, in
an especially configured private space, at scheduled date and time. The
participants will be informed via telephone call for the details of the
appointment. On the day of the recruitment the participant will be given a
unique study identifier. To ensure anonymity the name of the participant will
be confidential and will not be recorded into the questionnaires. The data
will be collected in hard copies (forms) and afterwards will be uploaded in a
secured database, from specially trained study personnel. Prior to any
participation, the recruiter will inform the participant of the studies
purpose, answer any questions the participant might have and have the
participate sign the informed consent. Then the baseline questionnaire will be
answered and the initial samples collected. Sampling will be repeated after
pre-defined time points.

##  Personal data

Personal identification data (name, date of birth, telephone number and
department ID and study IDs) in line with the “personal data definition”
according to GCP, will be stored separately and will not be used for analysis.
These will be saved in excel locked format, in the Coordinator’s personal
computer and in a locked hard drive in the Coordinator’s office, separately
from other data. Data will be encrypted and processed in an anonymized way.
The data collected in these interviews will be encrypted with a study number.
The data will not identify the participant by name, only by a number. The
encrypted data will be available to the study centre. All data protection laws
of the EU and partner countries will be followed. At the end of the study, the
analysis of the complete data will be published anonymously and only in
summary form, so that no single participant could be identified.

###  Data protection

All project data will be stored in accordance with the approval given to the
individual projects by the Respective (Greek and Polish) Data Protection
Agency.

Patient data will be fully anonymized, so that – by the data controller or by
any other person – it will be impossible to (i) identify individuals from the
data, (ii) link records relating to an individual, or (iii) for information
concerning an individual to be inferred from the data. Detailed information
are also provided in section 5 _storage and security

###  Archiving and preservation – General principles

Data from the CURE project will be archived for long-term preservation at the
earliest five years after project completion, in accordance with the Grant
Agreement. Data will only be entered into long-term storage if it is in
agreement with the CURE Steering Committee, or when the relevant Data
Protection Agency approval expires.

###  Data sharing – general principles

Data will be shared through the CURE consortium, with participating partners
accept and in compliance with applicable legislation:

  1. We expect data regarding 300 variables per donor per scheduled visit. 

  

  2. **Epidemiological data** relative to microbial exposure (Task 1.1 and 1.2). Based on relative questionnaires which will describe the level of microbial exposure and type of microbial exposure of each donor including life in an urban or rural environment, average contact with other people, means of commuting (metro, tram, bus, cycling, walking), job type, going to school or not, pets in the house etc., we expect data regarding 200 variables per donor. 

  

  3. **Metagenomic data** . Unprocessed raw metagenomic data will include 4 FASTQ files per processed sample (swab); (i) Metagenome library data from isolated microbial DNA (x2 due to pair-end sequencing), and (ii) Metagenome library data from isolated microbial RNA (x2 due to pair-end sequencing). These files will be handed from the University of Manchester genomics core facility directly to a designated member of the UMAN team, after appropriate demultiplexing and quality control of samples. 

  

  

Processed metagenomic data will include qualitative and quantitative
information regarding the annotated microbial species identified in each
processed sample. For each sample 2 major files will be formatted: (i)
metagenome content based on de novo assembly of contigs with information
regarding the absolute number of reads and the relative abundance of each
microbial taxon and at all taxon classification levels, (ii) metagenome
content based on microbial annotation without de novo assembly of genomes,
including the absolute number of reads and the relative abundance of each
microbial taxon and at all taxon classification levels. These files will be
shared to other consortium centres based on the specific interactions and flow
of information between centres as outlined in the main proposal (T5.1, T5.2,
T1.3, T3.1 and T3.2.).

Finally, processed metagenomic data will be produced in order to obtain a
predefined package of metadata to estimate the microbial diversity, richness
and abundance using individual and sample based rarefaction curves, annotate
inferred biological pathways and processes (GO terms) enriched in the
assembled metagenomes, calculate metagenomic signatures based on dinucleotide
relative abundance odds ratio (ρ*), identify viral signals (prophages) from
bacterial genomes and detect the CRISPR-Cas system and spacer sequences,
construct co-occurrence microbial interaction networks based on Spearman rank
tests and data from any other relevant metagenomics analysis.

  4. **Human in vitro data** . Cells from nasopharyngeal brushings of patients with asthma and healthy controls, will be characterised using a comprehensive panel of antibodies for monitoring diverse and rare leukocyte populations including macrophages, dendritic cells (DCs), T cells, B cells, innate lymphoid cells (ILCs), NK cells, neutrophils, eosinophils, mast cells and others, as well as epithelial cells. Major macrophage, dendritic cell (DC) and epithelial cell populations will be sorted (ARIA III, BD) and analysed by transcriptomics using next generation sequencing (RNAseq; Illumina MiSeq) and qPCR. Supernatants will be further analysed for the presence of relevant cytokines and chemokines using Luminex technology. The effect of relevant phage preparations on blood-derived macrophage & DCs and epithelial cell populations will be also be examined in culture. Finally, co-culture of different bacteria with air-liquid interfacedifferentiated human epithelial cells will be infected with varying doses of relevant bacteria and treated with various titres of corresponding bacteriophages (single related to the same species or their mixtures with overlapping host ranges). Data generated will include measures of epithelial and microbial viability, proliferation, mediator transcription and production. 

  

  5. **Microbial in vitro data** . The phages will be isolated from nasal swabs, sputum, oral or nasal washings, clinical environment, lysogenic strains, etc. An enrichment methodology will be used for isolation of bacteriophages. For this purpose, a set of the host cultures will be obtained from international culture collections and isolated from the CURE cohort. The isolated phages will be then characterized according to their biological and morphological (TEM images) properties, such as plaque and capsid morphology, host range, single cell growth parameters (adsorption time, latent period, yield) and genetic features, using PCR, molecular typing (RAPD-PCR) and sequencing analyses. Crossinfection of phage isolates against a panel of bacteria will be performed using spot assays. 

  

  

**Mathematical data** . (1) _Phage-bacteria interactions_ : A cross-infection
matrix constructed and represented as a network where phages and bacteria are
represented as nodes and edges will indicate a phage can infect and lyse a
specific host strain. The degree of interactions for each node will be used to
hierarchically cluster phage species based on their ability to infect multiple
bacteria species. To examine whether the phage-bacterial interactions are
deterministic and predictable (ecological and evolutionary drivers) or random,
four key types of Phage-Bacteria Infection networks (PBINs) will be
investigated: random, one-to-one, nested (NTS and NODF) and modular (Bipartite
Recursively Induced Modules, BRIM). Two widely used null models, the Bernoulli
random network and the probabilistic degree network will be used to measure
the statistical significance of patterns in the PBIN. (2) _Mathematical
modelling_ : Dirichlet multinomial mixture models, least angle regression and
model weighting approaches, and Lotka-Volterra models will predict the
dynamics of i) the bacterial and phage strains involved in health and disease
and ii) other microbial strains commonly found in the respiratory tract.
Stochastic optimisation (e.g., stochastic tunnelling) will be used to identify
optimal control strategies. Mathematical data processing will be implemented
in the R package and MATLAB.

**_Standards and best practices in next generation sequencing_ ** : The
metadata spreadsheet for NGS data will meet GEO’s standards. It provides
comprehensive information about the study design, sample information, the
protocol, data processing pipeline. In the repository of shared code will
include Wiki page and README file to describe the setup of computing
environment, usage of the software and demo. A recent overview (
_https://doi.org/10.1093/gigascience/gix047_ )  , discusses in detail the
landscape of data standards available for the description of essential steps
in metagenomics, including (i) **material sampling** , (ii) **material
sequencing** , (iii) **data analysis** , and (iv) **data archiving and
publishing** . We will follow the proposed Metagenomics Data Model providing
information regarding the: (1) study: information about the scope of a
sequencing effort that groups together all data of the project, (2) sample:
information about provenance and characteristics of the sequenced samples, (3)
experiment: information about the sequencing experiments, including library
and instrument details, (4) run: an output of a sequencing experiment
containing sequencing reads represented in data files, and (5) analysis: a set
of outputs computed from primary sequencing results, including sequence
assemblies and functional and taxonomic annotations.

**_Sampling_ ** : We will modify The Minimum Information about Metagenomic
Sequence (MIMS)  ( _http://wiki.gensc.org/index.php?title=MIGS/MIMS_ )
standard based on our tissue specific output. MIMs is a Genomic Standards
Consortium (GSC)-developed data reporting standard designed for accurate
reporting of contextual information for samples associated with metagenomic
sequencing, and it is also largely applicable to metatranscriptomics studies.

**_Sequencing_ ** : Once a sample is collected and its provenance recorded, it
is subjected to preparation steps for nucleotide sequence analysis. Equally
critical for the downstream metagenomic data analysis and interpretation is
the reporting of sequencing library preparation protocols and parameters as
well as sequencing machine configurations. We will use existing MIxS fields to
describe mandatory information (mandatory descriptors for new generation
nucleotide sequencing experiments as currently captured by International
Nucleotide Sequence Database Collaboration (INSDC) databases) and non-
mandatory descriptors as outlined in MIMs.

**_Experiment and Run_ ** : Variable parameters of the library preparation and
instrumentation are captured in the metadata objects Experiment and Run. Each
Experiment should refer to Study and Sample objects, to provide context for
the sequencing, and is referred to from the Run objects, which point to the
primary sequencing reads.

Examples of the Experiment and Run XML are available, e.g., from the European
Nucleotide Archive (ENA):

[http://www.ebi.ac.uk/ena/submit/preparing-xmls#experiment]

[http://www.ebi.ac.uk/ena/submit/preparing-xmls#run]

The primary data (the reads) are stored in files of various formats, which can
be standard (Binary Alignment/Map [BAM], Compression Reduced Alignment/Map
[CRAM], or Fastq) or a platform specific, as with standard flowgram format
(SFF), PacBio, Oxford Nanopore, or Complete Genomics. Information on the read
data format must be indicated in the description of sequencing.

The minimum information encapsulated in read data files includes base calls
with quality scores. Quality requirements on read data files are file format
specific and are summarized, e.g., in the ENA data submission documentation. A
freely available diagnostic tool for the validation of CRAM and BAM files is
the Picard ValidateSamFile. Validation of FastQ files is less straightforward
since there is no single FASTQ specification. Recommended usage of FASTQ can
be found, e.g., in the ENA guidelines. An open resource for managing next
generation sequencing datasets is the NGSUtils, which also contains tools for
operations with FASTQ files. As sequencing technologies change over time, the
formats and associated validation tools may well change, so a comprehensive
list of formats and tools is likely to become outdated. The key point is to
adopt a widely used format and to check for file format and integrity (e.g.,
checksums).

**_Analysis:_ ** There are currently no standards for reporting how
metagenomics datasets have been analysed. While systematic analysis workflows,
such as those offered by EMG, Integrated Microbial Genomes with Microbiomes,
META-pipe, and MG-RAST, provide a standard that is documented (albeit in
different ways), many published datasets are analysed by in-house bespoke
pipelines. A schematic overview of a best practice for analysis metadata
collection is shown in Fig. 3A (adapted from
_https://academic.oup.com/gigascience/article/6/8/1/3869082_ )  . An
overarching set of metadata relating to analysis will encapsulate generic
information such as analysis centre, name of bioinformatician, analysis
objectives, name of overall analysis (if appropriate), and the date on which
the analysis was performed. It will also contain appropriate pointers to the
run data, run sequence metadata, and associated sample data. Underneath the
overarching analysis metadata is a collection of analysis components that
describe each stage of the analysis (Fig. 3B). Each component can be divided
into 3 sections: input(s), analysis algorithm, and output(s).

Figure 3: Schematic overview of a best practice for analysis metadata
collection

Archived components will be tailored to the analysis but will at least include
operational taxonomic unit counts and assignments, functional assignment
counts, and read/sequence positional information for the aforementioned
assignments. Such data files are already made available from MG-RAST and EMG,
and those from other sources are accepted for archiving within ENA. If
metagenomic assemblies have been performed, then these should have an
appropriate structure of contigs, scaffolds, or chromosomes with an
appropriate format as detailed, e.g., in the ENA data submission
documentation. Due to the overheads of producing an assembly, these should be
archived, ideally with an INSDC database.

#  ⮚ Section 5: Short-term Storage and security

1\. **Clinical-epidemiological data** : All clinical protocols, procedures and
questionnaires will be described in a clear and detailed manner that will
allow reproducibility, follow up and sharing between clinical centers/members,
consortium members or peer-reviewers upon request. The protocol files will
reside within the local hospital intranet secure servers. Questionnaires and
procedures derived during the study from participants, including unprocessed
data will be kept hardcopies in a specific locked drawer in the PI’s office
and will be saved in a specific folder under the name “Cure_WP1” in pdf
format. The folder will contain other sub-folders named WP1a/ WP1b/WP1c and
further per questionnaire / procedures in the respective centers (Athens
_Research laboratory of the Allergy Unit, 2  nd  Pediatric Clinic and Sotiria
Hospital Athens Greece and Lodz). Clinical data will be stored locally at the
donor inclusion centres for the duration of the project. Only ID study numbers
will be used to identify participants in the data files and
samples/procedures, according to protocol labeling. Consent forms will be
saved in hard copies and in e-pdf format in the “Cure_WP1” folder, as
described above.

The electronic unprocessed formats will be saved and monitored by the
respective research team (personal computer of the PI, medical responsible for
the study_data manager) in the respective centers or according to local
custom. Datasets will be named with date and version.

Raw data as produced by instruments (spirometry, impulse oscilometry, skin
prick tests, SCORAD, CAP results) will be saved in hard copies and locked in
electronic pdf formats, as described above.

Data files will be named according to CURE, type of data and date of
creation/revision. Data variables in individual files will be given an
abbreviated variable name, together with a longer, explanatory variable label.

Raw data from spirometry will be processed by the GLI 2012 predictive values
excel from, before uploaded in the e-database.

##  _The e-database_

Processed raw data or metadata will be uploaded and stored in the e-database
in the REDCap system. A designated member of the research team will be
responsible for filling in the information to the electronic database.

The database will be created with the use of the RedCap programme. REDCap
(Research Electronic Data Capture) is a secure, web-based application designed
to support data capture for research studies. The primary objective of RedCap
is to provide high-quality data by keeping the number of errors and the
missing data as low as possible. The administrator is responsible for
controlling and allocating the database access.

Access to database requires user authentication using a password. Recruiters
create a new record using a unique code for each patient or edit an existing
one. The match between the code and the patient is known only to the recruiter
of each country ensuring patient's anonymity. The database will be updated
once a month in order to reduce time for the circulation of essential
information among centres

All records are stored on a secure encrypted server. In the end of the study,
administrator exports data to common data analysis packages (Microsoft Excel,
PDF, SAS or SPSS for analysis). The language of the database is English. The
location of the database will be in:  _www.allergy1.gr/cure_ .  The server
does automatically back up so that the data cannot be lost and the
functionality of the database allows the restore of the data up to a month
ago. Access in the platform will have authorized people only. The access will
be given by the administrator. The administrator provides with a username via
email the corresponding person and an auto-generated password. In case the
recruiter forgot his password there is the choice ‘’forgot the password’’ and
then automated he will receive an email to set a new password. The password is
known only from the recruiter. No one else can log in the data base.

Afterwards, for the needs of the analysis, data will be exported in a data
analysis package by the administrator.

##  Quality and security control of the e-database

The database will be locked after the completion of the data entry. Quality
control check will be applied to the inserted data in order ensure the quality
of the data. In order to avoid the input of incorrect data, the fields on the
e-database will accept specific character types, numerical or text. Each field
will be set by default the kind of value it will accept. The option of a drop
down list for multiple choice options will be available in the corresponding
fields.

The donor’s medical file will be linked with the CURE donor code within the
database through a separate key to protect anonymity. Only the designated
medical professional and the PI of the recruitment centre will have the key to
link donor’s name to the code in order to follow up and send reminders for
visits.The CURE clinical database will be hosted locally at the NKUA and will
be accessible for members of the consortium through the private area at:
_https://www.cureasthma.eu/about-us_ .  (Figure 4).

Figure 4: Schematic representation of CURE clinical data storage and sharing
protocol

**Metagenomic data** : Metagenomic data will be generated at UMAN. The
University of Manchester has an existing comprehensive data policy which will
be followed:

( _http://documents.manchester.ac.uk/DocuInfo.aspx?DocID=33802%20_ )  . This
policy applies to any data (Relevant Data) that is created or acquired in
research (funded or unfunded) involving staff and/or students of the
University (Relevant Research).

UMAN IT Services provides centrally hosted and administered data storage for
research staff/students — the Research Data Storage Service. Storage will be
available to each academic-led research project at no charge (up to 8 TB).
Further storage will be charged for. (This storage is commonly referred to as
Isilon.) All data will be stored on the servers/Isolon, and backed up to
encyrpted hard disks. Stored files within Isolon are accessible from desktop
and laptop machines on campus and may also be accessed from on-campus research
computing systems. For off-campus access, VPN will be used. Files stored on
this service are secure. For example, files corrupted or accidentally deleted
can be recovered for up to 35 days.

No personal data will be available since all files will be given local codes
per experiment and run as described before.

2\. Human in vitro data: Human in vitro data will be generated at SIAF and
BRFAA. Data storage and security will comply with local standards. The data
storage on personal computers will be real-time backed up with CrashPlan (
www.crashplan.com)  . NGS data will be submitted into GEO
(https://www.ncbi.nlm.nih.gov/geo/) and assigned with unique accession number.
The unique accession number is commonly referred when the data is used in a
publication. Programming language code will be available as a Github
repository (https://github.com/) with a permanent URL. Usage by other
researchers can be monitored by download count. Other data will be deposited
into DRYAD (http://datadryad.org/) and assigned with DOI. DRYAD provides usage
statistics of the data. All digital repositories will be choosen will conform
to the FAIR Data Principles. We will choose digital repositories maintained by
a non-profit organisation. Large raw and intermediate data produced with High
Performance Computing will be stored on Science Cloud of University of Zürich
and storage server of FGCZ. **Microbiological data:** Microbiological data
will be generated at ELIAVA and ELIBIO. Detailed strain characteristics,
including the data on isolation date, source, bacteriology and genetic
identification, serology, etc. will be stored in Excel files. The detailed
characteristics of

the isolated phages, including TEM images, physiological parameters, genetic
data will be stored in text, jpg and excel files.

#  ⮚ Section 6: Deposit, Long-Term Preservation and accessibility

Results from the project will be disseminated by publication in high quality,
internationally recognised peer-reviewed journals. We will make use of Open
Access (OA) options to ensure that our results are freely available to the
entire scientific community and the public. The raw data files (FASTQ) will be
deposited as freely accessible in the European Nucleotide Archive and the
NCBI, and available from time of publication. The wider scientific community
will be able to access the data and use them for data mining and discovery.
The metadata will also be available in metagenomic repositories (EBI
Metagenomics). GitHub will be used for archive of code and DRYAD to archive
data, and code, related to a specific publication.  
  
<table>  
<tr>  
<th>

**Dataset ID**

</th>  
<th>

**NKUA_C_S**

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

Partner name

</td>  
<td>

National and Kapodistrian University of Athens

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

Purpose of data

</td>  
<td>

Clinical database A - cross sectional (Task 1.1.,

NKUA)

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

Longitudinal data

</td>  
<td>

No

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</td>  
<td>

60

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

Number of different variables

</td>  
<td>

300

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

How frequently will the database be updated?

</td>  
<td>

Monthly

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

Database in Engligh?

</td>  
<td>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

</th>  
<th>

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

**Dataset ID**

</td>  
<td>

**NKUA_L**

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

Partner name

</td>  
<td>

National and Kapodistrian University of Athens

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

Purpose of data

</td>  
<td>

Clinical database B - longitudinal (Task 1.2, NKUA)

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

Longitudinal data

</td>  
<td>

Yes

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</td>  
<td>

78

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

Number of different variables

</td>  
<td>

300

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

How frequently will the database be updated?

</td>  
<td>

Monthly

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

Database in Engligh?

</td>  
<td>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**NKUA_SC**

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

Partner name

</td>  
<td>

National and Kapodistrian University of Athens

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

Purpose of data

</td>  
<td>

Clinical database C – Cross-Sectional (Task 1.3,

NKUA)

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

Cross Sectional data

</td>  
<td>

Yes

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</td>  
<td>

30

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

Number of different variables

</th>  
<th>

300

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

How frequently will the database be updated?

</td>  
<td>

Monthly

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

Database in Engligh?

</td>  
<td>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**BRFAA_Innate**

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

Partner name

</td>  
<td>

Biomedical Research Foundation, Academy of

Athens

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

Purpose of data

</td>  
<td>

Immune response database - Innate (Task 2.1,

BRFAA)

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

Longitudinal data

</td>  
<td>

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</td>  
<td>

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

Number of different variables

</td>  
<td>

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

How frequently will the database be updated?

</td>  
<td>

Monthly

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

Database in Engligh?

</td>  
<td>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**SIAF_B_Cells**

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

Partner name

</td>  
<td>

Swiss Institute of Allergy and Asthma Research

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

Purpose of data

</th>  
<th>

Immune response database - B-cells (Task 2.1, SIAF)

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

Longitudinal data

</td>  
<td>

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</td>  
<td>

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

Number of different variables

</td>  
<td>

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

How frequently will the database be updated?

</td>  
<td>

Monthly

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

Database in Engligh?

</td>  
<td>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**SIAF_Epithelial**

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

Partner name

</td>  
<td>

Swiss Institute of Allergy and Asthma Research

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

Purpose of data

</td>  
<td>

Primary epithelial cell response database (Task 2.2,

SIAF)

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

Longitudinal data

</td>  
<td>

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</td>  
<td>

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

Number of different variables

</td>  
<td>

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

How frequently will the database be updated?

</td>  
<td>

Monthly

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

Database in Engligh?

</th>  
<th>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**BRFAA_Adaptive**

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

Partner name

</td>  
<td>

Biomedical Research Foundation, Academy of

Athens

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

Purpose of data

</td>  
<td>

In-vitro database - PBMC, immune (Task 2.1,

BRFAA)

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

Longitudinal data

</td>  
<td>

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</td>  
<td>

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

Number of different variables

</td>  
<td>

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

How frequently will the database be updated?

</td>  
<td>

Monthly

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

Database in Engligh?

</td>  
<td>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**BRFAA_Epithelial**

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

Partner name

</td>  
<td>

Biomedical Research Foundation, Academy of

Athens

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

Purpose of data

</td>  
<td>

In-vitro database - Epithelial cell lines (Task 2.2,

SIAF)

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

Longitudinal data

</th>  
<th>

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</td>  
<td>

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

Number of different variables

</td>  
<td>

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

How frequently will the database be updated?

</td>  
<td>

Monthly

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

Database in Engligh?

</td>  
<td>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**ELV_INST**

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

Partner name

</td>  
<td>

The Eliava Institute of Bacteriophage, Microbiology and Virology

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

Purpose of data

</td>  
<td>

Phage database (Task 4.1, ELIAVA)

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

Longitudinal data

</td>  
<td>

No

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</td>  
<td>

Not applicable

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

Number of different variables

</td>  
<td>

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

Time period the data cover

</td>  
<td>

4 years

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

How frequently will the database be updated?

</td>  
<td>

Monthly

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

Database in Engligh?

</th>  
<th>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**ELV_INST**

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

Partner name

</td>  
<td>

The Eliava Institute of Bacteriophage, Microbiology and Virology

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

Purpose of data

</td>  
<td>

Phage-bacteria interaction (Task 4.2, 4.3 ELIAVA)

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

Longitudinal data

</td>  
<td>

No

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</td>  
<td>

Not applicable

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

Number of different variables

</td>  
<td>

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

How frequently will the database be updated?

</td>  
<td>

Monthly

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

Database in Engligh?

</td>  
<td>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**UMAN_base**

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

Partner name

</td>  
<td>

The University of Manchester

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

Purpose of data

</td>  
<td>

Metagenomics database (Task 3.1, UMAN)

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

Longitudinal data

</td>  
<td>

No

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</th>  
<th>

70

</th>  
<th>

</th>  
<th>

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

Number of different variables

</td>  
<td>

>300

</td>  
<td>

</td>  
<td>

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

How frequently will the database be updated?

</td>  
<td>

Monthly

</td>  
<td>

</td>  
<td>

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

Database in Engligh?

</td>  
<td>

Yes

</td>  
<td>

</td>  
<td>

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

Quality checks on dataset

</td>  
<td>

Yes

</td>  
<td>

</td>  
<td>

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**UMAN_Meta**

</td>  
<td>

</td>  
<td>

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

Partner name

</td>  
<td>

The University of Manchester

</td>  
<td>

</td>  
<td>

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

Purpose of data

</td>  
<td>

Metagenomics metadata database

UMAN)

</td>  
<td>

(Task

</td>  
<td>

3.2,

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

Longitudinal data

</td>  
<td>

Yes

</td>  
<td>

</td>  
<td>

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

</td>  
<td>

</td>  
<td>

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

Number of unique patients that the database will involve

</td>  
<td>

150

</td>  
<td>

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

Number of different variables

</td>  
<td>

>300 per visit (max of 5 visits per person)

</td>  
<td>

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

How frequently will the database be updated?

</td>  
<td>

Monthly

</td>  
<td>

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

Database in Engligh?

</td>  
<td>

Yes

</td>  
<td>

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

Quality checks on dataset

</td>  
<td>

Yes

</td>  
<td>

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

</td>  
<td>

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**Merged_Host_response**

</td>  
<td>

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

Partner name

</th>  
<th>

NKUA, BRFAA, SIAF

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

Purpose of data

</td>  
<td>

Host response DB 1+3+4+5 (NKUA, BRFAA, SIAF)

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

Longitudinal data

</td>  
<td>

No

</td>  
<td>

</td>  
<td>

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

</td>  
<td>

</td>  
<td>

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

Number of unique patients that the database will involve

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Number of different variables

</td>  
<td>

Number of variables

</td>  
<td>

</td>  
<td>

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

How frequently will the database be updated?

</td>  
<td>

Monthly

</td>  
<td>

</td>  
<td>

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

Database in Engligh?

</td>  
<td>

Yes

</td>  
<td>

</td>  
<td>

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

Quality checks on dataset

</td>  
<td>

Yes

</td>  
<td>

</td>  
<td>

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**Merged_Clinical_Metagenomics**

</td>  
<td>

</td>  
<td>

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

Partner name

</td>  
<td>

NKUA, UMAN

</td>  
<td>

</td>  
<td>

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

Purpose of data

</td>  
<td>

Clinical metagenomics correlation

(NKUA, UMAN)

</td>  
<td>

DB

</td>  
<td>

1+2+10

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

Longitudinal data

</td>  
<td>

Yes

</td>  
<td>

</td>  
<td>

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

</td>  
<td>

</td>  
<td>

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

Number of unique patients that the database will involve

</td>  
<td>

250

</td>  
<td>

</td>  
<td>

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

Number of different variables

</td>  
<td>

>300 per unique patient per visit

</td>  
<td>

</td>  
<td>

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

How frequently will the database be

</td>  
<td>

Monthly

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

updated?

</td>  
<td>

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

Database in Engligh?

</td>  
<td>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

</td>  
<td>

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

**Dataset ID**

</td>  
<td>

**Merged_Microbial_Immune**

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

Partner name

</td>  
<td>

NKUA, UMAN

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

Purpose of data

</td>  
<td>

Clinical-microbial-immune interactions DB 12a+11

(NKUA, BRFAA, SIAF, UMAN)

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

Longitudinal data

</td>  
<td>

No

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

Will these data be integrated with data from other centres?

</td>  
<td>

Yes

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

Number of unique patients that the database will involve

</td>  
<td>

200

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

Number of different variables

</td>  
<td>

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

How frequently will the database be updated?

</td>  
<td>

Monthly

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

Database in Engligh?

</td>  
<td>

Yes

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

Quality checks on dataset

</td>  
<td>

Yes

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

The 2 main routes to open access are:

Self-archiving / 'green' open access – the author, or a representative,
archives (deposits) the published article or the final peer-reviewed
manuscript in an online repository before, at the same time as, or after
publication. Some publishers request that open access be granted only after an
embargo period has elapsed.

Open access publishing / 'gold' open access - an article is immediately
published in open access mode. In this model, the payment of publication costs
is shifted away from subscribing readers. The most common business model is
based on one-off payments by authors. These costs, often referred to as
Article Processing Charges (APCs) are usually borne by the researcher's
university or research institute or the agency funding the research.

Final CURE data will be stored for 3 years after the end of the project, to
allow for maximum publication of findings before release, unless further
processing is needed for Intellectual property protection.

The project’s steering committee will be responsible for deciding the final
amount and type of data and metadata which will be stored after the end of
CURE. The committee will also decide which datasets wil be publicly available
through CURE’s website. Decisions on the above will be taken based on:

  * Potential publications and presentations in scientific meetings and conferences. 

  

  * Potential PhD projects to be concluded 

  

  * Data that can be used as preliminary for new EU funded or international grant applications, awards and fellowships. 

  

  * Potential patents that might arise from CURE. 

  

  * Completeness of datasets. A priority will be given in DOIs with complete datasets along the different CURE work packages, especially WP1, WP2 and WP3.Availability of storage space Ethics and Intellectual Property 

  

##  ETHICS

All data related processes, from collection and sharing to data research and
sustainability will be in compliance with the legal requirements established
by GDPR (General Data Protection Regulation).

CURE is a biomedical research project engaged in studying asthma using
clinical data of patients. Data relating to health constitutes sensitive
category of data. The processing of health data for research is subject to the
rules of data protection and requires legitimisation. Such legitimisation may
be given by the law, or by the patient by means of informed consent. Also,
since the project is engaged in biomedical research, the undertaking of such
research requires approval by the Ethics Committee after assessment “of its
scientific merit, including assessment of the importance of the aim of
research, and multidisciplinary review of its ethical acceptability.”
(Additional Protocol to the Convention on Human Rights and Biomedicine,
concerning Biomedical Research, Strasbourg, 25.I.2005)

In CURE, the use of sensitive data may be considered to be done in an
ethically and legally compliant way since the partners that contribute data to
the project, have informed consent of the patients and approvals by the Ethics
Committee.

##  INTELLECTUAL PROPERTY

The management of Intellectual Property (IP) in CURE is governed by the Grant
Agreement (GA) and Consortium Agreement (CA). In particular, Article 23a of
the GA makes it an obligation of the project partners to take measures to
implement the Commission Recommendation on the management of intellectual
property in knowledge transfer activities. One of the principles regarding
collaborative research is to develop an IP strategy and to manage IP related
issues as early as possible. IP-related issues include _“allocation of the
ownership of intellectual property which is generated in the framework of the
project (hereinafter “foreground”), identification of the intellectual
property which is possessed by the parties before starting the project
(hereinafter “background”) and which is necessary for project execution or
exploitation purposes, access rights to foreground and background for these
purposes, and the sharing of revenues.”_

According to this principle, and as also set forth by Article 24.1 of the GA,
the CURE partners identified and agreed on the background, which they agree to
contribute into the project, both as on the terms, on which such background
may be contributed and used in the project in the agreement on background
(Attachment 1 to CA).

The ownership of results is in general also regulated by the project GA/CA.
The basic principle that governs ownership of research results, as laid down
by Article 8.1 CA, is that the results are owned by the party that generates
them. In cases, when work producing the results has been performed by more
than one party and it is not possible to separate and/or define contributions
of each, then the contributing parties shall have joint ownership over such
results and each enjoy the rights in relation to the exploitation of a joint
work, as laid down in Article 8.2 CA.

In addition, one of the guiding principles in relation to managing ownership
in research results is that “ _the ownership of the foreground should stay
with the party that has generated it, but can be allocated to the different
parties on the basis of a contractual agreement concluded in advance,
adequately reflecting the parties' respective interests, tasks and financial
or other contributions to the project_ .” In essence, these rules advocate and
delegate the management of IP and ownership to contractual arrangements. If
needed, the CURE consortium will set up contractual arrangements aimed to
address the IP and ownership related aspects of the project.

##  Resourcing

Original databases will be kept locally for the duration of the project and
beyond, with the responsibility of the corresponding partner. Merged databases
will be kept at the University of Athens, until uploaded onto free public
servers, as described above.