#  Executive Summary

E2Data’s vision is to develop a novel Big Data software stack that will help
Big Data practitioners to exploit in a transparent and efficient manner the
available underlying diverse heterogeneous hardware resources without
requiring software re-engineering by the programmers.

To achieve its goals, E2Data development will be driven by the requirements of
industrial partners, having the role of use case providers. This document
describes those application use cases which will be experimented within
E2Data. The background of each use case is described in order to identify the
underlying challenges in terms of business requirements.

The E2Data project needs to respond to diverse and strict requirements, in
terms of performance and infrastructure costs. Such requirements are driven by
the four participating use cases, in the following domains:

**Health Use Case –** It is necessary to improve the predictive capability of
a hospital readmission risk prediction algorithm. To achieve this, the patient
discharge profile is enhanced with profiles of highly correlated patients (in
terms of recent hospital activity). The patient correlations are established
based on their medical conditions. The algorithmic solution enters into time
sensitive matrix calculations which need to be accelerated appropriately.

**Fintech (Natural Language Processing) -** Processing of unstructured data
(text) is a powerful tool to extract knowledge from articles and messages,
including social media. Processing of such online streams within the financial
sector is useful when you need to correlate financial news with trade facts;
also useful in several other business domains where sentiment analysis needs
to be applied (i.e. tourism). In E2DATA, we focus on processing large amounts
of messages from social media, such as Twitter, in order to perform semantic
information extraction, sentiment analysis, summarization, interpretation and
organization of their contents. Critical language processing algorithms are
falling in the critical path in the knowledge extraction process; therefore,
acceleration is considered as a solution towards enhanced performance.

**Green Building Infrastructure.** Management and monitoring of buildings
employs an Internet-ofThings (IoT) Framework cloud platform with high
scalability both in terms of users, number of connected devices and volume of
data processed. It accommodates real-time processing of information collected
from mobile sensors and smartphones and offers fast analytic services. The
Cloud Services offer real time processing and analysis of unlimited IoT data
streams with minimal delay and processing costs.

**Security and biometric recognition.** Biometric authentication, using facial
recognition, is fast becoming a mainstream method of authenticating customers
for high value transactions, such as the creation of Bank Accounts, issuing of
Travel Visas and unmanned border crossing by preregistered users. Such
processes are coupled with tight SLA to ensure user experience is maintained,
even when a single transaction involves the processing of 30 images and the
execution of deep neural networks. The nature of security results in the
complexity of processing that is continuously increasing. E2Data will be asked
to both optimize the cost base of the platform and automate the performance
optimization of code which is currently undertaken by highly skilled
engineers.

From the business level, the document moves to lower code level details, where
critical computation takes place and acceleration is needed to improve
performance and eliminate bottlenecks. Candidate code kernels for acceleration
are described. A first set of code includes:

  * a matrix inversion algorithm 

  

  * an algorithm for lexicographical approximate matching in vocabularies using distances between words 

  

  * approximate Matching in dictionaries stored as Directed Acyclic Graph Words 

  

  * cosine similarity applied on words or q-grams and a variation of the algorithm in order to rank documents 

  

  * fuzzy Matching of terms in terminological dictionaries stored in Compressed Tries ● computing the sum / maximum / minimum / average of sensor measurements. 

  

  * carrying out a large number of PearsonR correlation coefficient calculations in a very small time period. 

  

  * algorithm that takes an array of RGB images containing faces together with a set of feature location for the faces, and ‘morphs’ each individual image to a standard face which is finally returned. 

  

Apart from the application use case context and the specific computation field
requirements, the document includes a data management framework that the
project will follow in order to manage the use cases’ datasets. Results of the
project action includes scientific publications, data research results and
datasets that are available for processing and experimentation. The Data
Management Plan and the relevant principles are set in the project, in order
to assure access, respect to personal data, re-usability, sharing, archiving
and presentation. A common framework is set by the project that is to be
instantiated by each use case. Main pillars of the plan include:

  * Open access to scientific publications; 

  

  * Open access to research data; 

  

  * Standards and metadata; 

  

  * Data access; 

  

  * Access and sharing policies; 

  

  * Re-usability and distribution; ● Archiving and presentation. 

#  Introduction

E2Data’s vision is to develop a novel Big Data software stack that will help
Big Data practitioners to exploit in a transparent and efficient manner the
available underlying diverse heterogeneous hardware resources without
requiring software re-engineering by the programmers.

While in the de-facto scale-out or homogeneous scale-up model the applications
are partitioned and sent for execution on CPU nodes, E2Data will intelligently
identify which parts of the applications can be hardware accelerated and,
**dynamically** , based on the current hardware resources will send tasks for
execution on the appropriate nodes. The scheduling, compilation, and execution
of the tasks will happen “on-the-fly” without requiring Big Data practitioners
to write not-portable, low-level code for each specific device or accelerator.
This will ultimately translate to: a) **higher performance** of Big Data
execution, b) **energy efficient execution** , c) **significant cost
improvements** for cloud providers and endusers, and d) **enhanced scalability
and performance portability** of Big Data applications.

In order to achieve its ambitious goals, E2Data will follow an **application-
driven approach** in which the development of the proposed solutions will be
guided by the SLAs of the industrial partners. Enabling current Big Data
software stacks to perform transparent and efficient heterogeneous execution
is a challenging task in which pre-defined objectives and performance Key
Performance Indicators (KPIs) must be satisfied in order to assess success.
The selected real-world and complex scenarios of the industrial partners are
guiding the technological advancements. Since E2Data is not aiming to provide
a new Big Data software stack but rather to break the barriers of existing
deployments to exploit heterogeneity, its high impact objectives and
deliverables will be immediately available to the industrial partners for
exploitation.

The aim of this document is to present and describe those application use
cases which will be experimented within E2Data. The background of each use
case is described in order to identify the underlying challenges in terms of
business requirements. Moreover, indicative code segments are identified and
presented in detail. These code segments will be the focus for acceleration,
as being critical in the overall computation process. More code kernels will
be also identified during the project progress. These will be the main
requirements to drive the E2Data architecture options design choices.

Apart from the application use case context and the specific computation field
requirements, the document includes a data management framework that the
project will follow in order to manage the use cases’ datasets.

#  Use Cases Overview

The E2Data project needs to respond to diverse and strict requirements, in
terms of performance and infrastructure costs. Such requirements are driven by
the four participating use cases, in the following domains:

**Health Use Case –** It is necessary to improve the predictive capability of
a hospital readmission risk prediction algorithm. To achieve this, it is
proposed to enhance the patient discharge profile with profiles of highly
correlated patients (in terms of recent hospital activity). It is proposed to
establish the patient correlations based on their medical conditions. The
number of unique codes, identifying reasons for patient hospitalization, runs
into tens of thousands. Further, for a sufficiently large number of National
Health Service (NHS) trusts (i.e. organisations in the UK that serve different
aspects of a patient in a specific geographic area), the number of patients
can easily run into millions over the span of a few years. The algorithmic
solution enters into time sensitive matrix calculations which need to be
accelerated appropriately.

**Fintech (Natural Language Processing) -** Processing of unstructured data
(text) is a powerful tool to extract knowledge from articles and messages,
including social media. Processing of such online streams within the financial
sector is useful when you need to correlate financial news with trade facts;
also useful in several other business domains where sentiment analysis needs
to be applied (i.e. tourism). In E2DATA, we focus on processing large amounts
of messages from social media, such as Twitter, in order to perform semantic
information extraction, sentiment analysis, summarization, interpretation and
organization of their contents. This analysis occurs by extracting from each
tweet phrases with specific syntactic forms. The process uses a number of
different dictionary types storing a diverse range of information from word
lists (vocabularies) to complex networks structures, expressing syntactic
patterns (kanon rules). These dictionaries provide hints with which each tweet
is going to be marked. The execution involves critical and complex algorithms
(words proximity, fuzzy matching, etc.) that are invoked upon each new text,
thus requiring their acceleration in order to become as efficient and scalable
as possible.

**Green Building Infrastructure.** Management and monitoring of buildings
employs an Internet-ofThings (IoT) Framework cloud platform with high
scalability both in terms of users, number of connected devices and volume of
data processed. It accommodates real-time processing of information collected
from mobile sensors and smartphones and offers fast analytic services. The
Cloud Services offer real time processing and analysis of unlimited IoT data
streams with minimal delay and processing costs. The current setup uses
averaging to minimize the required storage space. For obtaining near real-time
information on the buildings’ status, it is necessary to shorten the averaging
period, an approach that will lead to significant data volume increase. In
this context, the sensors and the platform will generate, handle, transfer and
store a tremendous amount of data, which cannot be processed in an efficient
manner using current platforms and techniques. Therefore, it is necessary to
utilize the E2Data stack for improving IoT Platform in order to rapidly
process the constantly accumulated data and tackle the issues generated by
thousands of parallel deployments of sensors, each generating enormous data
chunks that need to be processed almost in real-time.

**Security and biometric recognition.** Biometric authentication, using facial
recognition, is fast becoming a mainstream method of authenticating customers
for high value transactions, such as the creation of Bank Accounts, issuing of
Travel Visas and unmanned border crossing by preregistered users. This has
been enabled by the introduction of methods that can detect presentation
attacks, such as photos, masks or replay attacks [1]. iProov is a leader in
this space and the service offers both multi-tenant and dedicated cloud based
Software-as-a-Service (SaaS) offerings to both government and commercial
organisations. The data volumes involved are large; for example, the image
analysis rate for one government customer recently tested as 12 % of the
global image upload rate of Facebook. This is coupled with a tight SLA to
ensure user experience is maintained, so a single transaction that will
typically require the processing of 30 images; the execution of 10+ deep
neural networks; and the execution of a large amount of compute intensive
algorithms is required to be completed in under 5 seconds. The nature of
security is that this is an ongoing arms race which results in the complexity
of processing continuing to increase. E2Data will both optimize the cost base
of the platform and automate the performance optimization of code which is
currently undertaken by highly skilled engineers typically in a CUDA
environment.

#  Health Use Case \- Fast Collaborative Filtering

##  Description of Use Case and Requirements

To improve the predictive capability of a hospital readmission risk prediction
algorithm, it is proposed to enhance the patient discharge profile with data
from highly correlated patients (in terms of recent hospital activity). In
particular, the aim is to establish the patient correlations based on their
medical conditions. The International Classification of Diseases (ICD),
maintained by the World Health Organisation (WHO), provides a system of
diagnostic codes for classifying diseases based on ICD codes. The number of
unique ICD codes, identifying reasons for patient hospitalization, are in the
order of magnitude of tens of thousands. Further, for a sufficiently large
number of NHS trusts, the number of patients can easily run into millions over
the span of a few years.

_Technical description:_ The patient’s medical condition matrix is a highly
sparse matrix because most patients are typically unlikely to suffer from most
medical conditions. Furthermore, over the span of a few years, this matrix,
for a normal size hospital, is likely to expand to the order of 10  10
elements. It is proposed to extract patient correlations from this matrix, for
the purpose of enhancing a readmission risk prediction model, through the use
of Model-Based Collaborative Filtering – a method that has been shown to be
extremely successful for identifying correlations [2].

###  Description of the Framing Environment

Model-based Collaborative Filtering has received significant attention mainly
as an unsupervised learning method for latent variable decomposition and
dimensionality reduction. Two approaches to achieve the matrix factorization
required in Collaborative Filtering are stochastic gradient descent and
alternating least squares (ALS). ALS is favorable in two cases: a) when the
system can use parallelization, and b) when the data is implicit [3].
Collaborative Filtering can be formulated by approximating a matrix by ALS.
Once the decomposed matrices (corresponding to patients and medical
conditions) have been obtained, various operations can be carried out on these
matrices to calculate pairwise patient similarity scores. ALS is an iterative
algorithm and can be very slow and computationally expensive but lends itself
to parallel implementations.

The ALS algorithm is as follows:

  1. Initialize the two target matrices X, Y 

  

  2. repeat 

  

  3. for u = 1...n do 

  

  4. 𝑥𝑢 = (∑𝑟𝑢𝑖 ∈𝑟𝑢∗ 𝑦𝑖𝑦𝑇𝑖 + 𝜆𝐼𝑘)−1 ∑𝑟𝑢𝑖 ∈𝑟𝑢∗ 𝑟𝑢𝑖𝑦𝑖 

  

  5. end for 

  

  6. for i = 1...m do 

  

  7. 𝑦𝑖 = (∑𝑟𝑢𝑖 ∈𝑟∗𝑖 𝑥𝑢𝑥𝑇𝑢 + 𝜆𝐼𝑘)−1 ∑𝑟𝑢𝑖 ∈𝑟∗𝑖 𝑟𝑢𝑖𝑥𝑢 

  

  8. end for 

  

  9. until convergence 

  

  

The key matrix operations required to implement (ridge regression) the
algorithm are: matrix inversion, dot product calculation and a sum of squared
errors calculation to check when the convergence criterion has been met. On a
single machine (non-parallel) implementation, the matrix inversion subroutine
is the most time consuming.

It is proposed to develop the matrix factorization in Java with Tornado APIs
used for providing the acceleration for the matrix inversion subroutine.

###  List of Critical Code Parts

The list of kernels which are candidates to accelerate are enumerated in the
Table below. Specifically for the Health Use Case, the kernel is the one that
performs matrix inversion.  
  
<table>  
<tr>  
<th>

</th>  
<th>

</th>  
<th>

**Title**

</th>  
<th>

</th>  
<th>

**Description**

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

1\.

</td>  
<td>

**Minv**

</td>  
<td>

</td>  
<td>

Matrix inversion

</td>  
<td>

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

##  Code Kernel “Minv”

**Description -** ALS factors a matrix A into two component matrices - X (for
example representing patientfeature space) and Y (for example representing
medical condition-feature space). The most compute intensive part of the ALS
algorithm is the calculation of the inverse of a matrix. The proposed kernel
should speed up the overall ALS by dealing with the most time consuming part.

The following Figure shows the time (in seconds) taken by three most time
consuming methods in the ALS process: matrix inversion (Invert), dot product
(Dot) and sum of square error (Error). The times were measured for datasets of
two sizes: small (2000x5000 elements) and medium (6040x3952 elements) [4],
each experiment running for 10 iterations. It can be seen that the time spent
calculating matrix inverse is far greater than the other and increases
significantly as the number of elements in the dataset increase.

_**Figure:** Stacked bar graph showing processing times (seconds) of the three
most time consuming subroutines in the ALS implementation for different sized
datasets _

Further, as stated, ALS is an iterative algorithm where the two factor
matrices (X, Y) are alternatively calculated such that the sum of squared
errors are minimized. Thus, for a given size of dataset, the number of
iterations needed to reach an acceptable error level varies. In general, the
higher the number of iterations permitted, the more likely that the desired
error level (smaller is better) will be reached. In the following Figure, we
compare the times taken by the subroutines as the number of iterations is
increased. It is clear that the time spent calculating the inverse matrix
increases very rapidly (almost exponentially) with the number iterations
permitted for the optimization process.

_**Figure:** Stacked bar graph showing processing times (seconds) of the three
most time consuming subroutines in the ALS implementation for different
iteration counts _

Input: float matrix A (m x m)

Output: float matrix A’ (m x m)

**Data involved -** The main input data should be received as a two
dimensional array of floating values. The input matrix is expected to be
square.

**Accelerating Code Kernel -** In order to support daily execution of
factorization routines, it is important to accelerate the ALS task which can
be very time consuming for large matrices and the matrix inversion is the most
time consuming operation in the algorithm. The above analysis clearly
highlights the importance of the matrix inversion routine in speeding up the
overall matrix factorization process.

**About the code** – The existing code is in Java, utilizing libraries [5]
_https://github.com/grafosml/okapi/blob/master/src/main/java/ml/grafos/okapi/cf/als/Als.java_
.  EXUS ALS code will use this (or equivalent implementation) as the base and
utilize the Tornado APIs for acceleration. The specific Java implementation of
ALS that will be used has not been finalized; however, the central process of
matrix inversion is expected to be common to all of them.

#  NLP Use Case

##  Description of Use Case and Requirements

Mnemosyne is a corpus processing and information extraction platform developed
by Neurolingo  ( _www.neurolingo.com_ )  . The platform has been designed with
the ambition to support and manipulate most of the branches of Natural
Language Processing (NLP) field that are:

  1. _Phonetics – Phonology_ : Phonetics examine the physiology of speech and describe the sounds in the way they are produced by the human phonetic systems. Phonology looks at the operation of these sounds in a specific linguistic system (morpho-phonological relations). In each language, sounds can be classified into a finite set of phonemes. Traditionally, they include vowels: a, e, i, o; and consonants: p, f, r, m. Phonemes are assembled into syllables: pa, pi, po, to build up the words. 

  

  2. _Morphology_ : This second level concerns the words. The word set of a language is called a lexicon. Words can appear under several forms, for instance, the singular and the plural forms. Morphology is the study of the structure and the forms of a word. Usually a lexicon consists of root words. Morphological rules can modify or transform the root words to produce the whole vocabulary. Morphology concerns morphemes, i.e. the smallest word segments that can carry semantic information. 

  

  3. _Syntax_ is a third discipline in which the order of words in a sentence and their relationships is studied. Syntax defines word categories and functions. Subject, verb, object is a sequence of functions that corresponds to a common order in many European languages including English and French. However, this order may vary and the verb is often located at the end of the sentence (for example in German). Parsing determines the structure of a sentence and assigns functions to words or groups of words. Syntax deals with the way and the rules according to which words are combined in larger units, creating phrases and clauses. 

  

  4. _Semantics_ is a fourth domain of linguistics. It considers the meaning of words and sentences. The concept of “meaning” or “significance” can be controversial. Semantics is differently understood by researchers and is sometimes difficult to describe and process. In a general context, semantics could be envisioned as a medium of our thought. In applications, semantics often corresponds to the determination of the sense of a word or the representation of a sentence in a logical format. Semantics is either the research of the meaning of language elements or the research of the combination of these elements. 

  

  5. _Pragmatics_ is the fifth discipline of linguistics. While semantics is related to universal definitions and understandings, pragmatics restricts it – or complements it – by adding a contextual interpretation. Pragmatics refers to the study of linguistic production in specific cases. This means that the language is studied by its context (the participating members, the timing, the place, etc.). 

  

  

Mnemosyne incorporates a large number of text processing technologies
developed by Neurolingo and its scientists in more than a twenty years period.
Characteristic technologies used in NLP process are:

  1. Spelling Checking & Fuzzy Matching 

  

  2. Lexicons development as Morphology Lexicons, Thesaurus, Terminology Lexicons, etc. 

  

  3. Indexing and Searching 

  

  4. Syntax Checking & Grammar Checkers 

  

  5. Named Entity Recognition 

  

  6. Information Extraction 

  

  

####  Mnemosyne Features

In the following figure, we present the top level architecture of the
Mnemosyne platform.

_**Figure:** Mnemosyne Architecture _ The main features of the Mnemosyne
platform are:

  1. Process collections of texts stores in various media (files, websites, databases) and in various formats (DOC, XML, HTML, PDF, TXT). 

  

  2. Uses a large number of lexical resources as: alphabets, spelling dictionaries, morphological dictionaries, gazetteers, thesaurus, etc. 

  

  3. Creates different analyses of a text. Each analysis is expressed as a sequence of annotations on parts (text spans) of the input text. The input text remains unmodified as the annotations are stored in different parallel layers referencing parts of the input text. This architecture gives great flexibility because it permits to have different layers of annotations that may refer to interleaved text spans. 

  

  4. Analyzers are the software components that produce analyses. They are interconnected to flows where the output of an analyzer constitutes the input of another. These flows can represent parallel computation tasks increasing the throughput of the system. 

  

  5. The heart of the system is the “Kanon” formalism. Kanon formalism is close to Unification Grammars [6]. The formalism uses grammar rules that describe the syntax of the processed language. The execution of these rules creates the analyses described above. 

  

  6. Filtering of the produced annotations are transferred in the next processing phases. This way we minimize the information we pass and we need to handle from one phase. Except for the storage and transmission gain, we minimize the processing complexity of following phases because there are less annotations to handle and also less ambiguity to solve. 

  

  7. Fuzzy matching mechanisms are used for named entity recognition, i.e. persons, organizations, toponyms, etc. The recognition of a named entity is not always enough. Many times we also need to identify it, i.e. to match it in a set of similar entities and return a unique id. Usually these sets are stored in legacy databases which also provide a unique id for each entity. Mnemosyne provides two categories of fuzzy matching mechanisms. The lexicographic mechanisms that use spelling correction techniques and distance functions in order to match two strings and the statistical techniques that split the strings in words or parts of a word (q-grams) and use statistical formulas in order to evaluate the similarity of an input string (entity) with the entity strings in the database. 

  

  8. Specialized analyzers are responsible for exporting and/or transfering the extracted structural information to the desired formats and destinations (e.g. XML, Database tables, etc.). 

  

  9. There are special mechanisms for monitoring and logging of the process flow. The mechanisms are extensible and permit the concurrent storage of logged data in different formats and media (files, databases, network, etc.). The level of detail of the logged information is configurable and is very useful in case we want to debug the process. The schema of the logged information constitutes a generic schema for information extraction projects and can be used in a quick implementation of information extraction and text analytics projects. 

  

  10. The results of the information extraction process can be viewed, verified and corrected with a specialized Annotation Editor application. This is a GUI application with functionality that permits the editing of annotations of a text. 

  

  11. The large amounts of corpus texts alongside with the annotations produced by the information extraction process can be semantically searched with a web application. The users can use both non-structural (text) and structural (annotations) search criteria in order to search and retrieve the information they are interested in. The results presented also in a mixed nonstructural/structural way based on a concordance view. 

  

  

_Use Case Application -_ In the E2Data project, we focus on processing large
amounts of messages from social media, such as Twitter, in order to perform
semantic information extraction, sentiment analysis, summarization,
interpretation and organization on their contents. This analysis occurs by
extracting from each tweet phrases with specific syntactic forms expressed
with Kanon. The process uses a number of different dictionary types storing a
diverse range of information from word lists (vocabularies) to complex network
structures expressing syntactic patterns (kanon rules). These dictionaries
provide hints with which each tweet is going to be marked. After finishing
execution, Mnemosyne creates a large output file, stored either in Lucene or
in the local file system.

_NLP Kernels -_ Three of the most important Mnemosyne engine types incorporate
many functions have been chosen to be accelerated. The common characteristics
of these engines are: a) they use a type of dictionary that is static and
constant, and b) they work in stream mode, i.e. we feed the engine with input
(words or texts) and they return answers. The engine types that will be
accelerated are:

  1. Lexicographical fuzzy matching search in vocabularies using either: 

     * Directed Acyclic Graph Words or DAWG which is a deterministic acyclic finite state automaton [7] that can be accessed with regular expressions. 

  

     * Levenshtein distances between the dictionary words and the input words [8]. 

  

  

  2. Statistical fuzzy matching and classification applied in multiword expressions and/or documents using: 

     * Cosine similarity or TFIDF [9] applied on words or q-grams. 

  

     * Okapi BM25 [10], which is a similar to the TFIDF algorithm for ranking documents. 

  

  

  3. Fuzzy matching of multiword expressions using Compressed Tries [11]. Compressed Tries are used as indexes to various types of lexicons (morphological, terminological, syntactical, etc.). 

  

  

###  Description of the Framing Environment

To scale on a single server, Mnemosyne has been designed as a multithreaded
application. It uses a number of threads to process incoming tweets. Each
tweet is assigned to a different thread that performs all processing
associated with the tweet. Processing may involve multiple analysis steps
depending on the type of application. There is a central coordinator that
dispatches tweets to available threads for processing while processing
accesses private data structures, both to read and update information. Each
thread creates a private version of the required dictionaries and updates its
dictionary based on the tweets it processes. Although in other applications,
cross-tweet updates may be required, this is not the case in the applications
we examine in this report. Finally, the output, which is typically longer than
each tweet, is written to a file or database. In our experiments, we direct
output to files since this approach has lower overhead.

There are two flavors of multi-threading within Mnemosyne: _Hand-crafted
thread management_ and _Java streaming_ . In the first case, threads are
manually started and managed by application code. In the second case,
Mnemosyne uses Java 8 streams.

Java 8 offers a new abstraction that supports functional-style operations
(e.g. map-reduce) on a set of elements, called streams. Streams aim to provide
parallel processing to their elements, without the programmer having to
explicitly write parallel code; the parallelization is handled by the Java VM.
The difference between collections and streams is that collections are
concentrated to give direct access to their elements for operations, such as
update, whereas streams are concentrated on the source of the stream's
elements and the type of computational operations that are going to be
performed on that source.

Mnemosyne takes advantage of the characteristics of Streams. It uses a split
iterator for processing the input data, which is split to 1.5*#cores streams.
Hence, this version dynamically adapts to the capability of the server it runs
on. Both concurrent versions exhibit similar performance and scaling
characteristics.

###  List of Critical Code Parts

The list of kernels which are candidates to accelerate are enumerated in the
Table below:  
  
<table>  
<tr>  
<th>

</th>  
<th>

**Title**

</th>  
<th>

**Description**

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

1\.

</td>  
<td>

**Word Distance Kernel (WDK)**

</td>  
<td>

Lexicographical Approximate Matching in vocabularies using distances between
words (Levenshtein)

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

2\.

</td>  
<td>

**Directed Acyclic Graph Words Kernel**

**(DAWGK)**

</td>  
<td>

Approximate Matching in dictionaries stored as

Directed Acyclic Graph Words (DAWG)

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

3\.

</td>  
<td>

**TFIDFK**

</td>  
<td>

Cosine similarity (TFIDF) applied on words or qgrams

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

4\.

</td>  
<td>

**Best Match Kernel (BM25K)**

</td>  
<td>

Okapi BM25 is a variation of TFIDF algorithm ranking documents

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

5\.

</td>  
<td>

**Compressed Tries Kernel (CTK)**

</td>  
<td>

Fuzzy Matching of terms in terminological dictionaries stored in Compressed
Tries

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

##  Code Kernel “Word Distance Kernel” (WDK)

**Description -** The edit distance [12] between two strings of characters is
defined as the minimum number of edit operations needed to transform the first
string to the second. The permitted edit operations can be: insertion of a
character anywhere in the first string, deletion of a character from first
string and substitution of a character of the first string with another one.
The most known and used algorithm that computes the edit distance of two
strings is the Levenshtein and is a typical example of dynamic programming.
Despite the fact that the algorithm itself is not appropriate for acceleration
due to its recursive nature, we are going to accelerate the application of the
algorithm to a large number of pairs. Given a set of words L (lexicon) and an
input word w we will apply the Levenshtein algorithm between every word of L
and input word w. Then, we will output the words with the smaller distances as
candidates for the input word.

There are two variations of the algorithm, one that uses a matrix with
dimensions equal to the lengths of the words that we work on and one that uses
only two vectors of the previous matrix. We will implement the second
variation that needs less space. The algorithm is presented below: function
LevenshteinDistance(char s[1..m], char t[1..n]):

// create two work vectors of integer distances declare int v0[n + 1] declare
int v1[n + 1]

// initialize v0 (the previous row of distances)

// this row is A[0][i]: edit distance for an empty s

// the distance is just the number of characters to delete from t for i from 0
to n:

v0[i] = i

for i from 0 to m-1:

// calculate v1 (current row distances) from the previous row v0

// first element of v1 is A[i+1][0]

// edit distance is delete (i+1) chars from s to match empty t v1[0] = i + 1

// use formula to fill in the rest of the row for j from 0 to n-1:

// calculating costs for A[i+1][j+1] deletionCost := v0[j + 1] + 1
insertionCost := v1[j] + 1 if s[i] = t[j]:

substitutionCost := v0[j] else:

substitutionCost := v0[j] + 1

v1[j + 1] := minimum(deletionCost, insertionCost, substitutionCost)

// copy v1 (current row) to v0 (previous row) for next iteration swap v0 with
v1

// after the last swap, the results of v1 are now in v0 return v0[n]

**Data Involved -** For the testing of the kernel we will use lexicons from
the Moby Project [13].

##  Code Kernel “Directed Acyclic Graph Words Kernel” (DAWGK)

**Description -** DAWG constitutes the basic structure for vocabulary
handling. Dawg’s are directed graphs whose edges are labeled by symbols, and
they represent the set of all words "spelled" by its paths from the root to
the sink. Searching a DAWG for a word is very efficient and similar to
traversing a deterministic automaton to find a path. It is independent from
the size of the vocabulary (i.e. the size of DAWG) and depends only on the
length of the input word. The problem is when we search for similar words,
i.e. words with small distance from the input word. In that case, we have to
traverse many paths of the automaton in order to find the optimal (minimum
distance) alternatives. In that case, the DAWG is used as non-deterministic
automaton. Mnemosyne uses a modification of KMP (Knuth Morris Pratt) pattern
matching algorithm as base of the correction functionality (fuzzy matching)
for the most of the lexicon engines it has.

In this kernel we will implement parallel versions of the search engines that
Mnemosyne uses, incorporating algorithms as BNDM [14].

##  Code Kernel “TFIDFK”

**Description -** TFIDF [9] is another pattern matching technology used in
Mnemosyne. It belongs to the statistical matching algorithms and can also be
used as classification and clustering mechanism. Mnemosyne uses two
alternatives of the statistical approximate matching algorithms (TFIDF and
BM25). These algorithms can be applied between texts consisting of one to few
words to large documents with thousands of words. The strings compared are
called documents and the basic entity compared is the word. In case that the
documents consists of one or few words, Mnemosyne can also use q-grams as the
basic entity of indexing and comparing, q can be 2, 3 or 4. A parallel version
of the algorithm that will be implemented in the kernel, presented below:

**procedure** TFIDF(documents[0..n−1]) { // term frequency per document
associative_container ( string−> **int** ) term_freq[n ];

// document freq. and ID associative_container ( string −> ( **int** , **int**
)) doc_freq ;

**parallel_for** ( i : 0.. n−1) {

// Calculate term frequency in i−th document **parallel_for** (term :
documents[i]) modify(term_freq [ i ], term,+,1)

// Update document frequencies for term in i−th document

// Increment counter for each term ignoring term frequency

// Value of ID is irrelevant at this time

merge(doc_freq, term_freq [ i ], f =(k,( dfl , idl ), tfr )−>(k,(dfl+1,idl )),
g=(k, tfr )−>(k,(1,0)))

}

// Assign unique IDs to each term. The terms can be optionally

// sorted alphabetically . Sorting here affects the order of // terms in the
TF−IDF matrix and output.

// Store IDs in second element of value pair in doc_freq .
sort−by−key(doc_freq) ID = 0; **parallel_for** (term : doc_freq ) {
modify(doc_freq , term, f =((tf , old_ID ), ID)−>(tf,ID))

ID += 1

}

// Construct TF−IDF (sparse) matrix **parallel_for** ( i : 0.. n−1) { **for**
((term, tf ) : term_freq [ i ]) {

// Calculate TF−IDF score for term in i−th document

(df , id ) := lookup(doc_freq , term) tfidf [ i , id ] := tf  log ((
df+1)/(n+1))

}

}

**return** tfidf

}

##  Code Kernel “Best Match Kernel” (BM25K)

**Description -** This kernel will be a parallel version the Okapi BM25
algorithm which is a variation of the TFIDF algorithm. It is mostly used in
query processing systems where the system must return a set of most relevant
documents with the query (document). The kernel will follow the same
characteristics with the previous ones. The dictionary which constitutes the
indexed documents will be loaded in the kernel memory and the queries will be
streamed to the kernel. The kernel will respond with a ranking set of relevant
document ids.

There are many implementations of this algorithm using acceleration in GPU.
Below, we provide links to two example implementations:

_https://link.springer.com/chapter/10.1007%2F978-3-319-64471-4_10_
_http://nbjl.nankai.edu.cn/Lab_Papers/2017/ICPADS2017.pdf_

We will investigate/experiment with these implementations and we will choose
the most appropriate for usage in Mnemosyne.

##  Code Kernel “Compressed Tries Kernel” (CTK)

**Description -** Compressed Tries or C-Tries are used as index structures for
more complex dictionary types such as morphological, terminological, thesaurus
etc. They are also used as the basis for storing the compiled form of Kanon
rules. This kernel will be a parallel implementation of approximate searching
on C-Tries. Mnemosyne uses a modified KMP (Knuth Morris Pratt) algorithm to
search C-Tries in order to find similar terms.

Trie or digital tree [11] is a tree type used as index structure when keys are
strings. Nodes of the tree have edges labeled with characters from the
alphabet. This way searching of a string of length M needs M node visits in
order to either find the indexed object or to return failure. C-trie optimizes
the space needed by each node by using a bit mask of the alphabet used and a
length member of the number of children (nodes of the next level) from the
left siblings of the current node.

The kernel will follow the same architecture with the previous ones, i.e. it
will load the dictionary data in memory and will be streamed with keys
(strings) that will be checked in the dictionary. The kernel will reply with
the ID (a number) of the object having the key. In case that the key is not
stored in the dictionary, the kernel will reply with a set of approximate keys
with the distances from the input key.

**Data Involved -** The kernel will be tested with a modified version of a
morphological Greek dictionary developed by Neurolingo [15].

#  Green Buildings Use Case

##  Description of Use Case and Requirements

The SparkWorks IoT Framework cloud platform is designed to enable an easy and
fast implementation of applications that utilize an Internet-of-Things
infrastructure. It offers high scalability in terms of users, number of
connected devices and volume of data processed. The platform accommodates
real-time processing of information collected from mobile sensors and
smartphones and offers fast analytic services. The Cloud Services offer real
time processing and analysis of unlimited IoT data streams with minimal delay
and processing costs. In its current deployment, over 400MB of data are
produced daily, resulting in a yearly data volume of approximately 140GB.
However, the current setup uses averaging to minimize the required storage
space. For obtaining near real-time information on the building status, it is
necessary to shorten the averaging period (now set to 5 minutes), an approach
that will lead to significant data volume increase. In this context, the
deployed IoT infrastructure will generate, handle, transfer and store a
tremendous amount of data, which cannot be processed in an efficient manner
using current platforms and techniques. SparkWorks will utilize the E2Data
stack for improving its IoT Platform in order to rapidly process the
constantly accumulated data and tackle the issues generated by thousands of
parallel deployments of sensors, each generating enormous data chunks that
need to be processed almost in real-time.

###  Description of the Framing Environment

The SparkWorks platform receives streaming data from multiple types of sensors
and provides real-time analytics over them. In general, the Sparks Engine is a
process engine which provides the analytics and a storage system which is used
for storing those results. The process engine receives events from multiple
sensors and executes aggregate operations on these events. The output of the
engine is stored at a storage system.

Sensors produce (periodically or asynchronously) events that are sent to the
Sparks Processing Engine via RabbitMQ. Those events are usually tuples of
values: value and timestamp. All data received are collected and forwarded to
a queue. From there, they get processed in real time by an Apache Storm
cluster. The Storm cluster has a number of topologies for processing based on
the data type. Each topology is responsible for a unique type of sensor such
as general measurement sensors (temperature, humidity, wind speed etc.), power
measurement sensors, etc. The produced analytics are outputted into summaries
which are stored permanently to a NoSQL (MongoDB) database. The process engine
is composed by topologies for every type of sensor. Each topology has the
ability to be easily modified in order to accommodate aggregation operations.
The engine, which is implemented with Apache Storm, consists topologies. As
already mentioned above, each topology is responsible for a specific type of
sensor and consists a chain of aggregators which we call process blocks or
process levels. The process blocks can aggregate data for specific time
intervals. Events which enter the Storm cluster are processed consecutively.
First, the Storm topology performs aggregation operations on the streaming
data i.e., for a temperature sensor; Storm calculates the average values of
the 5-min-interval and stores them to memory and disk for further processing
(when the topology receives more than one events for the same 5-min-interval,
it calculates the average of those events). Every consecutive 5-min-interval
aggregate is kept in memory (topology keeps 48 interval values ‘k’ for 5-min,
hour, day, month intervals for each device) or stored in disk. The next step
is to update the hour intervals. For that reason, the topology updates the
5-min-intervals inside the buffer of the hour processor and stores the average
of those 5min-intervals.

The process is the same for the daily processor but the topology also stores
the max/min of the day (based on the hour intervals) and the same for monthly
and yearly processors. For power consumption sensors, the scheme (topologies
inside storm) is the same with the difference that the topology has to
calculate and store the power consumption.

**Aggregators** are used to perform aggregation operations on input streaming
data.

The topologies use aggregation for **Power Consumption calculation**
(calculate the power consumption of the stream values), **Sum calculation**
(summarize the streaming values) and **Average Calculation** (calculate the
average of the streaming values).

_**F** _

_**IGURE** _

_**2:** _

_**A** _

_**G** _

_**GREGATION** _

_**TOPOLOGY** _

1.1.1.

High Level Specification

The high level indicators that need to be achieved are:

  1. _Execution time_ : 50% reduction in execution time in metadata categorization process time and query response time. 

  

  2. _Computational resources_ : 70% reduction of computational resources needed to perform Big Data processing with respect to homogeneous scale-out approach. 

  

  3. _Data volume_ : 40% reduction of data volume traverse between Network Edge and Big Data processing tool based on dynamic information regarding resource availability provided by E2Data’s GUI. 

  

  

###  List of Critical Code Parts

The list of kernels which are candidates to accelerate are enumerated in the
Table below:  
  
<table>  
<tr>  
<th>

**Title**

</th>  
<th>

**Description**

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

1\. **compute sum**

</td>  
<td>

Computes the sum of the sensor measurements.

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

2\. **compute max**

</td>  
<td>

Computes the max of the sensor measurements.

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

3\. **compute min**

</td>  
<td>

Computes the min of the sensor measurements.

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

4\. **compute average**

</td>  
<td>

Computes the average of the sensor measurements.

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

##  Code Kernel “compute sum”

**Description -** Returns the summary of the readings stored until a requested
index arrives.

Method signature: getTotal(int until)

Input (int): the index until which summary will be computed

Output (double): the computed summary value

####  Data involved

  * Type / Structure: Array of Double 

  

  * Data source: Stream 

  

  * Volume: Up to hundreds of events 

  

  * Rate: up to 1 event/30 secs 

  

  * How accessed: AMQP 

  

**Code-level SLA –** We need to achieve:

####  Latency: 0,373 ms

**Throughput:** 5833,33 events/sec

**Critical to accelerate -** This method is crucial for the efficient
operation of the SparkWorks analytics engine since it contains the computation
of analytics results and is invoked every time a new sensor reading arrives on
the system.

**About the code –** It is implemented in Java, utilizing the Apache Storm
stream engine.

##  Code Kernel “compute max”

**Description -** Returns the maximum value of the readings stored until a
requested index.

Method signature: getMax(int until)

Input (int): the index until which maximum value will be computed

Output (double): the computed maximum value

####  Data involved

  * Type / Structure: Array of Double 

  

  * Data source: Stream 

  

  * Volume: Up to hundreds of events 

  

  * Rate: up to 1 event/30 secs 

  

  * How accessed: AMQP 

  

**Code-level SLA –** We need to achieve:

####  Latency: 0,373 ms

**Throughput:** 5833,33 events/sec

**Critical to accelerate -** This method is crucial for the efficient
operation of the SparkWorks analytics engine since it contains the computation
of analytics results and is invoked every time a new sensor reading arrives on
the system.

**About the code –** It is implemented in Java, utilizing the Apache Storm
stream engine.

##  Code Kernel “compute min”

**Description -** Returns the minimum value of the readings stored until a
requested index.

Method signature: getMin(int until)

Input (int): the index until which minimum value will be computed

Output (double): the computed minimum value

####  Data involved

  * Type / Structure: Array of Double 

  

  * Data source: Stream 

  

  * Volume: Up to hundreds of events 

  

  * Rate: up to 1 event/30 secs 

  

  * How accessed: AMQP 

  

**Code-level SLA –** We need to achieve:

####  Latency: 0,373 ms

**Throughput:** 5833,33 events/sec

**Critical to accelerate -** This method is crucial for the efficient
operation of the SparkWorks analytics engine since it contains the computation
of analytics results and is invoked every time a new sensor reading arrives on
the system.

**About the code –** It is implemented in Java, utilizing the Apache Storm
stream engine.

##  Code Kernel “compute average”

**Description -** Returns the average value of the readings stored until a
requested index.

Method signature: getAvg(int until)

Input (int): the index until which average value will be computed

Output (double): the computed average value

####  Data involved

  * Type / Structure: Array of Double 

  

  * Data source: Stream 

  

  * Volume: Up to hundreds of events 

  

  * Rate: up to 1 event/30 secs 

  

  * How accessed: AMQP 

  

**Code-level SLA –** We need to achieve:

####  Latency: 0,373 ms

**Throughput:** 5833,33 events/sec

**Critical to accelerate -** This method is crucial for the efficient
operation of the SparkWorks analytics engine since it contains the computation
of analytics results and is invoked every time a new sensor reading arrives on
the system.

**About the code –** It is implemented in Java, utilizing the Apache Storm
stream engine.

#  Security Use Case

##  Description of Use Case and Requirements

The iProov cloud platform is a multi-tenant platform running on Microsoft
Azure. The General Data Protection Regulations (GDPR) define biometric
profiles as “Special Category Personal Data”. This, combined with the high-
value nature of the transactions the platform runs, which include the
authentication of users for the creation of European bank accounts in multiple
EU countries, as well as the automated issuing of Visa documents, results in
the requirement for a highly secure, as well as highly scalable and resilient
infrastructure. The current platform encompasses a number of clusters of both
CPU and GPU servers to provide both the scalability and reliability required.
Peak transaction volumes for one customer results in excess of 3Gb of image
data to be processed per second.

###  Description of the Framing Environment

The existing environment runs as a series of CPU and GPU clusters deployed in
Microsoft Azure [16], combined with a distributed (Netherlands, UK and Eire)
MongoDB [17] NoSQL database which holds account information, customer
information and biometric profiles.

The CPU and GPU clusters are configured similarly as follows:

  * Each Virtual machine runs either one (GPU Cluster) or more than one (CPU Cluster) docker [18] containers. 

  

  * Each docker container runs a single micro-service which is typically coordinated by python software. However, for performance reasons, the actual execution of the kernel will be either in compiled multi-threaded C/C++ on CPUs or C compiled to CUDA [19] to execute on a Nvidia GPUs. 

  

  * The docker containers are orchestrated by Kubernetes [20] to allow ease of management. 

  

  * Task distribution is carried out by Celery [21] running on a RabbitMQ AMQP infrastructure [22]. 

  

  * Due to the nature of the payload (images), the overhead of distribution over RabbitMQ is excessive so instead the images are encoded using Google Protobuf 2 [23] and are stored in an active Memcached cluster [24]. This allows any worker to load any image in < 1ms for negligible CPU cost. 

  

  * The entire infrastructure sits behind a pair of Active/Standby Pfsense [25] firewalls, as well as the Azure firewalls. This allows the introduction of both an Intrusion Detection System (IDS) on the Pfsense servers, as well as the use of HAPROXY [26] to allow load distribution at the edge of the network. 

  

###  List of Critical Code Parts

The list of kernels which are candidates to accelerate are enumerated in the
Table below:  
  
<table>  
<tr>  
<th>

**Title**

</th>  
<th>

**Description**

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

1\. **ColourMorph**

</td>  
<td>

This takes an array of RGB images containing faces together with a set of
feature location for the faces. Each image is individually ‘morphed’ to a
standard face which is returned.

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

2\. **PearsonR**

</td>  
<td>

This Kernel is required to carry out a large number of PearsonR calculations
in a very small time period.

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

##  Code Kernel ColourMorph

The kernel takes as input a series (n) of equal sized source RGB images loaded
from Memcached where the RBG uint8 images have been encoded by Protobuf 2.
Each image contains a single face. A set of landmarks for each image is also
read from Memcached.

The kernel also has a single reference image again complete with a set of
landmarks.

The value of each pixel in the reference image is set to that of the closest
pixel in each of the source images as described below.

####  Description

The feature points within the reference image are triangulated using Delauney
Triangulation [27] as an one-off exercise.

The location of each point within each triangle is geometrically calculated
relatively to the 3 - vertices of the surrounding triangle and stored.

For each pixel within the reference image:

\- For each colour channel for each input image:

The colour channel value for the corresponding pixel in the input image is
stored onto the reference image.This means that some pixels in the input image
may be used more than once whereas some may not be used at all depending on
the relative sizes of the images.

The output of the process is a uint8 array of (3n, w, h). Where: n is the
number of input images; w is the width of the reference image and h is the
height of the reference image.

####  Data Involved

\- The inputs are:

N x 3 channel uint8 RGB images.

A JSON array containing 68 feature points for each input image with each
feature represented as a uint8 coordinate pair.

A reference model

All transient data will be accessed from Memcached where the results will also
be stored. Static data such as the model, will be loaded once from disk and
then stored in memory.

**Code-level SLA –** We need to achieve:

####  ● Latency: <500ms

  * **Throughput:** 240 images per second with typical images size being 220x240x3 

  

  * **Execution Time:** <200ms for each set of 30 images 

  

**Programming Efficiency:** HIGH. This is one of the key benefits for this use
case which can be massively parallelized. The goal of this use case is to
reduce engineering effort for code optimization.

**Critical to accelerate -** Acceleration is needed as the cost, both
financial and in terms of resources, of processing this quantity of data is
high.

I/O can be a limiting factor. Significant work has been carried out to
optimize the efficiency of image load.

This process is an input to one of the Presentation Attack Detection (PAD)
defenses of the iProov system. It is critical it is completed for each
transaction or the transaction will fail.

Acceleration so far - Significant work has been put into optimizing this
function using hand crafted CUDA. This performs well but the cost in person
effort of implementation is high. This is currently run on GPU. It
parallelizes well and is a good candidate for both GPUs and Xeon Phis.

####  About the code -

  * Language: CUDA 

  

  * Libraries utilised: Memcached and Protobuf 2 for data loading. None for execution. 

  

**Hints on Parallelisation -** The calculation for every pixel of every colour
channel of every image can be carried out in parallel.

##  Code Kernel PearsonR

This kernel takes as input a JSON structure containing two two-dimensional
arrays. The first input is of shape (8192, 13) and the second of shape (4096,
13) with both input are of type float64. The kernel performs a PearsonR
calculation for every 13 value array in the first input against every 13 byte
array in the second input. Over 33 million (8192x4096) Pearson Correlation
Coefficient calculations are made.

**Description -** This kernel is very simple. It performs Pearson Correlation
Coefficient [28] calculations against arrays consisting of thirteen float64
numbers. The complexity is simply the number of calculations required and the
limited time available.

####  Data involved -

  * Input 1: An array of type Float64 and size (8192, 13) 

  

  * Input 2: An array of type Float64 and size (4096, 13) 

  

  * Output 3: An array of type Float64 and size (33554432, 2) 

  

**Code-level SLAs –** We need to achieve:

####  ● Latency: <500ms

  * **Throughput:** 8 batched of transactions per seconds 

  

  * **Execution Time:** <25ms for each set of 30 images 

  

**Programming Efficiency:** HIGH. This is one of the key benefits for this use
case which can be massively parallelized. It complements the first use case
which is image-based. The goal of this use case is to reduce engineering
effort for code optimization.

#  Generic Data Management Plan

Results of the project action includes scientific publications, data research
results and datasets that are available for processing and experimentation.
The Data Management Plan and the relevant principles are set in the project,
in order to assure access, respect to personal data, re-usability, sharing,
archiving and presentation. A common framework is set by the project that is
to be instantiated by each use case. Main pillars of the plan include:

  * Open access to scientific publications; 

  

  * Open access to research data; 

  

  * Standards and metadata; 

  

  * Data access; 

  

  * Access and sharing policies; 

  

  * Re-usability and distribution; 

  

  * Archiving and presentation. 

  

##  Open Access to Scientific Applications

Scientific publications will be given open access; that is free of charge
online access for users. Open access will be achieved through the following
steps:

  1. Any paper presenting project results will acknowledge the Action: “ _The research leading to these results has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 780245-E2Data_ ” and display the EU emblem. 

  

  2. Any paper presenting results will be deposited at least by the time of publication to a formal repository for scientific papers. If the organisation does not support a formal repository [29], the paper can be uploaded in the European sponsored repository for scientific papers Zenodo [30]. 

  

  3. Authors can choose to pay “author processing charges” to ensure open access publishing, but still they have to deposit the paper in a formal repository for scientific papers (step 2). 

  

  4. Authors will ensure open access via the repository to the bibliographic metadata identifying the deposited publication. More specifically, the following will be included: 

     * The terms “ _European Union (EU)_ ” and “ _Horizon 2020_ ”; 

  

     * “ _E2Data – European Extreme Performing Big Data Stacks_ ”, Grant agreement number 780245; 

  

     * Publication data, length of embargo period if applicable; and 

  

     * A persistent identifier. 

  

  

  5. Each case will be examined separately in order to decide on self-archiving or paying for open access publishing. 

  

  

##  Open Access to Research Data

Open access to research data refers to the right to access and re-use digital
research data generated by project actions. Management and sharing of research
aims to maximise opportunities for future research and comply with best
practices in the relevant subject domain. That is:

  * The dataset has clear scope for wider research use; 

  

  * The dataset is likely to have long-term value for research or other purposes; ● The dataset has broad utility for reference and use by research communities; 

  

  * The dataset represents a significant output of the research project. 

  

Openly accessible research data generated during E2Data will be accessed,
mined, exploited, reproduced and disseminated free of charge for the user.
Specifically, the " _Guidelines on Data Management in Horizon 2020_ "
clarifies that the beneficiaries must:

_“Deposit in a research data repository and take measures to make it possible
for third parties to access, mine, exploit, reproduce and disseminate — free
of charge for any user — the following:_

i. _The data, including associated metadata, needed to validate the results
presented in scientific publications as soon as possible;_ ii. _Other data,
including associated metadata.”_

The datasets to provide will be described and be updated as they might change
with the evolution of the project, within future versions of this current
document. For each dataset that we are going to share in the project’s
lifetime, policies for access and sharing, as well as policies for re-use and
distribution, will be defined and applied. A generic guideline is provided in
Sections 6.4 " _Policies for Data Sharing and Access_ ", Section 6.5 “
_Policies for Re-Use and Distribution”_ and Section 6.6 " _Archiving and
preservation_ ".

##  Standards and Metadata

**Metadata** is needed on the datasets. This will provide transparency and
traceability to make security and audit possible. Such data can include
timestamps for various actions on data (generation, exchange, modification),
ownership, log access and action details, identifiers, etc.

**Standards** can be selected to help the data exchange, but the variation in
the employed systems across Europe is very large and there will be hundreds of
standards and even large variations within the same standards and/or versions
of these. Datasets should be as standardized, if possible, but the exchange of
data will be very hard by using defined standards.

To use standards, you do not only need to invent new or develop current
standards but implement them into the actual systems which is a very difficult
task. The reason for this is that you do not only need the technological
support, but you also really need to make it happen. It is a rare thing that
an organisation can adapt to a new standard with an existing system since that
system will likely be integrated with other systems. Also, the
systems/organisations asking others to adapt to a standard will not have the
budget or the governance in the other organisation. Experience shows that you
need to be able to handle a multitude of standards, if you want to integrate a
large number of systems and E2Data is aiming to potentially integrate a very
large number of systems.

A standard for integrating to E2Data should be defined, but it is a must that
it can co-exist with current standards and interfaces in the system. Even on a
European level, it is hard to imagine all countries moving at the same pace.

##  Policies for Data Sharing and Access

The data sharing policy is an ongoing process and is expected to be finalised
later in the course of the project as it closely related to the definition and
the requirements of the E2Data use cases. The issues identified so far
concern:

  * The definition of data owner(s); 

  

  * The definition of incentives concerning the data providers; 

  

  * The identification of user groups and the access policies concerning the data; 

  

  * The definition of access procedures and embargo periods; 

  

  * The compliance with corresponding legal and ethical issues. 

  

Open access to research data will be achieved in E2Data through the following
steps:

  1. Prepare the " _Data Management Plan_ " (current document) and update it as needed; 

  

  2. Select what data we will need to retain to support validation of the project findings ; 

  

  3. Deposit the research data into an online research data repository. While deciding where to store project data, the following choices will be performed, in order of priority: 

     * An institutional research data repository, if available; 

  

     * An external data archive or repository already established in the E2Data research domain 

  

  

  

(to preserve the data according to recognised standards);

  * The European sponsored repository:  _http://zenodo.org/_ ; 

  

  * Other data repositories (searchable here:  _http://www.re3data.org_ )  , if the aforementioned ones are ineligible. 

  

  4. License the data for re-use (Horizon 2020 recommendation is to use CC0 or CC BY); 

  

  5. Provide information on the tools needed for validation, i.e. everything that could help a third party in validating the data (workflow, code, etc.). Independent of the selected repository, the authors will ensure that the repository: 

     * Gives the submitted dataset a persistent and unique identifier to make sure that research outputs in disparate repositories can be linked back to particular researchers and grants; 

  

     * Provides a landing page for each dataset, with metadata; 

  

     * Helps track if the data has been used by providing access and download statistics; 

  

     * Keeps the data available in the long term, if desired; 

  

     * Provides guidance on how to cite the data that has been deposited. 

  

  

  

Even following the previously described steps, each case will be examined
separately in order to select the most suitable online repository.

As suggested by the European Commission, the partners will deposit at the same
time the research data needed to validate the results presented in the
deposited scientific publications. This timescale applies for data
underpinning the publication and results presented _._ Research papers written
and published during the funding period will be made available with a subset
of the data necessary to verify the research findings. The consortium will
then make a newer, complete version of the data, available within 6 months of
Action completion. This embargo period is requested to allow time for
additional analysis and further publication of research findings to be
performed.

Other data (not underpinning the publication) will be shared during the
project’s lifetime following a granular approach to data sharing and releasing
subsets of data at distinct periods rather than waiting until the end of the
Action, in order to obtain feedback from the user community and refine it as
necessary.

An important aspect to take into account is who is allowed to access the data.
It could be the case that part of a dataset should not be publicly accessible
to everyone. In this case, control mechanisms will be established, including:

  * Authentication systems that limit read access to authorised users only; 

  

  * Procedures to monitor and evaluate access requests one by one. A user must complete a request form stating the purpose for which they intend to use the data; 

  

  * Adoption of a Data Transfer Agreement that outlines conditions for access and use of the data. 

  

Each time a new dataset will be deposited, the consortium will decide who is
allowed to access the data. Generally speaking, anonymised and aggregate data
will be made freely available to everyone, whereas sensitive and confidential
data will only be accessed by specific authorised users.

##  Policies for Re-Use and Distribution

A key aspect of data management is to define policies in order for users to
learn the existence of data and the content it contains. People will not be
interested in a set of unlabeled files published on a website. To attract
interest, partners will describe accurately the content of published datasets
and, each time a new dataset is deposited, disseminate the information using
the appropriate means (i.e., mailing list, press release, Facebook, website
news) based on the type of data and the interested target audience.

Research data will be made available in a way that can be shared and easily
re-used by others. That means:

  1. Sharing data using open file format (whenever possible), so that they can be processed by both proprietary and open source software; 

  

  2. Using formats based on an underlying open standard; 

  

  3. Using formats which are interoperable among diverse internal and external platforms and applications; 

  

  4. Using formats which do not contain proprietary extensions (whenever possible). 

  

  

Documenting datasets, data sources and the methodology used for acquiring the
data establishes the basis for the interpretation and appropriate usage of the
data. Each generated/collected and deposited dataset will include
documentation to help users to re-use it.

As recommended, the license that will be applied to the data is CC0 or CC BY.
If limitations exist for the generated data, these restrictions will be
clearly described and justified.

Potential issues that could affect how data can be shared and used may include
the need to protect participant confidentiality, comply with informed consent
agreement, protect Intellectual Property Rights, submit patent applications
and protect commercial confidentiality. Possible measures that may be applied
to address these issues include encryption of data during storage and
transfer, anonymisation of personal information, development of Data Transfer
Agreements that specify how data may be used by an end user, specification of
embargo periods, and development of procedures and systems to limit access to
authorised users only.

##  Archiving and Presentation

Datasets will be maintained for 5 years following project completion. To
ensure high-quality long-term management and maintenance of the dataset, the
consortium will implement procedures to protect information over time. These
procedures will permit a broad range of users to easily obtain, share and
properly interpret both active and archived information and they will ensure
that information is:

  * Kept up-to-date in content and format so that they remain easily accessible and usable; 

  

  * Protected from catastrophic events (e.g., fire and flood), user error, hardware failure, software failure or corruption, security breaches, and vandalism. 

  

Regarding the second aspect, solutions dealing with disaster risk management
and recovery, as well as with regular backups of data and off-site storage of
backup sets, are always integrated when using the official data repositories
(i.e., Zenodo [30]); the partners will ensure the adoption of similar
solutions when choosing an institutional research data repository.

Partners are encouraged to claim costs for resources necessary to manage and
share data; these will be clearly described and justified. Arrangements for
post-action data management and sharing must be made during the life of the
Action. Costs associated with long-term curation and preservation, such as
POSF (Pay Once, Store Forever) storage, will be purchased before the Action
ends.

#  Conclusions

The use case providers (EXUS, Neurocom Luxembourg, iProov and SParkWorks/CTI)
do present an interesting set of code kernels that will be exercised. It
includes

  * a matrix inversion algorithm 

  

  * an algorithm for lexicographical approximate matching in vocabularies using distances between words 

  

  * approximate Matching in dictionaries stored as Directed Acyclic Graph Words 

  

  * cosine similarity applied on words or q-grams and a variation of the algorithm in order to rank documents 

  

  * fuzzy Matching of terms in terminological dictionaries stored in Compressed Tries ● computing the sum / maximum / minimum / average of sensor measurements. 

  

  * carrying out a large number of PearsonR correlation coefficient calculations in a very small time period. 

  

  * algorithm that takes an array of RGB images containing faces together with a set of feature location for the faces, and ‘morphs’ each individual image to a standard face which is finally returned. 

  

The description of the code kernels have given significant feedback to the
core development team that need to advance the E2DATA architecture to address
the requirements. Computations are featuring different performance behavior
and computation profiles. Some are better on GPUs rather than FPGAs and the
opposite. During the identification of certain case requirements, code
examples have been provided for experimentation, setting well defined targets.
The accomplished work triggered the desirable and valuable collaboration among
the use cases and the E2data core development teams.

Apart from the application use case context, the project sets a Data
Management Plan that aims to assure access, respect to personal data, re-
usability, sharing, archiving and presentation. A common framework is set by
the project which will sufficiently guide each use case, into treating each
dataset, in respect to the following:

  * Open access to scientific publications; 

  

  * Open access to research data; 

  

  * Standards and metadata; 

  

  * Data access; 

  

  * Access and sharing policies; 

  

  * Re-usability and distribution; ● Archiving and presentation.