**Executive summary**

EW-Shopp aims at supporting companies operating in the fragmented European
ecosystem of the eCommerce, Retail and Marketing industries to increase their
efficiency and competitiveness by leveraging deep customer insights that are
too challenging for them to obtain today. The integration of public and
private data collected by different business partners will ensure to cover
customer interactions and activities across different channels, providing
insights on rich customer journeys. These integrated data will be further
enriched with information about weather and events, two crucial factors
impacting consumer choices. To realize these objectives, a platform, also
referred to as EW-Shopp platform, will be built.

The Data Management Plan (DMP) reports on the data that EW-Shopp project will
use and generate during its life, from the set up of the EW-Shopp Platform to
the business exploitation of its services.

The deliverable, following the Horizon 2020 guidelines  1  , defines the
general approach that will be adopted in the context of EW-Shopp project in
terms of data management policies. In accordance with these Guidelines, this
deliverable will include information about the handling of data during and
after the end of the project, reserving a particular attention to the
methodology and standards to be applied.

In addition to the guidelines provided by the European Commission, this
document also refers to the plan to address the legal and ethical issues
related to data that will be collected, in close collaboration with the
activities undertaken by the EW-Shopp Ethics Advisory Board and the main
outcomes from WP7.

The deliverable describes the approach established in EW-Shopp to ensure the
life-cycle management of the public and proprietary datasets provided by the
consortium members to the project as well as other dataset produced by the
Consortium during the project execution.

In particular, this report describes rules, best practices and standards used
with regard to make the data findable, accessible, interoperable and reusable
(FAIR data) and the process to collect and manage data in compliance with
ethical and legal requirements. The deliverable includes a high-level
description of the four business cases (BC1: Bing Bang, Ceneje, and Browsetel;
BC2: GfK, BC3: Measurence; BC4: Jot Internet Media) and descriptions of the
datasets provided for EW-Shopp project, which aim to detail identification,
origin, format, access, security of the data and to take into account legal
and ethics requirements.

**Chapter 1**

**Introduction**

According to the Guidelines on FAIR Data Management in Horizon 2020, Data
Management Plan (DMP) is a key element of good data management. A DMP
describes the data management life cycle for the data to be collected,
processed and/or generated by a Horizon 2020 project.

This document will set-up a DMP in accordance with H2020 Guidelines, including
information and suggestions about the handling of data during and after the
end of the project, what data will be collected, processed and/or generated,
which methodology and standards will be applied, whether data will be
shared/made open access and how data will be curated and preserved (including
after the end of the project).

In addition to the guidelines provided by the European Commission, this
document also refers to the plan to address the legal and ethical issues
related to data that will be collected.

The deliverable describes the approach established in EW-Shopp to ensure the
life-cycle management of the public and proprietary datasets provided by the
consortium members to the project as well as other dataset produced by the
Consortium during the project execution, as defined at M6.

In chapter 1 the document defines which are the principles underlying EW-Shopp
DMP, the approach followed to generate the structure, the main contents of the
document and links to the other deliverables and documents. In chapter 2, the
document introduces the EW-Shopp project, its purpose, the kind of dataset
involved in the project, the audience and the responsibilities defined around
the DMP. Chapter 3 introduces core concepts and fundamental legal principles
as well outlines an ethical assessment for data owner and, concerning legal
requirements, provides detailed guidelines about the obligations that data
owners need to comply with. In Chapter 4, a high-level description of the four
business cases is reported in order to give an overall view of the project
scope. In Chapter 5, relevant information regarding the dataset are explained
and the process to collect all the information among data owners is described.
Chapter 6 shows, for each dataset, all the information required for dataset
identification, origin, format, access, security and with respect to ethical
and legal requirements. Data storage policies, data archiving, security,
permission, data access, re-use and licensing are discussed in chapter 7.

Finally, the survey that was submitted to all dataset providers is reported in
Annex A.  
  
<table>  
<tr>  
<th>

**1.1**

</th>  
<th>

**Principles underlying EW-Shopp DMP**

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

The EW-Shopp project aims at deploying and hosting a platform to ease data
integration tasks, by embedding shared data models, robust data management
techniques and semantic reconciliation methods. This platform will offer a
framework for unification of fragmented business data and its integration with
external event and weather data, which will support data analytics services
that offer key competitive advantages in the modern commerce space.

In general, research data should be 'FAIR', that is findable, accessible,
interoperable and re-usable. These principles precede implementation choices
and do not necessarily suggest any specific technology, standard, or
implementation-solution.

In this context, the Data Management Plan is a key activity and it will deepen
the general principles underlying EW-Shopp Data Management Plan (from [DoA]):

  * **EW-Shopp Privacy Policy:** We will set up and explicitly define a Privacy Policy adopted in the EW-Shopp project, with which all partners and data processing activities carried out in the project must comply. […] In case some PD is used in some intermediate data processing step, this information will be properly anonymized and used only upon consent to secondary use collected from the users. The EW-Shopp Privacy Policy will assure that data processing activities in EW-Shopp comply with national and EU legislation, including legislation on personal data protection. 

  

  * **Statistical data not containing PD:** The majority of datasets consist of statistical data (all dataset classified as not containing personal data in the data description tables). These data do not contain PD but only information treated at an aggregate level that cannot be linked back to single individuals. Therefore, the specific data subjects will be not visible/ recognizable in such sets of data. These data have been collected by business partners in their daily operations in compliance with national regulations, both in relation to privacy protection and informed consent to data processing. 

  

  * **Anonymization of data containing PD:** Other datasets are classified as containing personal data in the data description tables. These data will be anonymized before being used in the project so as to comply with the privacy protection policy and national and EU legislation. Among these datasets, we consider three notable cases, for which we specify how we plan to ensure privacy protection constraints. 

  

  
<table>  
<tr>  
<th>

**1.2**

</th>  
<th>

**General Approach**

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

The EW-Shopp DMP will be developed by taking into account the DMP template
that matches the demands and suggestions of the Guidelines on Data Management
in Horizon 2020, and that is available through the DMPonline platform  2  .

The principal contents indicated in the template are enlisted here below:

  * Dataset Description 

  

  * Fair data (making data findable, accessible, interoperable and reusable) 

  

  * Data security 

  

  * Data archiving and preservation 

  

  * Ethics and aspects 

  

These contents were utilized as a guide and then the document was customized
according to specific study requirements.  
  
<table>  
<tr>  
<th>

**1.3**

</th>  
<th>

**Applicable documents and references**

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

The following documents are applicable to the subject discussed in this
deliverable, and will be referenced as indicated into round brackets:

  1. EW-Shopp – Grant Agreement number 732590 ( [GA] ) 

  

  2. [GA] Annex 1 – Description of the Action ( [DoA] ) 

  

  3. EW-Shopp – Consortium Agreement ( [CA] ) 

  

  4. D7.2 POPD-Requirement No.2 ( [D7.2] ) 

  

  

Short references may be used to refer to project beneficiaries, also
frequently referred to as _partners_ . References are listed in Table 2.

#  Table 2. Short references for project partners  
  
<table>  
<tr>  
<th>

**No.**

</th>  
<th>

**Beneficiary (partner) name as in [GA]**

</th>  
<th>

**Short reference**

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

1

</td>  
<td>

UNIVERSITA’ DEGLI STUDI DI MILANO-BICOCCA

</td>  
<td>

UNIMIB

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

2

</td>  
<td>

CENEJE DRUZBA ZA TRGOVINO IN POSLOVNO SVETOVANJE DOO

</td>  
<td>

CE

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

3

</td>  
<td>

BROWSETEL (UK) LIMITED

</td>  
<td>

BT

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

4

</td>  
<td>

GFK EURISKO SRL.

</td>  
<td>

GFK

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

5

</td>  
<td>

BIG BANG, TRGOVINA IN STORITVE, DOO

</td>  
<td>

BB

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

6

</td>  
<td>

MEASURENCE LIMITED

</td>  
<td>

ME

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

7

</td>  
<td>

JOT INTERNET MEDIA ESPAÑA SL

</td>  
<td>

JOT

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

8

</td>  
<td>

ENGINEERING – INGEGNERIA INFORMATICA SPA

</td>  
<td>

ENG

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

9

</td>  
<td>

STIFTELSEN SINTEF

</td>  
<td>

SINTEF

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

10

</td>  
<td>

INSTITUT JOZEF STEFAN

</td>  
<td>

JSI

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

**1.4**

</td>  
<td>

**Updates of this deliverable**

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

This deliverable will be updated, over the course of the project, whenever
significant changes arise, to ensure compliance with Horizon 2020 guidelines.
Among these changes it is possible to list: new datasets that will be added,
changes in consortium policies or changes in consortium composition and
external factors.

**Chapter 2 Project Data Management**  
  
<table>  
<tr>  
<th>

**2.1**

</th>  
<th>

**Project purposes**

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

EW-Shopp aims at supporting companies operating in the fragmented European
ecosystem of the eCommerce, Retail and Marketing industries to increase their
efficiency and competitiveness by leveraging deep customer insights that are
too challenging for them to obtain today.

Improved insights will result from the analysis of large amount of data,
acquired from different sources and sectors, and in multiple languages. The
integration of consumer and market data collected by different business
partners will ensure to cover customer interactions and activities across
different channels, providing insights on rich customer journeys. These
integrated data will be further enriched with information about weather and
events, two crucial factors impacting consumer choices.

By increasing the analytical power coming from the integration of cross-
sectorial and cross-language data sources and new data sources companies will
deploy real-time responsive services for digital marketing, reporting-style
services for market research, advanced data and resource management services
for Retail & eCommerce companies and their technology providers, and enhanced
location intelligence services. For example, by using a predictive model built
on top of integrated data about click-through rate of products, weather and
events, we will develop a service that is able to increase advertising of top-
gear sport equipment on a sunny weekend afternoon during Tour De France.

To realize these objectives, a platform, also referred to as EW-Shopp
platform, will be built. The platform will support:

  * The integration of consumer and market data, covering customer interactions across different channels and with different languages, and providing insights on rich customer journey 

  

  * The enrichment of the integrated data with information about weather and events 

  

  * The analysis of the enriched data using visual, descriptive and predictive analytics. 

  

  
<table>  
<tr>  
<th>

**2.2**

</th>  
<th>

**Project data**

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

EW-Shopp makes use of a mix of public and proprietary datasets. The broad
classes of data include the following:

  * Market data – data extracted from marketing research and commercial activity 

  

  * Consumer data – profiles from marketing research, e-commerce, digital advertising, and IoT devices 

  

  * Category/product data – data coming from commercial activities 

  

  * Events reported in media – popular online media data 

  

  * Weather data and forecasts 

  

The EW-Shopp platform will provide data services and tools to process and
harmonise data. It will produce a set of agreed data models, including a
shared system of entity identifiers to represent the aforementioned datasets.
The data will furthermore be represented in a way that provides support for
multiple input languages.  
  
<table>  
<tr>  
<th>

**2.3**

</th>  
<th>

**Audience**

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

Project data are oriented to:

  * The consortium partners; 

  

  * All stakeholders involved in the project; • The European Commission. 

  

Because of the sensitiveness of business data used in the EW-Shopp innovation
action, no commitment to publish datasets provided by business partners as
open data is made in [DoA]. For this reason, we do not include _external
stakeholders_ in the audience for project data. With _external stakeholders_
we refer to a party that: is not a beneficiary, is not a linked third party in
EW-Shopp, is not the European Commission. Although we do not expect to make
datasets openly accessible to external stakeholders, models and methodologies
developed in the project to support interoperability between different parties
will be disseminated to a larger audience of stakeholders.  
  
<table>  
<tr>  
<th>

**2.4**

</th>  
<th>

**Roles and responsibilities**

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

We describe main roles of beneficiaries in the consortium and their
responsibilities with regards to data and services developed in business cases
in Table 3. Roles and Responsibilities of Beneficiaries In the table with
refer to Business Cases with their number, which are further explained in
Chapter 4

.

In the table, we distinguish between two main __roles of beneficiaries in the
consortium_ _ :

  * **Business Partners:** partners that develop services within the project, by exploiting the technology developed in the project, i.e., the EW-Shopp platform, on their own data sets and/or with the help of data sets provided by other partners in the project. These partners will also contribute indirectly to the technology by driving its development with the specification coming from their business cases. 

  

  * **Technology partners:** partners whose main role in the project is to develop the technology that will support the EW-Shopp platform. These partners will also contribute indirectly to the business cases by performing the following activities: 

    * Providing or supporting access to core data sets, i.e., data sets such as product data, locations, weather and events, used to integrate and enrich business data. 

  

    * Supporting the development of pilots and services by helping business partners integrate or analyze the data. 

  

  

#  Table 3. Roles and Responsibilities of Beneficiaries  
  
<table>  
<tr>  
<th>

**Partner**

</th>  
<th>

**Partner Role**

</th>  
<th>

**Resp. wrt Data**

</th>  
<th>

</th>  
<th>

Resp. wrt Business Cases

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

Business

</th>  
<th>

**Tech.**

</th>  
<th>

Owner

</th>  
<th>

**Facilitator**

</th>  
<th>

**Service**

</th>  
<th>

Data

</th>  
<th>

Tech.

Support

(Integration)

</th>  
<th>

Tech.

Support

(Analytics)

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

UNIMIB

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

BC2, BC3

</td>  
<td>

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

CE

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

BC1

</td>  
<td>

BC1

</td>  
<td>

</td>  
<td>

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

BT

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

BC1

</td>  
<td>

BC1

</td>  
<td>

</td>  
<td>

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

GFK

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

BC2

</td>  
<td>

BC1,BC2

</td>  
<td>

</td>  
<td>

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

BB

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

BC1

</td>  
<td>

BC1

</td>  
<td>

</td>  
<td>

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

ME

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

BC3

</td>  
<td>

BC3

</td>  
<td>

</td>  
<td>

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

JOT

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

BC4

</td>  
<td>

BC4

</td>  
<td>

</td>  
<td>

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

ENG

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

BC4

</td>  
<td>

BCALL

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

SINTEF

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

BC1

</td>  
<td>

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

JSI

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

BCALL

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

At a general level, __responsibilities with respect to data_ _ managed in the
project can be summarized as follows:

  * **Data owner** , a partner that provides to the consortium data that it owns - **Data facilitator** , a partner that eases access to data that are: 

    * provided by beneficiaries (i.e., UNIMIB will support access to product data owned by 

  

  

GFK) o provided by linked third parties (i.e., JSI will provide access to
weather data provided by ECMWF)

  * available as open data (i.e., UNIMIB will provide access to relevant data about locations available in sources such as DBpedia  3  ) 

  

Partners may thus have different responsibilities with respect to development
of business cases and pilots (see Table 3 for the specification of the
responsibilities of individual beneficiaries in each business case):

  * **Service developer** (referred to as “Service” in the table) is a beneficiary that is responsible for developing a service within a business case. 

  

  * **Data provider** (referred to as “Data” in the table) is a beneficiary that is responsible for providing its data to support a business case. 

  

  * **Technical support (integration)** is a technical partner that is responsible for providing support in a business case by helping business partners in the data integration process. 

  

  * **Technical support (analytics)** is a technical partner that is responsible for providing support in a business case by helping business partners in the data analytic process. 

  

The assignment of business cases to technology partners may be subject to
change in the course of the project; Table 3 reports assignments that have
been used to collect requirements included in this document.

In addition to EW-Shopp beneficiaries, the project also include three two
parties having a role in the project:

  * **European Centre for Medium-Range Weather Forecasts** (ECMWF **)** is an independent intergovernmental organisation founded in 1975 and supported by 34 states ( _http://www.ecmwf.int_ ). Data from ECMWF are provided to the EW-Shopp project to be used by every partner. **ECMWF** will contribute in EW-Shopp by making available, for the scope of the project, its meteorological archive of forecasts (MARS) of the past 35 years and sets of reanalysis forecasts. 

  

  * **CDE** is a Slovene Ltd IT company providing IT solutions for communication and customer relation management linked to Browsetel (BT). CDE will act as a data and infrastructure provider and software development in the context of BC1 in WP4, while BT will focus on business development. Responsibilities of CDE in EW-Shopp are included in responsibilities of BT in Table 3. 

  

**Chapter 3 Ethics and Legal Compliance**  
  
<table>  
<tr>  
<th>

**3.1**

</th>  
<th>

**Legal requirements regarding personal data**

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

The EW-Shopp project must comply with all EU laws regarding data protection.
The purpose of this section is to explain core principles and concepts of the
right to **protection of personal data in scientific research** .  4

In the 1990s, the European Union started a process of codification of data
protection and privacy rights in order to harmonise different national
legislation. Directive 95/46/EC  5  (“Data Protection Directive”) and
Directive 2002/58/EC  6  (“E-Privacy Directive”) are the main legal provisions
that referred to define the legal framework, considering also the EU Charter
of Fundamental Rights  7  and the appropriate national legislation that
transposed these EU directives.

This multilevel legal environment is going to change in 2018, when in May a
new European Regulation comes into force.  8  Indeed, the General Data
Protection Regulation (GDPR) (Regulation (EU) 2016/679)  9  was approved, by
the EU Parliament, on 14 April 2016. It will enter in force 20 days after its
publication in the EU Official Journal and will be directly application in all
member states two years after this date. It is designed to harmonize data
privacy laws across Europe, to protect and empower all EU citizens' data
privacy and to reshape the way organizations across the region approach data
privacy.

Although the new Regulation confirms the main principles of both the above-
cited Directives, it will substitute them and all national legislation on data
protection and privacy rights.

**3.1.1 Core concepts**

European Data Protection legislation is based on some core concepts concerning
the subjects who are going to acquire, collect, process, profile, and use
data; the different types of data; and notification procedures. Below are
listed the most important definitions for scientific research activities.
These definitions have been extrapolated from EU legislation, EU and Member
State (MS) official documents, or other legal documents.

All text in italics is with respect to the new 2018 European regulation and
its additional requirements.

#  Table 4 Core concepts - European Data Protection legislation  
  
<table>  
<tr>  
<th>

**CORE CONCEPT**

</th>  
<th>

**Definition**

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

SUBJECTS IN DATA PROCESS

</td>  
<td>

**Data Controller** 10  : The natural or legal person, which alone or jointly
with others determines the purposes and means of the processing of personal
data.

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

**Data Processor** 11  : A natural or legal person, which processes personal
data on behalf of the controller.

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

DIFFERENT TYPES OF DATA

</td>  
<td>

**Personal Data** 12  : Any information relating to an identified or
identifiable natural person (“data subject”); an identifiable person is one
who can be identified, directly or indirectly, in particular, by reference to
an identification number, _location data, an online identifier_ or to one or
more factors specific to his physical, physiological, _genetic,_ _mental_ ,
_economic_ , _cultural_ or _social identity_ _of that natural person_ .
Personal data may be processed only if the data subject has unambiguously
given his consent (“prior consent”).

**NB: Anonymised data are no longer personal data. See below.**

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

**Sensitive (Personal) Data** 11  : Personal data revealing racial or ethnic
origin, political opinions, religious or philosophical beliefs, trade-union
membership, and the processing of _genetic data, biometric data for the
purpose of uniquely identifying a natural person,_ data concerning health _or
data concerning a natural person’s sex life or sexual orientation._ Sensitive
data may be processed only if the data subject has given his explicit consent
to the processing of those data (“prior written consent”).

**NB: Anonymised data are no longer personal data. See below.**

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

**Genetic Data** 14  : personal data relating to the inherited or acquired
genetic characteristics of a natural person which give unique

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

</th>  
<th>

information about the physiology or the health of that natural person and
which result, in particular, from an analysis of a biological sample from the
natural person in question.

**NB: Anonymised data are no longer personal data. See below.**

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

**Biometric Data** 12  : personal data resulting from specific technical
processing relating to the physical, physiological or behavioural
characteristics of a natural person, which allow or confirm the unique
identification of that natural person.

**NB: Anonymised data are no longer personal data. See below.**

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

**Anonymization** ( **Anonymised Data** )  13  : Processing of data with the
aim of removal of information that could lead to an individual being
identified. Data can be considered anonymised when it does not allow
identification of the individuals to whom it relates, and it is not possible
that any individual could be identified from the data by any further
processing of that data or by processing it together with other information
which is available or likely to be available. Use of anonymised data does not
require the consent of the “data subject.”

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

**Simulated Data** : Imitation or creation of data that closely matches real-
world data, but is not real world data. For these data, consent is not
necessary since it is not possible to identify the “data subject.”

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

</td>  
<td>

**Pseudonymization** 14  : The processing of personal data in such a manner
that the personal data can no longer be attributed to a specific data subject
without the use of additional information, provided that such additional
information is kept separately and is subject to technical and organisational
measures to ensure that the personal data are not attributed to an identified
or identifiable natural person.

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

**Big Data** 15  : High-volume, high-velocity, high-value and high-variety
information (4Vs) assets that demand innovative forms of information
processing.

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

</td>  
<td>

**Open Data** 16  : Data that can be freely used, re-used, and redistributed
by anyone – subject only, at most, to the requirement to attribute and share-
alike.

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

PROCESSES

</td>  
<td>

**Processing of Personal Data** 17  : Any operation (or set of operations)
that is performed upon personal data _or on sets of personal data_ , whether
or not by automated means, such as collection, recording, organization,
_structuring,_ storage, adaptation or alteration, retrieval, consultation,
use, disclosure by transmission, dissemination or otherwise making available,
alignment or combination, _restriction_ , erasure, or destruction.

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

**Profiling** 18  : Any form of automated processing of personal data
consisting of the use of personal data to evaluate certain personal aspects
relating to a natural person, in particular, to analyse or predict aspects
concerning that natural person’s performance at work, economic situation,
health, personal preferences, interests, reliability, behaviour, location, or
movements.

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

NOTIFICATION

</td>  
<td>

**Notification** : According to different national legislation, data
controllers have to notify their National Data Protection Authority (DPA) of
their intention to use data before starting to process data. Requirements,
notification processes, and conditions vary across national DPAs.

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

**3.1.2 Fundamental Principles**

European Data Protection legislation provides that personal data must be
collected, used, and processed fairly, stored safely, and not disclosed to any
other person unlawfully. From this perspective, we can outline the following
fundamental principles regarding personal data use  19  :

  1. Personal data must be obtained and processed **fairly, lawfully, and _in a transparent way_ ** 20  : according to EU and MS’s national legislation the data controller has to respect certain conditions, for example do the notification process before starting collecting personal data or obtain prior consent from the natural person (the “data subject”) before collecting his/her personal data; 

  

  2. Personal data should only be collected for **specified, explicit, and legitimate purposes** and not further processed in any way incompatible with those purposes: personal data must be collected for specific, clear, and lawfully stated purposes, which the data controller has to specify to the “data subject” and to the national Data Protection Authority (DPA); 

  

  3. Personal data should be used in an **adequate, relevant, and not excessive way** in relation to the purposes for which they are collected and/or further processed: processing of personal data should be compatible with the specified purposes for which it was obtained; 

  

  4. Keep personal data **accurate, complete** , and, where necessary, **up-to-date** ; 

  

  5. Keep personal data **safe and secure** : the data controller must assure adequate technical, organisational, and security measures to prevent unauthorised or unlawful processing, alteration, or loss of personal data; 

  

  6. **Retain** personal data for **no longer** than is necessary: personal data should not be kept for longer than is necessary for the purposes for which it was obtained; 

  

  7. **No transfer of personal data overseas** : it is prohibited to transfer personal data to any country outside of the European Union and European Economic Area. 

  

  

The new European Regulation has also added some other principles to correctly
manage privacy and data protection rights. These new principles provide as
follows:

  * Data Controller **accountability** : taking into account the nature, scope, context, purposes, and risks of processing, the Data Controller has to implement **appropriate technical and organisational measures** .  21 

  

  * **Principles of data protection by design and by default** 25  must be applied: 

    * **Privacy by design** 22  : The Data Controller, before starting collection and processing of personal data as well as during the processing itself (“the whole life cycle of data”), has to implement **appropriate technical and organisational measures** , such as pseudonymization, which are designed to implement data protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing. In other words, before starting “working” with personal data, _the entire process from the start has to be designed_ in compliance with the required technical and legal safeguards of data protection regulations (e.g. adequate security); 

  

    * **Privacy by default** : The Data Controller has to implement appropriate technical and organisational measures for **ensuring that, by default, only personal data that are necessary for _each specific purpose of the processing_ are processed ** .  23  More specifically “Privacy by design’s” (PbD) core concepts  28  are: 

  

  

  1. Being **proactive not reactive** , preventative not remedial: The “PbD approach is characterized 

  

  

by proactive rather than reactive measures. It anticipates and prevents
privacy invasive events before they happen. PbD does not wait for privacy
risks to materialize, nor does it offer remedies for resolving privacy
infractions once they have occurred — it aims to prevent them from occurring.
In short, Privacy by Design comes before-the-fact, not after”;

  2. Having **privacy as the default** setting: “PbD seeks to deliver the maximum degree of privacy by ensuring that personal data are automatically protected in any given IT system or business practice. If an individual does nothing, their privacy still remains intact. No action is required on the part of the individual to protect their privacy — it is built into the system, by default”; 

  

  3. Having **privacy embedded into design** : “PbD is embedded into the design and architecture of IT systems and business practices. It is not bolted on as an add-on, after the fact. The result is that privacy becomes an essential component of the core functionality being delivered. Privacy is integral to the system, without diminishing functionality”; 

  

  4. Avoiding the **pretence of false dichotomies** , such as privacy vs. security: “PbD seeks to accommodate all legitimate interests and objectives in a positive-sum win-win manner, not through a dated, zero-sum approach, where unnecessary trade-offs are made. PbD avoids the pretence of false dichotomies, such as privacy vs. security – demonstrating that it is possible to have both”; 

  

  5. Providing **full life-cycle management of data** : “PbD, having been embedded into the system prior to the first element of information being collected, extends securely throughout the entire lifecycle of the data involved — strong security measures are essential to privacy, from start to finish. This ensures that all data are securely retained, and then securely destroyed at the end of the process, in a timely fashion. Thus, PbD ensures cradle to grave, secure lifecycle management of information, end-to-end”; 

  

  6. Ensuring **visibility and transparency of data** : “PbD seeks to assure all stakeholders that whatever the business practice or technology involved, it is in fact, operating according to the stated promises and objectives, subject to independent verification. Its component parts and operations remain visible and transparent, to users and providers alike. Remember, trust but verify”; 

  

  7. Being **user-centric and respecting user privacy** : “PbD requires architects and operators to protect the interests of the individual by offering such measures as strong privacy defaults, appropriate notice, and empowering user-friendly options. Keep it user-centric”. 

  

  

**3.1.3 Notification process and data protection impact assessment**

Generally, every data controller has to notify its national Data Protection
Authority (DPA) of its decision to start collection of personal data before
starting this process. This notification aims at communicating in advance the
creation of a new “database,” explaining the reasons for and purposes of this,
and the technical and organisational safeguards in place to protect the
personal data. Consequently, DPAs are enabled to verify the legal and
technical safeguards required by EU legislation. However, the conditions
attaching to and the procedures for submitting such a notification differ from
EU state to EU state, with the strongest protections in place in Germany and
the Netherlands and the least in Ireland and the UK.

The **new European Regulation** will introduce a different way to manage data
protection issues, following PbD principles, however _. Each Data Controller
has to carry o_ ut an assessment of the impact of processing operations on the
protection of personal data before starting the processing itself to evaluate
the origin, nature, particularity, and severity of risk  24  attaching to
their proposed processing. Such Data Protection/Privacy Impact Assessments
(DPIA) can then be utilised to define appropriate measures to assure data
protection and compliance with EU legislation.

A DPIA is required in case of:

  * Systematic and extensive evaluation of personal aspects in automated processing (e.g. profiling); 

  

  * Processing on a large scale of sensitive data or of personal data relating to criminal convictions and offences; 

  

  * Systematic monitoring of a publicly accessible area on a large scale. 

  

The main aspects of DPIAs are:

  1. Systematic description of processing operations and the purposes of the processing; 

  

  2. Assessment of the necessity and proportionality of the processing operations in relation to the purposes; 

  

  3. Assessment of the risks to the rights and freedoms of data subjects; 

  

  4. Measures to deal with the risks, including safeguards, security measures, and mechanisms to ensure data protection and to demonstrate compliance with EU legislation. 

  

  

In the event that a DPIA indicates a high risk in terms of data protection and
privacy rights, the Data Controller must consult the National Data Protection
Authority prior to the processing.  30

**3.1.4 Notification process in EW-Shopp project**

The use of dataset within EW-Shopp project have to comply with applicable
international, EU and national law (in particular, EU Directive 95/46/EC).

To this aim, data owners have been asked to evaluate each of their dataset in
order to confirm the nature and sensitivity of data to be used within EW-Shopp
project.

In order to make this evaluation, dataset owners, for each dataset, have to
clarify if their own dataset contains PD. If the dataset contains PD, they
have to provide _notification_ and _informed consent for secondary use_ .

If the dataset, to be used for EW-Shopp project, does not contain PD, it is
needed to clarify if it is derived from a dataset which contains PD. If the
dataset derives from a dataset which contains PD, the data owner should
prepare a statement which explains that he will not use data produced in the
project to enrich dataset containing PD for DMP aims and provide also the
notification with the EC regarding the original dataset which contains PD to
be included in deliverable [D7.2].

If the dataset does not contain PD (or derives from a dataset does not contain
PD), the data owner should provide a statement, which details that his own
dataset does not contain PD (explaining the implemented procedures, etc.).

All the notifications and copy of opinions performed by owners of dataset,
which contains PD will be collected in deliverable [D7.2].  
  
<table>  
<tr>  
<th>

**3.2**

</th>  
<th>

**Ethics requirements regarding the involvement of human rights**

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

The EW-Shopp project is implemented considering fundamental ethical standards
to ensure the quality and excellence in the process and after the life of the
project. In the Horizon 2020 it is specified that Ethical research conduct
implies the application of fundamental ethical principles and legislation to
scientific research in all possible domains of research. According to the
procedure established in the Horizon 2020 in terms of Ethics, in order to
achieve the engagement of the scientific research with the ethical dimension,
in EW-Shopp project each BC owner has been asked to answer the following
questions:

  * Are there any ethical issues that can have an impact on data sharing? 

  

  * Have you taken the necessary measures to protect the humans’ rights and freedoms? 

  

  * How did/could these measures impact the BC? 

  

  * Do you assess the risks linked to the specific type of data your organization provides? 

  

  
<table>  
<tr>  
<th>

**3.3**

</th>  
<th>

**Intellectual Property Rights**

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

In the context of EW-Shopp project, the IPR ownership is fundamentally
regulated by the underlying principles of two main official documents (namely
[CA] and [GA]), but further considerations will be detailed within WP5 frame
and provided in its outcome “D5.4 – Update of Exploitation and Dissemination
Strategy (M24)”.

Two main concerns on IPR management could impact the current deliverable:

  * Existing or developed datasets will be available to the whole Consortium during the project timespan, but any further use in exploitation activities must follow specific limitations and/or conditions (as stated in Article 25.3 of the [GA] and described in its Attachment 1). 

  

  * All the identified datasets will be available to all Beneficiaries in order to develop the business cases used to validate the project results, as explicitly mentioned in the description tables contained in “Chapter 6 - Dataset description” (see Dataset ACCESS section). 

  

  
<table>  
<tr>  
<th>

**Chapter 4 Business Case description**

</th>  
<th>

**high-level**

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

The main business objective of EW-Shopp is to **develop cross-domain data
integration platform that would enable fragmented European business ecosystem
to increase efficiency and competitiveness through building relevant custom
insights and business knowledge** . This platform will enable us to regain
lost positions in competing against global internet service giants that
managed to position their growth and sector transformation on intensive
exploitation of integrated big data generated at their proprietary platforms.  
  
<table>  
<tr>  
<th>

**4.1**

</th>  
<th>

**Bing Bang, CENEJE (BC1)**

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

The goal of the business case is to follow user experience based on real time
cross channel data integration. The business case will develop analytical
predictive models for managing marketing activities, sales resources,
operations, data quality and content management that will increase partner
efficiency and sales. It will furthermore enable the development of market
data enrichment services and consequent monetization. This will be done
through integrating cross-channel intent, research, interest, interaction and
purchase data with point of sales solutions.

The data that will be integrated are:

  * Purchase intent: A collection of user journey data – pageviews, search terms, redirects to sellers and similar. 

  

  * Product attributes: A collection of product attributes (varying from generic such as name, EAN, brand, categorization and color to more specific as dimensions or technical specifications). 

  

  * Products price history: A collection of seller quotes for products. 

  

  * Customer purchase history: Sell out data matched with customer baskets in a defined timeframe. 

  

  * Consumer intent and interaction: A collection of user journey data from Google Analytics - pageviews, page events, search terms, redirects to channels, etc. 

  

  * Contact and Consumer interaction history: calls (outbound, inbound and simulated calls), other contacts events (email, SMS, click-through, fax, scan, or any other document) and other events. 

  

To achieve the business case goals, in EW-Shopp we will set-up a virtual lab
in a data cloud environment where we will create a set of scenarios by
integrating partner data sets of anonymized user paths to purchase that should
include all possible engagements, decisions and purchase information. The data
will be used in order to:

  * develop models of purchase behavior; 

  

  * cluster similar behaviors to optimize operations; 

  

  * enable user experience advertising; 

  

  * develop efficient sales promotions; 

  

  * provide efficient marketing and communication tools; 

  

  * build segmented mailing groups for efficient automatization of e-mail marketing; 

  

  * increase efficiency in above-the-line (mass media) and below-the-line (one to one) activities; 

  

  * create efficient POS solutions for sales. 

  

  
<table>  
<tr>  
<th>

**4.2**

</th>  
<th>

**GfK (BC2)**

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

The goal of the business case two, is to find which are the external variables
and their weights in predicting sales and success of products. Except the
integration between the two datasets provided by GfK, this business case aims
at integrating also external data such as events and weather data, in order to
improve predictability.

The two services, Retail Sales Data Reporting System and Echo, where the
former allows to maximize sales and profit in order to keep customers coming
back, while the latter tracks and improves the experiences of customers in
real-time. The predictive model learned upon the integrated data about
customer feedback as well as third party data will identify which actions
drive growth.

The data that will be integrated are:

  * Market data: Sales data (tech goods), Product Attributes and Prices Data (tech goods), and Purchase Data 

  

  * Consumers data: Demographics, TV Behaviour & Exposure Data (passive / survey), Online Behavior & Exposure Data, Individual Purchase Data (passive / survey), and Mobile Usage & Exposure Data 

  

  * Event data, including Sport Events (World cup, Champion, Olympic games, etc.), Social Events (strikes, terrorism, epidemics, etc.), Political Events (elections, relevant laws, etc.), Natural Events (earthquake, floods, etc.) 

  

  * Historical Weather Data: relevant weather information across different countries 

  

  * Social media data: measures of customer engagement across different platforms (e.g., email marketing, search 

  

  * Purchase intent and search data: data about purchase research and intent by category and search behaviour based on keyword interaction through advertising. 

  

  
<table>  
<tr>  
<th>

**4.3**

</th>  
<th>

**Measurence (BC3)**

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

The goal of the business case is to improve the Measurance Scout, a location
scouting solution that helps in choosing the best location for the business.
This will optimize the real estate investments by analyzing the traffic around
the location of their interest.

The traffic data, after being anonymized, are collected by Measurance WiFI
technology at a high level of granularity. Moreover. in order to understand
better the potential location, Measurance need also external data such as
weather data, event data, geographic data, sales data of business etc.

The data that are planned to be integrated are:

  * Weather data at a high level of granularity 

  

  * Events data around a location: we need to be able to filter these events based on their venue and, ideally, on the number of people expected to join the events 

  

  * Geographical data: Businesses in the area (shopping, restaurants etc.), schools, tourist attractions, nightlife, etc. 

  

  * Sales data: business volume of businesses in the area aggregated by kind of activity (e.g. restaurants, clothes shop, etc.) 

  

  
<table>  
<tr>  
<th>

**4.4**

</th>  
<th>

**JOT (BC4)**

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

The goal of JOT Business case is using big data technology and integrating
cross domain purchase intention data on the level of search and communication
and content interactions in order to enable JOT to increase its clients’
communication efficiency and marketing effort allocation. Current methods for
online marketing prediction have failed simply because there is no single rule
that can be universally applied to all markets, products and sectors. The only
way to effectively find an online marketing method is to analyse user
behaviour and traffic sources, taking into account the different aspects of
external environmental and behavioural variables that impact it.

Through analysing marketing campaign performance, JOT can obtain behaviour
patterns that can be used to establish a behavioural baseline. Thanks to this
JOT will be able to predict the likely pattern for certain days or times zones
with similar characteristics. Behaviour analysis could be obtained by cross-
referencing geographical data with peak times, baseline traffic, daily
impressions trends, realtime conversion and bounce rates just to name a few
metrics. Furthermore, in order to achieve accurate results, a vast amount of
data will have to be collected so as to provide accuracy to the data sample.

JOT had planned to provide three different datasets within the project (two
are proprietary and meaningful mainly only in their own business case):

  * Traffic sources (Bing): Historical marketing campaign performance statistics of search data in Bing advertising platforms. 

  

  * Traffic sources (Google): Historical marketing campaign performance statistics of data in Google platform. 

  

  * Twitter trends: Trending topics as available through Twitter APIs. 

  

In respect of the [DoA], JOT has datasets to simplify the usage of their data
within EW-Shopp project without impacting the support of the services foreseen
in this business case:

  * the original Pixel Dataset has been unified with Traffic source Google and Traffic source Bing; 

  

  * for the Email marketing campaign dataset, the company Impacting was no longer able to provide it. JOT confirmed this dataset does not affect the goal of the project, being just a complement to the Traffic Source ones, so this will not interfere in the business case success. Moreover, this has allowed to removing, at the source, the problem related to IP and geo-localisation. 

  

Other datasets will be added to the above-mentioned ones in order to realize
the JOT business case:

  * Events: A dataset covering different kinds of events (sporting, large-scale concerts, congresses, elections) for the different countries that wish to take part in the use case will be needed. This kind of dataset is provided through Event Registry dataset. 

  

  * Weather history: This dataset will contain historical data on the weather that JOT will utilize for the project. It will show the real weather conditions, even down to a specific hour / minute, during the time period chosen for the study. This dataset is provided through MARS (historical data) dataset. 

  

  * Weather forecast: Same time period as for the previous dataset but just that the information will be the weather forecasted or predicted for the given times, not necessarily the actual climatic conditions. 

  

The purpose of this business case is related to carry out systematic analyses
to predict the effect of different variables such as weather and other events
on the performance of marketing campaign. These analyses will lead to the
development of different business services:

  1. Event and weather-aware campaign scheduling. This service will be used by JOT to predict the very best moment to launch or run a marketing campaign based on weather conditions and events. 

  

  2. Event-based customer engagement analysis. This service supports the analysis of the possible impact of events on Online Shopping. 

  

  3. Event-based digital marketing management. This service supports intelligent bidding on digital marketing platforms, programmed based on events. 

  

  4. Weather-responsive digital marketing. This service offers intelligent bidding on digital marketing platforms, based on real-time weather conditions. 

  

  
  
<table>  
<tr>  
<th>

**Chapter 5 EW-Shopp DMP**

</th>  
<th>

**Methodology for**

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

The aim of this chapter is to provide an explanation of all the information
required to data owners in order to make data findable, accessible,
interoperable and re-usable (FAIR) and to share the process followed in EW-
Shopp to collect these data.

**5.1 Elements of EW-Shopp Data Management Plan**

The DMP should address some important points on a dataset by dataset basis and
should reflect the current status of reflection within the consortium about
the data that will be produced. The DMP, as a key element of good data
management, has to describe the life cycle management applied to the data to
be collected, processed and/or generated by a Horizon 2020 project.

In order to make data findable, accessible, interoperable and re-usable
(FAIR), a DMP should include:

  * **Dataset Identification** : specifying what data will be collected, processed and/or generated. 

  

  * **Dataset Origin** : specifying if existing data is being re-used (if any), the origin of the data and the expected size of the data (if known). 

  

  * **Dataset Format** : describing the structure and type of the data, time and spatial coverage and language and naming conventions. 

  

  * **Data Access** : specifying whether data will be shared/made open access. In particular, for: 

    * **Making data accessible** : specifying if and which data produced and/or used in the project will be made openly available, moreover _explaining why certain datasets_ _cannot be shared_ (or need to be shared under restrictions), separating legal and contractual reasons from voluntary restrictions. 

  

    * **Making data interoperable** : specifying if the data produced in the project is interoperable, that is allowing data exchange and re-use. Moreover, specifying what data and metadata vocabularies, standards or methodologies it is meant to follow to make data interoperable. 

  

  

  * **Data Security** : specifying which provisions are in place for data security (including data recovery as well as secure storage and transfer of sensitive data). Furthermore, specifying Personal Data presence and, in that case, privacy management procedures put in practice. 

  

The following paragraphs aim to give more details, in terms of the class of
attributes listed above, and will be used as a guide to describe datasets
provided for EW-Shopp purpose, in accordance with the Guidelines on Data
Management in Horizon 2020.

**5.1.1 Dataset IDENTIFICATION**

First of all, it’s needed to identify the dataset to be produced and provide
dataset details, in terms of description of the data that will be generated or
collected.

Following H2020 guidelines, it has been defined a set of relevant information
that can help to define the dataset identification:

  * Category: Dataset typology (Market, Consumer, Products, Weather, Media). 

  

  * Data name: Name of the dataset that should be a self-explaining name. 

  

  * Description: Description of the dataset in order to provide more details. 

  

  * Provider: Name of the beneficiary providing the dataset (or being in charge of bringing it into the project). 

  

  * Contact Person: Name of the person to be contacted for further details about the dataset. 

  

  * Business Cases number: BC involved (i.e., BCx) 

  

**5.1.2 Dataset ORIGIN**

Following H2020 guidelines, it has been defined a set of relevant information
that can help to define the dataset origin:

  * Available at (M): Project month in which the dataset will be available. 

  

  * Core Data (Y|N): Indicate if the dataset is mandatory and will be part of the data shared along the different UCs or if it is discretionary and present only a limited usage. 

  

  * Size: A rough order of magnitude (ROM) estimation in terms of MB/GB/TB. 

  

  * Growth : A dynamic rough order of magnitude (ROM) estimate by selecting the most appropriate frequency in terms of MB/GB/TB per hour/day/week/months/other. 

  

  * Type and format: Dataset format, specifying if it is using, for example, CSV, Excel spreadsheet, XML, JSON, etc. 

  

  * Existing data (Y|N): The data already exist or are generated for the project’s purpose. 

  

  * Data origin: How the data in the dataset is being collected/generated (i.e. SQL table, Google 

  

API, etc.)

**5.1.3 Dataset FORMAT**

Following H2020 guidelines, it has been defined a set of relevant information
that can help to define the dataset format:

  * Dataset structure: description of the structure and type of the data. (i.e. the header columns, the JSON schema, REST response fields, etc.). 

  

  * Dataset format: definition of the dataset format (i.e. specifying if it is using CSV, Excel spreadsheet, XML, JSON, GeoJSON, Shapefile, HTTP stream, etc.). 

  

  * Time coverage: if the data _set has a time dimension, indicatio_ n of what period does it cover. 

  

  * Spatial coverage: if the dataset relates to a spatial region, indication of what is its coverage. 

  

  * Languages: languages of metadata, attributes, code lists, descriptions. 

  

  * Identifiability of data: reference to identifiability of data and standard identification mechanism. 

  

  * Naming convention: description about how the dataset can be identified if updated or after a versioning task has been performed, if the dataset is not static. 

  

  * Versioning: reference to how often is the data updated (i.e. No planned updating, Annually, Quarterly, Monthly, Weekly, Daily, Hourly, Every few minutes, Every few seconds, Real-time) and how the versioning is managed (i.e. if daily, every day a new dataset is generated with the newly created data or every day a new dataset overrides the old one containing all the data generated from the beginning of the collection, …) 

  

  * Metadata standards: specification of standards for metadata creation (if any). If there are no standards description of what metadata will be created and how. 

  

**5.1.4 Dataset ACCESS**

Following H2020 guidelines, it has been defined a set of relevant information
that can help to define the dataset access with the aim to making data
accessible and interoperable:

  * Dataset license: if the dataset is released as open data, indication of the license used: CC0  25  , CC-BY  26  , CC-BY-SA  27  , CC-BY-ND  28  , CC-BY-NC  29  , CC-BY-NC-SA  30  , CC-BY-NC-ND  31  , PDDL  38  , ODCby  32  , ODbL  40  , other or proprietary (with link if possible). Otherwise, specify who have access to the dataset (for example, all partners in the consortium, some partners for the purpose of tool development, only a sample will be disclosed, etc.) 

  

  * Availability (public | private): the dataset is public or private. 

  

  * Availability to EW-Shopp partners (Y|N): the dataset is available to EW-Shopp partners. 

  

  * Availability method: specification of how the data will be made available (i.e. web page in the browser, web service (REST/SOAP APIs), query endpoint, file download, DB dump, directly shared by the responsible organization, etc.). 

  

  * Tools to access: specification of what methods or software tools are needed to access the data. 

  

  * Dataset source URL: specification of where the data and associated metadata, documentation and code are deposited (i.e. dataset source URL, etc.) 

  

  * Access restrictions: specification of how access will be provided in case there are any restrictions. 

  

  * Keyword/Tags: categorization of the dataset through some relevant keywords/tags (i.e. product categories, price, etc.) 

  

  * Archiving and preservation: description of the procedures that will be put in place for longterm preservation of the data. Indication of how long the data should be preserved, what is its approximated end volume, what the associated costs are and how these are planned to be covered. 

  

  * Data interoperability: specification of what data and metadata vocabularies, standards or methodologies will be followed to facilitate interoperability. 

  

  * Standard vocabulary: specification of what standard vocabulary, to allow inter-disciplinary interoperability, will be used for all data types present in the dataset. If not, a mapping to more commonly used ontologies has to be provided. 

  

We provide some more clarifications about the approach to describe Data
interoperability and Standard vocabulary dimensions in EW-Shopp. Because of
the sensitiveness of business data used in the EW-Shopp innovation action, no
commitment to publish datasets provided by business partners as open data is
made in [DoA]. Thus, the primary focus concerning interoperability in EW-Shopp
is on supporting data integration tasks, rather than on supporting
discoverability of data sets by third parties.

For this reason, in Data interoperability, we will focus on methodologies that
will be adopted to support interoperability between the described dataset and
other datasets. Here we will shortly describe the interoperability
methodologies that we plan to use, while more details will be provided in D3.1
– Interoperability Requirements, which will be published at M8.

  * **Publication as linked data (RDF-ization).** Linked data represented with the RDF  33  language provide support to data interoperability by: i) representing information as with graph-based abstractions, often referred to as Knowledge Graphs (descriptions of typed entities, their properties and mutual relations), ii) using global identifiers for entities described in a dataset (URIs), iii) using terms (classes, properties, data types) from shared vocabularies and ontologies. Publishing a source dataset using linked data principles makes it easy to access and use the data for future integration tasks. This methodology is used in particular for EW-Shopp core data, i.e., data that are used as joints to integrate different information sources like product data or product classification schemes, which are not available already as linked data. 

  

  * **N/A (Linked Open Data).** For data that are already available as linked data, we consider interoperability methodology not applicable. 

  

  * **Semantic data enrichment.** This is a key pillar of EW-Shopp approach adopted to support interoperability. Given an input dataset that is provided in a format different from RDF, and after applying suitable transformations if needed, the dataset will be semantically annotated using semantic labelling techniques. We assume that the input dataset is transformed in a table in CSV format, then, i) the headers of the column tables will be aligned with shared vocabularies (e.g., XSD used to define the data types, or predicates of Schema.org  34  used to describe offers in eCommerce portals), while ii) values will be linked to shared systems of identifiers (e.g., location identifiers from DBpedia). Annotations will support the enrichment of the data using the shared system of identifiers as joints, and ii) publication of the data as Knoweldge Graphs represented in RDF (if useful). For example, after linking a column representing product names to EAN codes, we can retrieve the brand of each product from a linked product data source, thus enriching the original dataset. Semantic data enrichment also provides a methodology to publish data that come in tabular format as linked data. However, such a publication is not a mandatory step in semantic data enrichment. 

  

  * **References to shared systems of identifiers and standard data types.** A data sources is made interoperable by using shared systems of identifiers without requiring a full RDFization. For example, we may want to invoke weather data APIs using DBpedia identifiers for locations. 

  

For Standard vocabulary, we refer to shared vocabularies, where “shared” refer
to adoption by community of users. Among shared vocabularies we consider ISO
standards, e.g., ISO 8601  35  date formats, languages and vocabularies
recommended by W3C  36  , e.g., RDF or Time OWL 2  37  , but also vocabularies
and systems of identifiers that are becoming de-fact standard because of
usage, e.g., Schema.org, DBpedia, Wikipedia. We will consider the following
shared vocabularies, which will be used in the project to support
interoperability:

  * Terminologies from language specifications 

  

  * Predicates, classes and data types specified in languages recommended by W3C (i.e., XSD Data Types  38  , RDF, SKOS  47  , RDFS  39  , OWL  40  ); these terms are used throughout the project, thus they will not be added to the descriptions of individual datasets. 

  

o Classifications

  * **Interlinked product classifications.** This classification will be built in EW-Shopp by linking Google Categories (from Google product taxonomy), Global Product Classification by GS1 1 and GFK product categories, i.e., categories used in GFK Product Catalog 2 (GS1 categories are derived from GFK categories and the two classifications are aligned). o Domain ontologies and shared systems of identifiers 

  

  * **Linked product data.**

    * Schema-level terminology (e.g., Schema.org, GoodRelations  50  ) 

  

    * Schema-level terminology and identifiers (GfK Product Catalog for retail, with internal identifiers and partially aligned to EAN codes 3) 

  

  

  * **Temporal ontologies** . Standard vocabularies and other vocabularies and ontologies recommended by W3C to represent temporal information (e.g., ISO 8601, XSD Date and Time Data Types, Time OWL 2). 

  

  * **Spatial ontologies and locations** . Ontologies covering spatial schema-level terminology as well as identifiers of locations and administrative units across Europe (e.g., Basic Geo WGS84  41  , DBpedia Ontology  42  , Schema.org, Geonames Ontology  43  , Linked GeoData  44  , Linked Open Street Maps  45  ) 

  

  * **Wikipedia entities.** Wikipedia provide identifiers for a very large number and variety of entities described in Wikipedia, which are adopted by a very large community of data providers and consumers. With Wikipedia entities, we refer also to identifiers used in data sources derived from Wikipedia (e.g., DBpedia) or linked to Wikipedia identifiers (e.g., WikiData  46  ). While identifiers of location play a prominent role in EW-Shopp and are covered by spatial locations, here we refer to entities of different types, used, e.g., to annotate events. 

  

**5.1.5 Data SECURITY**

Following H2020 guidelines, it has been defined a set of relevant information
that can help to define the dataset security:

  * Personal Data (Y|N): Confirmation about personal data presence in the dataset. 

  

  * Anonymized (Y|N|NA): confirmation if personal data is anonymized. 

  

  * Data recovery and secure storage: Information about how was managed data recovery and secure storage. 

  

  * Privacy management procedures: Specification about procedure addressed in order to manage privacy. 

  

  * PD At The Source (Y|N): Confirmation about Personal data absence at the source. 

  

  * PD - Anonymised during project (Y|N): Confirmation about Personal data anonymised during the project. 

  

  * PD - Anonymised before project (Y|N): Confirmation about Personal data anonymised before the project. 

  

  * Level of Aggregation (for PD anonymized by aggregation): Indication about which is the level of aggregation to allow Personal data anonymization. 

  

**5.2 Process to collect dataset details**

The goal to collect all the information, described in the previous paragraphs,
has been achieved, with respect to EW-Shopp dataset, through the process
described here below.

The first step was intended to set up a table with the main sections of the
Dataset description: Dataset Identification, Dataset origin, Dataset format,
Dataset access and Dataset security. Each of these sections was further
decomposed to contain all the information described in the related paragraphs
showed in this Chapter 5

The second step consisted in preparing a sort of survey in the form of a
textual description (see Annex A – DMP Survey), with the scope to give a clear
understanding of all the required information and ease the fulfilment of the
table.

The third step was realized by performing a collection process, when each
Business case owner had to fulfill the table and then it was interviewed by a
technical partner aiming at discussing the information provided.

At the end of the process, all the information collected was merged in an
integrated spreadsheet. The same information will be discussed, in the
following chapter, using a table format in order to ease the understanding of
each dataset description.

**Chapter 6 Dataset description**

The aim of this chapter is to provide, for each dataset, a description trying
to answer to all the information listed in Chapter 5 in accordance with
Guidelines on FAIR Data Management in Horizon 2020 and with ethics and legal
requirements. Dataset, as it’s possible to see in the following paragraphs,
refers to individual dataset but also to families of datasets with the same
structure created in different moments of time or under other discriminating
conditions.

**6.1 CE Dataset - Consumer Data: Purchase Intent**

**6.1.1 Dataset IDENTIFICATION**

The dataset “Purchase Intent” is proprietary and contains user journey metrics
and logs.

#  Table 5. DATASET IDENTIFICATION – Purchase Intent  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Consumer data

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

**Data name**

</td>  
<td>

Purchase intent

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

**Description**

</td>  
<td>

A collection of user journey data – pageviews, search terms, redirects to
sellers and similar. Data is logged to local databases and we provide data
from 1. 1. 2015. Local databases consist of SQL databases and NoSQL databases.

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

**Provider**

</td>  
<td>

Ceneje

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

**Contact Person**

</td>  
<td>

David Creslovnik Uros Mevc

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

**Business Cases number**

</td>  
<td>

BC1

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

**6.1.2 Dataset ORIGIN**

This dataset is available from January 2017 and it cannot be defined as “core
data”. The dataset already existed.

#  Table 6. DATASET ORIGIN – Purchase Intent  
  
<table>  
<tr>  
<th>

</th>  
<th>

**Available at (M)**

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

**Core Data (Y|N)**

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

**Size**

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

**Growth**

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

</td>  
<td>

15000 searches per day

25000 redirects per day

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

**Type and format**

</td>  
<td>

structured documents, TSV

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

SQL tables

NoSQL documents

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

**6.1.3 Dataset FORMAT**

The dataset has a tsv (SQL) or json (NoSQL) format, the data structure is
illustrated in the following table. It collects data not in a specific
language, since 2015 and it covers information at Country level. The data is
updated daily that means every day the dataset contains only the data newly
generated.

#  Table 7 DATASET FORMAT – Purchase Intent  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

*SQL tables* 

Product pageviews

  * IdProduct (INT) 

  

  * NameProduct (STRING) 

  

  * L1 (STRING): Level 1 category 

  

  * L2 (STRING): Level 2 category 

  

  * L3 (STRING): Level 3 category 

  

  * IdUsers (INT) 

  

  * Date (DATETIME) 

  

Product deeplinks (redirects to sellers)

  * IdProduct (INT) 

  

  * NameProduct (STRING) 

  

  * L1 (STRING): Level 1 category 

  

  * L2 (STRING): Level 2 category 

  

  * L3 (STRING): Level 3 category 

  

  * IdUsers (INT) 

  

  * IdSeller (INT) 

  

  * Date (DATETIME) 

  

*NoSQL documents* 

Page search

{

"_id" : (ObjectId)

"IdUsers" : (INT),

"TimeStamp" : (ISODate),

"Search" : {

"NumberOfResults" : (INT),

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

</td>  
<td>

"Query" : (STRING)

}

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

**Dataset format**

</td>  
<td>

SQL: tsv

NoSQL: json

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

**Time coverage**

</td>  
<td>

since 2015

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

**Spatial coverage**

</td>  
<td>

Country

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

**Languages**

</td>  
<td>

not language specific

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

**Identifiability of data**

</td>  
<td>

Yes

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

**Naming convention**

</td>  
<td>

/{country}/YYYY/MM/DD.tsv

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

**Versioning**

</td>  
<td>

Daily (every day the dataset contains only the data newly generated)

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.1.4 Dataset ACCESS**

The dataset is private, but it is accessible to all the consortium members.
The data will be made available through File-download by means of WGET/Curl.
Dataset will be deposited on AWS or Ceneje static content server and the
access is provided by credentials.

#  Table 8 MAKING DATA ACCESSIBLE – Purchase Intent  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: Ceneje

Access: All members

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

**Availability (public | private)** 
</td>  
<td>

private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

File download (zip)

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

**Tools to access**

</td>  
<td>

WGET/Curl

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

**Dataset source URL**

</td>  
<td>

AWS or Ceneje static content server

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

**Access restrictions**

</td>  
<td>

Credentials

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

**Keyword/Tags**

</td>  
<td>

N/A

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

**Archiving and preservation**

</td>  
<td>

NO (can be generated on demand)

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

#  Table 9 MAKING DATA INTEROPERABLE – Purchase Intent  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Interlinked product classification

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

</td>  
<td>

•

</td>  
<td>

Linked product data

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

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

**6.1.5 Dataset SECURITY**

The dataset does not contain personal data because these were anonymized
before being used in the project. It is expected a secure storage and regular
backups.

#  Table 10 DATASET SECURITY - Purchase Intent  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

Y

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

**Data recovery and secure storage**

</td>  
<td>

Secure storage, regular backups

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

**Privacy management procedures**

</td>  
<td>

N/A

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

**PD at the source (Y|N)**

</td>  
<td>

Y

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

Y

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

**Level of Aggregation (for PID anonymized by aggregation)**

</td>  
<td>

User Id level (anonymous)

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

**6.1.6 Ethics and Legal requirements**

The source of the data contains PD, but data are anonymized before the project
and shared within the project without PD. Since Ceneje already notified to
their Data Protection Officer (DPO) that there will be no PD shared, they
don’t need to get additional opinion. Notification to Data Protection Officer
is included in deliverable [D7.2].

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.2 ME Dataset - Consumer Data: Location analytics data (Hourly)**

**6.2.1 Dataset IDENTIFICATION**

The dataset “Location analytics data”, provided by Measurence, focuses on
Hourly number of devices with WiFi enabled that pass through an area covered
by Measurence WiFi sensors.

#  Table 11\. DATASET IDENTIFICATION – Location analytics data  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Consumer Data

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

**Data name**

</td>  
<td>

Location analytics data

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

**Description**

</td>  
<td>

Hourly number of devices with WiFi enabled that pass through an area covered
by Measurence WiFi sensors

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

**Provider**

</td>  
<td>

Measurence

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

**Contact Person**

</td>  
<td>

Olga Melnyk

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

**Business Cases number**

</td>  
<td>

BC3

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

**6.2.2 Dataset ORIGIN**

This dataset is available from January 2017 and it cannot be defined as “core
data”. It has a APIs - JSON format with a size of ~600GB and a growth of ~5GB
/ location / month. The dataset already existed before the project.

#  Table 12. DATASET ORIGIN – Location analytics data  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

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

**Core Data (Y|N)**

</td>  
<td>

N

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

**Size**

</td>  
<td>

~600GB

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

**Growth**

</td>  
<td>

~5GB / location / month

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

**Type and format**

</td>  
<td>

APIs - JSON format

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

Proprietary sensors

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

**6.2.3 Dataset FORMAT**

The dataset has a JSON and CSV format. It collects numerical data gathered
since 2015 and it covers information related to zip code, coordinates,
address, county, city, country. The data is updated daily that means every day
the dataset contains only the data newly generated.

#  Table 13 DATASET FORMAT – Location analytics data  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

N/A because there is no access to the data through URL

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

**Dataset format**

</td>  
<td>

JSON and CSV

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

**Time coverage**

</td>  
<td>

starting from 2015

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

**Spatial coverage**

</td>  
<td>

zip code, coordinates, address, county, city, country

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

**Languages**

</td>  
<td>

EN (numerical data)

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

**Identifiability of data**

</td>  
<td>

No. Raw data contains a hashed version of the real mac address which is
anonymized at the source

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

**Naming convention**

</td>  
<td>

/location_id/YYYY/MM/DD/HH

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

**Versioning**

</td>  
<td>

Daily (every day the dataset contains only the data newly generated)

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.2.4 Dataset ACCESS**

The dataset is private, but it is accessible to all the consortium members.
The data will be made available through API by means of Authenticated
encrypted channel.

#  Table 14 MAKING DATA ACCESSIBLE – Location analytics data  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: ME. Access: members

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

**Availability (public | private)**

</td>  
<td>

private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

API

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

**Tools to access**

</td>  
<td>

Authenticated encrypted channel

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

**Dataset source URL**

</td>  
<td>

API endpoint

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

**Access restrictions**

</td>  
<td>

Credentials / API keys

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

**Keyword/Tags**

</td>  
<td>

presence data, location intelligence

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

**Archiving and preservation**

</td>  
<td>

Lifetime archive of raw data. The APIs always use the last version of the
algorithm

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

#  Table 15 MAKING DATA INTEROPERABLE – Location analytics data  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

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

**6.2.5 Dataset SECURITY**

The dataset does not contain personal data because these data were anonymized
at the source. It is expected data recovery and a secure storage.

#  Table 16 DATASET SECURITY - Location analytics data  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

Y, prior to storing data in a database (No PD is stored in any database)

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

**Data recovery and secure storage**

</td>  
<td>

Y

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

**Privacy management procedures**

</td>  
<td>

All the data anonymized are before storage (read paragraph 6.2.6)

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

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

**6.2.6 Ethics and Legal requirements**

The MAC addresses that Measurence's sensors collect (which can be unique
identifiers of WiFi transmitters) are hashed with the cryptographic hash
function SHA-2 256bits – which is a set of cryptographic hash functions  47
designed by the United States National Security Agency (NSA). Measurence
followed a privacy by design approach, so after hashing has been performed,
the hashed MAC address is sent to our servers and the original MAC address
gets discarded directly by the sensor: we never store the real mac address on
our servers. Given a hashed MAC address there is no way to reconstruct the
corresponding original MAC address, other than attempt a brute force attack
(which, obviously, is applicable to any cryptographic function). Based on the
above description, this dataset does not contain personal data, therefore the
national and European legal framework that regulates the use of personal data
does not apply and copy of opinion is not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.3 ME Dataset - Consumer Data: Location analytics data (Daily)**

**6.3.1 Dataset IDENTIFICATION**

The dataset “Location analytics data”, provided by Measurence, focuses on
daily number of devices with WiFi enabled that pass through an area covered by
Measurence WiFi sensors.

#  Table 17\. DATASET IDENTIFICATION – Location analytics data  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Consumer Data

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

**Data name**

</td>  
<td>

Location analytics data

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

**Description**

</td>  
<td>

Daily number of devices with WiFi enabled that pass through an area covered by
Measurence WiFi sensors

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

**Provider**

</td>  
<td>

Measurence

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

**Contact Person**

</td>  
<td>

Olga Melnyk

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

**Business Cases number**

</td>  
<td>

BC3

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

**6.3.2 Dataset ORIGIN**

This dataset is available from January 2017 and it cannot be defined as “core
data”. It has a APIs - JSON format with a size of ~600GB and a growth of ~5GB
/ location / month. The dataset already existed before the project.

#  Table 18. DATASET ORIGIN – Location analytics data  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

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

**Core Data (Y|N)**

</td>  
<td>

N

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

**Size**

</td>  
<td>

~600GB

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

**Growth**

</td>  
<td>

~5GB / location / month

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

**Type and format**

</td>  
<td>

APIs - JSON format

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

Proprietary sensors

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

**6.3.3 Dataset FORMAT**

The dataset has a JSON and CSV format. It collects numerical data gathered
starting from 2015 and it covers information related to zip code, coordinates,
address, county, city, country. The data is updated daily that means every day
the dataset contains only the data newly generated.

#  Table 19 DATASET FORMAT – Location analytics data  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

N/A because there is no access to the data through URL

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

**Dataset format**

</td>  
<td>

JSON and CSV

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

**Time coverage**

</td>  
<td>

starting from 2015

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

**Spatial coverage**

</td>  
<td>

zip code, coordinates, address, county, city, country

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

**Languages**

</td>  
<td>

EN (numerical data)

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

**Identifiability of data**

</td>  
<td>

No. Raw data contains an hashed version of the real mac address which is
anonymized at the source

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

**Naming convention**

</td>  
<td>

/location_id/YYYY/MM/DD/

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

**Versioning**

</td>  
<td>

Daily (every day the dataset contains only the data newly generated)

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.3.4 Dataset ACCESS**

The dataset is private, but it is accessible to all the consortium members.
The data will be made available through API by means of Authenticated
encrypted channel.

#  Table 20 MAKING DATA ACCESSIBLE – Location analytics data  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: ME. Access: members

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

**Availability (public | private)** 
</td>  
<td>

Private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

API

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

**Tools to access**

</td>  
<td>

Authenticated encrypted channel

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

**Dataset source URL**

</td>  
<td>

TBD / API endpoint

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

**Access restrictions**

</td>  
<td>

Credentials / API keys

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

**Keyword/Tags**

</td>  
<td>

presence data, location intelligence

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

**Archiving and preservation**

</td>  
<td>

Lifetime archive of raw data. The APIs always use the last version of the
algorithm

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

#  Table 21 MAKING DATA INTEROPERABLE – Location analytics data  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

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

**6.3.5 Dataset SECURITY**

The dataset does not contain personal data because these data were anonymized
at the source. It is expected data recovery and a secure storage.

#  Table 22 DATASET SECURITY - Location analytics data  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

Y, prior to storing data in a database (No PD is stored in any database)

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

**Data recovery and secure storage**

</td>  
<td>

Y

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

**Privacy management procedures**

</td>  
<td>

All the data anonymized are before storage (read paragraph 6.3.6)

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

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

**6.3.6 Ethics and Legal requirements**

The MAC addresses that Measurence's sensors collect (which can be unique
identifiers of WiFi transmitters) are hashed with the cryptographic hash
function SHA-2 256bits – which is a set of cryptographic hash functions
designed by the United States National Security Agency (NSA). Measurence
followed a privacy by design approach, so after hashing has been performed,
the hashed MAC address is sent to our servers and the original MAC address
gets discarded directly by the sensor: we never store the real mac address on
our servers. Given a hashed MAC address there is no way to reconstruct the
corresponding original MAC address, other than attempt a brute force attack
(which, obviously, is applicable to any cryptographic function). Based on the
above description, this dataset does not contain personal data, therefore the
national and European legal framework that regulates the use of personal data
does not apply and copy of opinion is not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.4 BB Dataset - Consumer Data: Customer Purchase History**

**6.4.1 Dataset IDENTIFICATION**

The dataset “Customer purchase history” is proprietary and contains data on
customers and their purchases.

#  Table 23\. DATASET IDENTIFICATION – Customer Purchase History  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Consumer data

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

**Data name**

</td>  
<td>

Customer purchase history

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

**Description**

</td>  
<td>

Sell out data matched with customer baskets in a defined timeframe.

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

**Provider**

</td>  
<td>

Big Bang

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

**Contact Person**

</td>  
<td>

Matija Torlak

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

**Business Cases number**

</td>  
<td>

BC1

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

**6.4.2 Dataset ORIGIN**

This dataset is available from January 2017 and it cannot be defined as “core
data”. It has a size of 29000 products and a growth of 2000 new products per
year. The dataset already existed before the project.

#  Table 24 DATASET ORIGIN – Customer Purchase History  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

</th>  
<th>

</th>  
<th>

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

**Core Data (Y|N)**

</td>  
<td>

N

</td>  
<td>

</td>  
<td>

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

**Size**

</td>  
<td>

29000 products

</td>  
<td>

</td>  
<td>

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

**Growth**

</td>  
<td>

2000 new products per year

</td>  
<td>

</td>  
<td>

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

**Type and format**

</td>  
<td>

structured tabular data

</td>  
<td>

</td>  
<td>

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

**Existing data (Y|N)**

</td>  
<td>

Y

</td>  
<td>

</td>  
<td>

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

**Data origin**

</td>  
<td>

Google Analytics, DWH (SQL

structured data

</td>  
<td>

tables),

</td>  
<td>

Excel

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

**6.4.3 Dataset FORMAT**

The dataset has a CSV/XLS format. It collects data gathered since 2013 and it
covers information related to total or per store location (18 stores + web).
The data is updated daily and contains the data newly generated and history.

#  Table 25 DATASET FORMAT – Customer Purchase History  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

BB Classification - can be matched with GPC Classification; purchase data
table structured (SQL)

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

**Dataset format**

</td>  
<td>

CSV/XLS

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

**Time coverage**

</td>  
<td>

since 2013

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

**Spatial coverage**

</td>  
<td>

Total or per store location (18 stores + web)

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

**Languages**

</td>  
<td>

slovenian

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

**Identifiability of data**

</td>  
<td>

Yes

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

**Naming convention**

</td>  
<td>

/{country}/companyname/purchaseid.json

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

**Versioning**

</td>  
<td>

daily (new + history)

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

**Metadata standards**

</td>  
<td>

Google Analytics

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

**6.4.4 Dataset ACCESS**

The dataset is public, but it is accessible through password. The data will be
made available through download.

#  Table 26 MAKING DATA ACCESSIBLE – Customer Purchase History  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Admin - Full User (Owner)

Access all members through pass and user name

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

**Availability (public | private)**

</td>  
<td>

public (password, username restricted)

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

Download, view, edit (based on license)

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

**Tools to access**

</td>  
<td>

Accessible on web

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

**Dataset source URL**

</td>  
<td>

BB virtual server

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

**Access restrictions**

</td>  
<td>

Credentials

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

**Keyword/Tags**

</td>  
<td>

OrderId, ProductId, StoreId,…. Same as the Sample

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

**Archiving and preservation**

</td>  
<td>

Can be generated on demand

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

#  Table 27 MAKING DATA INTEROPERABLE – Customer Purchase History  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Publication as linked data (RDF-ization)

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

</td>  
<td>

•

</td>  
<td>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Interlinked product classification

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

</td>  
<td>

•

</td>  
<td>

Linked product data

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

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

**6.4.5 Dataset SECURITY**

The dataset does not contain personal data because these data were anonymized
at the source. It is expected secure storage and constant download options.

#  Table 28 DATASET SECURITY – Customer Purchase History  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

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

**Data recovery and secure storage**

</td>  
<td>

Secure storage, constant download options

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

**Privacy management procedures**

</td>  
<td>

Personal data will not be processed during the project. All data are returned
by analytics engine that will not provide PD.

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

**PD at the source (Y|N)**

</td>  
<td>

Y

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

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

**Level of Aggregation (for PD**

**anonymized by aggregation)**

</td>  
<td>

N/A

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

**6.4.6 Ethics and Legal requirements**

The source of the data contains PD, but data are anonymized before the project
and shared within the project without PD. Since Bing Bang already notified to
their Data Protection Officer (DPO) that there will be no PD shared, they
don’t need to get additional opinion. Notification to Data Protection Officer
is included in deliverable [D7.2].

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.5 BB Dataset - Consumer Data: Consumer Intent and Interaction**

**6.5.1 Dataset IDENTIFICATION**

The dataset “Consumer intent and interaction” is proprietary and contains data
on customer journeys recorder using Google analytics.

#  Table 29\. DATASET IDENTIFICATION – Consumer Intent and Interaction  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Consumer data

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

**Data name**

</td>  
<td>

Consumer intent and interaction

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

**Description**

</td>  
<td>

A collection of user journey data from Google Analytics - pageviews, page
events, search terms, redirects to channels, etc. Data is recorded since
December 2012.

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

**Provider**

</td>  
<td>

Big Bang

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

**Contact Person**

</td>  
<td>

Matija Torlak

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

**Business Cases number**

</td>  
<td>

BC1

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

**6.5.2 Dataset ORIGIN**

This dataset is available from January 2017 and it cannot be defined as “core
data”. The dataset already existed before the project.

#  Table 30 DATASET ORIGIN - Consumer Intent and Interaction  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

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

**Core Data (Y|N)**

</td>  
<td>

N

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

**Size**

</td>  
<td>

130 million pageviews,

20 million sessions,

8 million users,

70000 transactions (since December 2012)

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

**Growth**

</td>  
<td>

10.000 users per day

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

**Type and format**

</td>  
<td>

numeric

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

Google Analytics

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

**6.5.3 Dataset FORMAT**

The dataset has a CSV format. It collects data gathered since 2013 and it
regards the whole world.

The data is updated daily and contains the data newly generated and history.

#  Table 31 DATASET FORMAT – Consumer Intent and Interaction  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

Google Analytics specified

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

**Dataset format**

</td>  
<td>

CSV, XLS

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

**Time coverage**

</td>  
<td>

since 2013

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

**Spatial coverage**

</td>  
<td>

Global

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

**Languages**

</td>  
<td>

not language specific

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

**Identifiability of data**

</td>  
<td>

Yes

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

**Naming convention**

</td>  
<td>

N/A

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

**Versioning**

</td>  
<td>

daily (new + history)

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

**Metadata standards**

</td>  
<td>

Google Analytics

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

**6.5.4 Dataset ACCESS**

The dataset is public, but it is accessible through password. The data will be
made available through download.

#  Table 32 MAKING DATA ACCESSIBLE – Consumer Intent and Interaction  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Admin - Full User (Owner)

Access all members through pass and user name

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

**Availability (public | private)** 
</td>  
<td>

public (password, username restricted)

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

Download, view, edit (based on license)

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

**Tools to access**

</td>  
<td>

N/A

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

**Dataset source URL**

</td>  
<td>

BB virtual server

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

**Access restrictions**

</td>  
<td>

Credentials

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

**Keyword/Tags**

</td>  
<td>

Google search tags

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

**Archiving and preservation**

</td>  
<td>

N/A because data is used just for analytical

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

#  Table 33 MAKING DATA INTEROPERABLE – Consumer Intent and Interaction  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Interlinked product classification

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

</td>  
<td>

•

</td>  
<td>

Linked product data

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

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

**6.5.5 Dataset SECURITY**

The dataset does not contain personal data. It is expected secure storage and
constant download options.

#  Table 34 DATASET SECURITY – Consumer Intent and Interaction  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

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

**Data recovery and secure storage**

</td>  
<td>

Secure storage, back up

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

**Privacy management procedures**

</td>  
<td>

Google Analytics data only, so no PD included. In this case

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

</td>  
<td>

data is on the level of product / categories / page.

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD- anonymised before project (Y|N)**

</td>  
<td>

N

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

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

**6.5.6 Ethics and Legal requirements**

Based on the above dataset description, the dataset does not contain personal
data, therefore the national and European legal framework that regulates the
use of personal data does not apply and copy of opinion is not required to be
collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.6 ME Dataset - Consumer Data: Location analytics data (Weekly)**

**6.6.1 Dataset IDENTIFICATION**

The dataset “Location analytics data”, provided by Measurence, focuses on
weekly number of devices with WiFi enabled that pass through an area covered
by Measurence WiFi sensors.

#  Table 35\. DATASET IDENTIFICATION – Location analytics data  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Consumer Data

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

**Data name**

</td>  
<td>

Location analytics data

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

**Description**

</td>  
<td>

Weekly number of devices with WiFi enabled that pass through an area covered
by Measurence WiFi sensors

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

**Provider**

</td>  
<td>

Measurence

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

**Contact Person**

</td>  
<td>

Olga Melnyk

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

**Business Cases number**

</td>  
<td>

BC3

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

**6.6.2 Dataset ORIGIN**

This dataset is available from January 2017 and it cannot be defined as “core
data”. It has a APIs - JSON format with a size of ~600GB and a growth of ~5GB
/ location / month. The dataset already existed before the project.

#  Table 36. Dataset ORIGIN – Location analytics data  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

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

**Core Data (Y|N)**

</td>  
<td>

N

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

**Size**

</td>  
<td>

~600GB

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

**Growth**

</td>  
<td>

~5GB / location / month

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

**Type and format**

</td>  
<td>

APIs - JSON format

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

Proprietary sensors

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

**6.6.3 Dataset FORMAT**

The dataset has a JSON and CSV format. It collects numerical data gathered
starting from 2015 and it covers information related to zip code, coordinates,
address, county, city, country. The data is updated daily that means every day
the dataset contains only the data newly generated.

#  Table 37 DATASET FORMAT – Location analytics data  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

N/A because there is no access to the data through URL

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

**Dataset format**

</td>  
<td>

JSON and CSV

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

**Time coverage**

</td>  
<td>

starting from 2015

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

**Spatial coverage**

</td>  
<td>

zip code, coordinates, address, county, city, country

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

**Languages**

</td>  
<td>

EN (numerical data)

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

**Identifiability of data**

</td>  
<td>

No. Raw data contains a hashed version of the real mac address which is
anonymized at the source

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

**Naming convention**

</td>  
<td>

/location_id/YYYY/weeknum

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

**Versioning**

</td>  
<td>

Daily (every day the dataset contains only the data newly generated)

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.6.4 Dataset ACCESS**

The dataset is private, but it is accessible to all the consortium members.
The data will be made available through API by means of Authenticated
encrypted channel.

#  Table 38 MAKING DATA ACCESSIBLE – Location analytics data  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: ME. Access: members

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

**Availability (public | private)** 
</td>  
<td>

Private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

API

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

**Tools to access**

</td>  
<td>

Authenticated encrypted channel

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

**Dataset source URL**

</td>  
<td>

TBD / API endpoint

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

**Access restrictions**

</td>  
<td>

Credentials / API keys

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

**Keyword/Tags**

</td>  
<td>

presence data, location intelligence

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

**Archiving and preservation**

</td>  
<td>

Lifetime archive of raw data. The APIs always use the last version of the
algorithm

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

#  Table 39 MAKING DATA INTEROPERABLE – Location analytics data  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

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

**6.6.5 Dataset SECURITY**

The dataset does not contain personal data because these data were anonymized
at the source. It is expected data recovery and a secure storage.

##  Table 40 DATASET SECURITY - Location analytics data  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

Y, prior to storing data in a database (No PD is stored in any database)

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

**Data recovery and secure storage**

</td>  
<td>

Y

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

**Privacy management procedures**

</td>  
<td>

All the data anonymised are before storage (read paragraph 6.6.6)

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

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

**6.6.6 Ethics and Legal requirements**

The MAC addresses that Measurence's sensors collect (which can be unique
identifiers of WiFi transmitters) are hashed with the cryptographic hash
function SHA-2 256bits – which is a set of cryptographic hash functions
designed by the United States National Security Agency (NSA). Measurence
followed a privacy by design approach, so after hashing has been performed,
the hashed MAC address is sent to our servers and the original MAC address
gets discarded directly by the sensor: we never store the real mac address on
our servers. Given a hashed MAC address there is no way to reconstruct the
corresponding original MAC address, other than attempt a brute force attack
(which, obviously, is applicable to any cryptographic function). Based on the
above description, this dataset does not contain personal data, therefore the
national and European legal framework that regulates the use of personal data
does not apply and copy of opinion is not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.7 BT Dataset - Customer Communication Data: Contact and Consumer
Interaction History**

**6.7.1 Dataset IDENTIFICATION**

The dataset “Contact and Consumer Interaction history” is proprietary and
contains data on communications with customers.

##  Table 41\. DATASET IDENTIFICATION – Contact and Consumer Interaction
History  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Customer Communication Data

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

**Data name**

</td>  
<td>

Contact and Consumer Interaction History

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

**Description**

</td>  
<td>

The dataset contains the following data:

  * calls o every outbound call; successful or not (every attempt counts) o every inbound call; successful or not o every simulated call 

  

  * other contacts events o every inbound email, SMS, click-through, fax, scan, or any other document 

  

o every outbound email, SMS, fax, or any other sent document

• other events o a record of agent's time spent on waiting for a contact o a
record of every time an agent logs in or out

o a record of every time an agent joins or leaves a campaign o a record of
every CCServer (CDE COCOS CEP Contact Center Server) start up or shutdown

Using this data, it is possible to create statistics and reports regarding
telephony and performance of single agents, groups of agents, campaigns and
call center. Nearly all the reports provided by CCServer are made from this
table.

Although this table isn't meant to serve as a basis for content related
reports (i.e., interview statistics), there are some fields in the table that
may be used for this kind of reports as well.

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

</td>  
<td>

Dataset data are either generated from the CCServer system or collected from
collected from the contact signaling (protocol).

The data are intended for handling the Customer Engagement Platform (CEP)
campaigns, they are already used for these intentions and are in future
intended for the same purposes.

Existing data is carrying all information about realized connection types and
services and will be reused and upgraded with new communication channels,
trends and services.

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

**Provider**

</td>  
<td>

Browsetel / CDE

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

**Contact Person**

</td>  
<td>

Matej Žvan Aleš Štor

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

**Business Cases number**

</td>  
<td>

BC1

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

**6.7.2 Dataset ORIGIN**

This dataset is available from March 2017 and it can be defined as “core
data”. Its size is of 5-20 GB with a growth of 5-20 GB / year. The dataset
already existed before the project.

##  Table 42 DATASET ORIGIN – Contact and Consumer Interaction History  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M3

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

**Core Data (Y|N)**

</td>  
<td>

Y

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

**Size**

</td>  
<td>

5-20 GB

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

**Growth**

</td>  
<td>

5-20 GB / year

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

**Type and format**

</td>  
<td>

Current format is SQL, target format CSV UTF-8 Text file (compressed)

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

Contact center and Customer Interaction Management data

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

**6.7.3 Dataset FORMAT**

The dataset has CSV UTF8 format. It covers information related to Slovenia
area in English. The data is updated monthly.

##  Table 43 DATASET FORMAT – Contact and Consumer Interaction History  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

RAW data.

Optimized Data from the system “Call History” table and history from Customer
Interaction Management. Records describing contacts can be described by
additional information records.

EVENTID

CAMPAIGNRESULT_CCS

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

</td>  
<td>

RESULT_CODE

CALL_PRIORITY

ATTEMPT_NR

MANUAL_MODE

CCS_ENDSTATE

COST

CONTACT_COUNT

FOR_APPOINTMENT

CALL_TYPE

CALL_DIRECTION

DISC_CAUSE

DISC_CAUSE_DESC

QUEUE_SIZE

ALL_QUEUE_SIZE

DISC_BY_CUSTOMER

CUSTOM_DATA

CALLED_NUMBER

VRU_NUMBER

TRANSFERS

REJECTS IGNORES...

CALL_REASON

EVENT_SERVICE_ORIGIN

EVENT_ORIGIN

EVENT_TYPE

EVENT_DATE

EVENT_LOCATION

MEDIA_TYPE

TOTAL_TIME

CONVERSATION_TIME

</td>  
<td>

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

**Dataset format**

</td>  
<td>

CSV UTF8

</td>  
<td>

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

**Time coverage**

</td>  
<td>

1 year (at the start), updated during the project duration

</td>  
<td>

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

**Spatial coverage**

</td>  
<td>

Slovenia

</td>  
<td>

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

**Languages**

</td>  
<td>

English

</td>  
<td>

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

**Identifiability of data**

</td>  
<td>

Persistent and unique identifiers are used e.g. CAMPAIGN_ID, CHANNEL_ID…

</td>  
<td>

EVENT_ID,

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

**Naming convention**

</td>  
<td>

Not used

</td>  
<td>

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

**Versioning**

</td>  
<td>

Monthly

</td>  
<td>

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

**Metadata standards**

</td>  
<td>

Proprietary solution in form of relational tables

</td>  
<td>

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

**6.7.4 Dataset ACCESS**

The dataset is private, but it is accessible to all the consortium members.
The data will be made available from Secure FTP in compressed CSV UTF-8.

##  Table 44 MAKING DATA ACCESSIBLE – Contact and Consumer Interaction History  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

No licencing for the time of EW Shopp project duration. Access via ACL is
enabled for all partners in the consortium

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

**Availability (public |**

**private)**

</td>  
<td>

private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

Data available from Secure FTP in compressed CSV UTF-8.

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

**Tools to access**

</td>  
<td>

Secure FTP Client

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

**Dataset source URL**

</td>  
<td>

Browsetel, secure file server

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

**Access restrictions**

</td>  
<td>

Credentials

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

**Keyword/Tags**

</td>  
<td>

Contacts

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

**Archiving and preservation**

</td>  
<td>

Data will be preserved for the time of EW Shopp project duration. End volume
is approximated to be 20 GB.

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

##  Table 45 MAKING DATA INTEROPERABLE – Contact and Consumer Interaction
History  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

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

**6.7.5 Dataset SECURITY**

The dataset does not contain PD because PD was removed at the source.

##  Table 46 DATASET SECURITY – Contact and Consumer Interaction History  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

N

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

**Data recovery and secure storage**

</td>  
<td>

N

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

**Privacy management procedures**

</td>  
<td>

Caller number is ignored and not recorded (not needed in analytical
processing)

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

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

**6.7.6 Ethics and Legal requirements**

Based on the above dataset description, the dataset does not contain personal
data, therefore the national and European legal framework that regulates the
use of personal data does not apply and copy of opinion is not required to be
collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.8 ECMWF Dataset - Weather: MARS Historical Data**

**6.8.1 Dataset IDENTIFICATION**

The dataset “MARS Historical Data” is proprietary and contains meteorological
data.  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M4

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

**Core Data (Y|N)**

</td>  
<td>

Y

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

**Size**

</td>  
<td>

>85PT

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

**Growth**

</td>  
<td>

Complete status of atmosphere twice a day

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

**Type and format**

</td>  
<td>

structured, CSV

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

ECMWF MARS API

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

#  Table 47. DATASET IDENTIFICATION – MARS Historical Data  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Weather

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

**Data name**

</td>  
<td>

Meteorological Archival and Retrieval System

(MARS)Historical Data

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

**Description**

</td>  
<td>

Meteorological archive of forecasts of the past 35 years and sets of
reanalysis forecasts.

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

**Provider**

</td>  
<td>

European Centre for Medium-Range Weather Forecasts (ECMWF)

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

**Contact Person**

</td>  
<td>

Aljaž Košmerlj

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

**Business Cases number**

</td>  
<td>

BC1, BC2, BC3, BC4

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

**6.8.2 Dataset ORIGIN**

This dataset is available from April 2017 and it can be defined as “core
data”. Its size is >85PT. The dataset already existed before the project.

#  Table 48 DATASET ORIGIN – MARS Historical Data

**6.8.3 Dataset FORMAT**

The dataset has CSV format. It covers information related to whole earth in
English language. The data is updated real-time.

#  Table 49 DATASET FORMAT – MARS Historical Data  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

N/A

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

**Dataset format**

</td>  
<td>

CSV

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

**Time coverage**

</td>  
<td>

past 35 years

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

**Spatial coverage**

</td>  
<td>

Global

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

**Languages**

</td>  
<td>

English

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

**Identifiability of data**

</td>  
<td>

Yes

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

**Naming convention**

</td>  
<td>

/{country}/YYYY/MM/DD.CSV

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

**Versioning**

</td>  
<td>

Real-time

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.8.4 Dataset ACCESS**

The dataset is private, but it is accessible to all the consortium members.
The data will be made available by API access.

#  Table 50 MAKING DATA ACCESSIBLE – MARS Historical Data  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: ECMWF. Access: All members

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

**Availability (public | private)** 
</td>  
<td>

private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

API access

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

**Tools to access**

</td>  
<td>

REST API, Python API

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

**Dataset source URL**

</td>  
<td>

http://apps.ecmwf.int/mars-catalogue/

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

**Access restrictions**

</td>  
<td>

Credentials

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

**Keyword/Tags**

</td>  
<td>

weather, climate

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

**Archiving and preservation**

</td>  
<td>

ECMWF maintained archive

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

#  Table 51 MAKING DATA INTEROPERABLE – MARS Historical Data  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

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

</td>  
<td>

•

</td>  
<td>

References to shared systems of identifiers and standard data types

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

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

</td>  
<td>

•

</td>  
<td>

Wikipedia entities

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

**6.8.5 Dataset SECURITY**

The dataset does not contain PD.

#  Table 52 DATASET SECURITY – MARS Historical Data  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

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

**Data recovery and secure storage**

</td>  
<td>

yes, both managed by ECMWF

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

**Privacy management procedures**

</td>  
<td>

N/A

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N/A

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N/A

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

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

**6.8.6 Ethics and Legal requirements**

Based on the above dataset description, the dataset “MARS Historical Data”
does not contain personal data, therefore the national and European legal
framework that regulates the use of personal data does not apply and copy of
opinion is not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.

**6.9 CE Dataset - Products and Categories: Product Attributes**

**6.9.1 Dataset IDENTIFICATION**

The dataset “Product attributes” is proprietary and contains information about
individual attributes for various products.

#  Table 53. DATASET IDENTIFICATION – Product Attributes  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Products and categories

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

**Data name**

</td>  
<td>

Product attributes

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

**Description**

</td>  
<td>

A collection of product attributes (varying from generic such as name, EAN,
brand, categorization and color to more specific as dimensions or technical
specifications). Data is collected from more than one thousand online stores
in 5 countries and then automatically and manually merged into an organized
dataset.

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

**Provider**

</td>  
<td>

Ceneje

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

**Contact Person**

</td>  
<td>

David Creslovnik Uros Mevc

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

**Business Cases number**

</th>  
<th>

BC1

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

**6.9.2 Dataset ORIGIN**

This dataset is available from January 2017 and it can be defined as “core
data”. The dataset already existed before the project.

#  Table 54 DATASET ORIGIN - Product Attributes  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

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

**Core Data (Y|N)**

</td>  
<td>

Y

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

**Size**

</td>  
<td>

12 million products

10 million product specifications

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

**Growth**

</td>  
<td>

10000 new products per day

7000 product specifications per day

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

**Type and format**

</td>  
<td>

structured tabular data

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

SQL tables

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

**6.9.3 Dataset FORMAT**

The dataset collects data starting from 2016 and related to Country in
Slovenian, Croatian, Serbian language. The data is updated Daily.

#  Table 55 DATASET FORMAT – Product Attributes  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

Product attributes

  * IdProduct (INT) 

  

  * NameProduct (STRING) 

  

  * L1 (STRING) 

  

  * L2 (STRING) 

  

  * L3 (STRING) 

  

  * AttName (STRING) 

  

  * AttValue (STRING) 

  

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

**Dataset format**

</td>  
<td>

SQL: tabular

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

**Time coverage**

</td>  
<td>

since 2016

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

**Spatial coverage**

</td>  
<td>

Country

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

**Languages**

</td>  
<td>

slovenian, croatian, serbian

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

**Identifiability of data**

</td>  
<td>

Yes

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

**Naming convention**

</td>  
<td>

/{country}/product_attributes.tsv

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

**Versioning**

</td>  
<td>

Daily (every day the dataset contains full generated data)

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.9.4 Dataset ACCESS**

The dataset is private, but it is accessible to all the consortium members.
The data will be made available through File download.

#  Table 56 MAKING DATA ACCESSIBLE – Product Attributes  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: Ceneje.

Access: All members

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

**Availability (public | private)**

</td>  
<td>

private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

File download (zip)

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

**Tools to access**

</td>  
<td>

WGET/Curl

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

**Dataset source URL**

</td>  
<td>

AWS or Ceneje static content server

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

**Access restrictions**

</td>  
<td>

Credentials

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

**Keyword/Tags**

</td>  
<td>

N/A

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

**Archiving and preservation**

</td>  
<td>

NO (can be generated on demand)

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

#  Table 57 MAKING DATA INTEROPERABLE – Product Attributes  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Publication as linked data (RDF-ization)

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

</td>  
<td>

•

</td>  
<td>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Interlinked product classification

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

</td>  
<td>

•

</td>  
<td>

Linked product data

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

**6.9.5 Dataset SECURITY**

The dataset does not contain PD.

#  Table 58 DATASET SECURITY – Product Attributes  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

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

**Data recovery and secure storage**

</td>  
<td>

Secure storage, regular backups

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

**Privacy management procedures**

</td>  
<td>

N/A

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

Product level

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

**6.9.6 Ethics and Legal requirements**

Based on the above dataset description, the dataset “Product Attributes” does
not contain personal data, therefore the national and European legal framework
that regulates the use of personal data does not apply and copy of opinion is
not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.10 JSI Dataset - Media: Event Registry**

**6.10.1 Dataset IDENTIFICATION**

The dataset “Event Registry” is proprietary and contains clustered information
about events based on news articles online.

#  Table 59. DATASET IDENTIFICATION – Event Registry  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Dataset Media

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

**Data name**

</td>  
<td>

Event Registry

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

**Description**

</td>  
<td>

A registry of news articles which are automatically clustered into events -
sets of articles about the same real-world event. The articles are collected
from over 150 thousand sources from all over the world and in 21 languages.
Article text is processed and annotated using a linguistic and semantic
analysis pipeline. The articles and events are linked based on content
similarity. These links are made automatically and across different languages.

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

**Provider**

</td>  
<td>

JSI

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

**Contact Person**

</td>  
<td>

Aljaž Košmerlj

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

**Business Cases number**

</td>  
<td>

BC1, BC2, BC3, BC4

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

**6.10.2**

</td>  
<td>

**Dataset ORIGIN**

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

This dataset is available from January 2017 and it can be defined as “core
data”. The dataset already existed before the project.

#  Table 60 DATASET ORIGIN – Event Registry  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

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

**Core Data (Y|N)**

</td>  
<td>

Y

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

**Size**

</td>  
<td>

136 million articles and 4.8 million events

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

**Growth**

</td>  
<td>

150 thousand articles and 400 events added per day

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

**Type and format**

</td>  
<td>

text + metadata

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

online news sites, Event Registry API

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

**6.10.3**

</td>  
<td>

**Dataset FORMAT**

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

The dataset collects data starting from December 2013, related to whole earth
in many languages.

The data is updated real-time.

#  Table 61 DATASET FORMAT – Event Registry  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

Full documentation available at:
_https://github.com/EventRegistry/eventregistry-python/wiki/Data-models_

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

**Dataset format**

</td>  
<td>

JSON

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

**Time coverage**

</td>  
<td>

since December 2013

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

**Spatial coverage**

</td>  
<td>

Whole Earth

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

**Languages**

</td>  
<td>

English, German, Spanish, Catalan, Portuguese, Italian, French, Russian,
Chinese, Slovene, Croatian, Serbian, Arabic, Turkish, Persian, Armenian,
Kurdish, Lithuanian, Somali, Urdu, Uzbek

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

**Identifiability of data**

</td>  
<td>

Y

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

**Naming convention**

</td>  
<td>

Wikipedia URIs

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

**Versioning**

</td>  
<td>

Real-time

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.10.4**

</td>  
<td>

**Dataset ACCESS**

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

The dataset is private, but it is accessible to all the consortium members.
The data will be made available through API access.

#  Table 62 MAKING DATA ACCESSIBLE – Event Registry  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: JSI

Access: All members

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

**Availability (public | private)**

</td>  
<td>

limited open and private (subscription-based); full access will be available
to project members

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

API access

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

**Tools to access**

</td>  
<td>

REST, Python API

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

**Dataset source URL**

</td>  
<td>

_http://eventregistry.org/_

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

**Access restrictions**

</td>  
<td>

Credentials

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

**Keyword/Tags**

</td>  
<td>

news, articles, events

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

**Archiving and preservation**

</td>  
<td>

long-term database storage

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

#  Table 63 MAKING DATA INTEROPERABLE – Event Registry  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

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

</td>  
<td>

•

</td>  
<td>

References to shared systems of identifiers and standard data types

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

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

</td>  
<td>

•

</td>  
<td>

Wikipedia entities

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

**6.10.5**

</td>  
<td>

**Dataset SECURITY**

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

The dataset does not include PD collected directly from its users. The dataset
contains only publicly available PD (mentions of natural persons in news
articles) as part of its news archive. PD can be removed upon request by any
individual.

#  Table 64 DATASET SECURITY – Event Registry  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

N

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

**Data recovery and secure storage**

</td>  
<td>

Secure storage, no sensitive data, local backups

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

**Privacy management procedures**

</td>  
<td>

"Right to be forgotten" guaranteed

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

**PD at the source (Y|N)**

</td>  
<td>

Y

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N/A

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N/A

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

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

**6.10.6**

</td>  
<td>

**Ethics and Legal requirements**

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

JSI has already obtained an opinion of the Slovenian Information Commissioner
regarding use of Event Registry data in another EU project. (H2020 project
RENOIR, grant agreement No 691152). A copy of this opinion and an explanation
why it is applicable also for the EW-Shopp project are included in deliverable
[D7.2]. The opinion states that even though Event Registry collects and
indexes news data which is publicly available, it may still constitute as
processing of personal data and some users may want to have their data removed
from the index. This is the so-called “right to be forgotten” which must also
be offered by web search engines such as Google. It can be defined as “the
right to silence on past events in life that are no longer occurring” and
allows individuals to have information about themselves deleted from certain
internet records so that they cannot be found by search engines. To comply
with this, Event Registry supports the option to request a removal of personal
links from its index. The Information Commissioner does not foresee any other
necessary privacy protection measures.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.11 GfK Dataset - Consumer data: Consumer data**

**6.11.1 Dataset IDENTIFICATION**

The dataset “Consumer data” is proprietary and contains clustered information
about events based on news articles online.

#  Table 65. DATASET IDENTIFICATION – Consumer data  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Consumer data

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

**Data name**

</td>  
<td>

Consumer data

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

**Description**

</td>  
<td>

TV Behavior & Exposure, Online Behavior & Exposure, HH

& Individual Purchase Level, Mobile Usage, Household & Individual Demographic
and Segmentation Information in Italy, Poland, Netherlands and Italy.

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

**Provider**

</td>  
<td>

GfK

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

**Contact Person**

</td>  
<td>

Stefano Albano

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

**Business Cases number**

</td>  
<td>

BC2

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

**6.11.2**

</td>  
<td>

**Dataset ORIGIN**

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

The dataset is available from May 2017 and it can’t be defined as “core data”.
Its size is of 80GB with a growth of 40GB per year. The dataset already
existed before the project.

#  Table 66 DATASET ORIGIN – Consumer data  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M5

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

**Core Data (Y|N)**

</td>  
<td>

N

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

**Size**

</td>  
<td>

80GB

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

**Growth**

</td>  
<td>

40GB per year

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

**Type and format**

</td>  
<td>

structured tabular data, CSV

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

GfK receive the data directly form the panelists that are connected to GfK via
GPRS technology with an ad hoc tablet / via web with a PC/Laptop / via
smartphone. Data are collected actively (with a questionnaires) or passively
(installed apps). Data are anonymized and stored in GfK’s storage systems.

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

**6.11.3**

</td>  
<td>

**Dataset FORMAT**

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

The dataset has a CSV format. It collects numerical data since 2016 and it
covers information related to Italy, Germany, Poland, Netherlands. The data is
updated monthly.

#  Table 67 DATASET FORMAT – Consumer data  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

Data are stored in data warehouse and can be extracted or visualized through a
software.

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

**Dataset format**

</td>  
<td>

structured tabular data, CSV

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

**Time coverage**

</td>  
<td>

Monthly / daily data since 2016

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

**Spatial coverage**

</td>  
<td>

Italy, Germany, Poland, Netherlands

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

**Languages**

</td>  
<td>

EN (numerical data)

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

**Identifiability of data**

</td>  
<td>

N/A

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

**Naming convention**

</td>  
<td>

Static DB

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

**Versioning**

</td>  
<td>

Monthly

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.11.4**

</td>  
<td>

**Dataset ACCESS**

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

The dataset is private and it is not available to consortium members.

#  Table 68 MAKING DATA ACCESSIBLE – Consumer data  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Available only for GfK

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

**Availability (public | private)** 
</td>  
<td>

private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

N

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

**Availability method**

</td>  
<td>

N/A

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

**Tools to access**

</td>  
<td>

N/A

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

**Dataset source URL**

</td>  
<td>

N/A

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

**Access restrictions**

</td>  
<td>

N/A

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

**Keyword/Tags**

</td>  
<td>

N/A

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

**Archiving and preservation**

</td>  
<td>

N/A

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

#  Table 69 MAKING DATA INTEROPERABLE – Consumer data  
  
<table>  
<tr>  
<th>

**Data**

**interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

• •

</td>  
<td>

Interlinked product classification Linked product data

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

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

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

**6.11.5**

</td>  
<td>

**Dataset SECURITY**

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

The dataset does not contain PD because those data was removed at the source.

#  Table 70 DATASET SECURITY – Consumer data  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

Y

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

**Data recovery and secure storage**

</td>  
<td>

Y

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

**Privacy management procedures**

</td>  
<td>

See 6.11.6

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

**PD at the source (Y|N)**

</td>  
<td>

Y

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

Y

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

Data are not aggregated

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

**6.11.6**

</td>  
<td>

**Ethics and Legal requirements**

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

GfK collects the data according the current Privacy law, asking each panelist
the consent to transfer the data to GfK for data analysis. GfK has performed
notification to the National Data Protection Authority (attached in [D7.2]).

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.12 GfK Dataset - Market data: Sales data**

**6.12.1 Dataset IDENTIFICATION**

The dataset “Sales data” contains monthly data (in value / number) of Consumer
Electronic, Information Technology, Telecommunication, Major Domestic
Appliances and Small Domestic Appliances products.

#  Table 71. Dataset IDENTIFICATION – Sales data  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Market data

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

**Data name**

</td>  
<td>

Sales data

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

**Description**

</td>  
<td>

Monthly data (in value / number) of Consumer

Electronics, Information Technology,

Telecommunication, Major Domestic Appliances and Small Domestic Appliances
products.

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

**Provider**

</td>  
<td>

GfK

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

**Contact Person**

</td>  
<td>

Alessandro De Fazio

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

**Business Cases number**

</td>  
<td>

BC1, BC2, BC3

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

**6.12.2**

</td>  
<td>

**Dataset ORIGIN**

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

The dataset is available from January 2017 and it can’t be defined as “core
data”. Its size is of 80GB with a growth of 5GB per country per year.

#  Table 72 DATASET ORIGIN – Sales data  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

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

**Core Data (Y|N)**

</td>  
<td>

N

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

**Size**

</td>  
<td>

80GB per country

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

**Growth**

</td>  
<td>

5GB per country per year

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

**Type and format**

</td>  
<td>

structured tabular data, CSV

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

GfK receive from the POS sales data split per product in different formats
(electronic and manual). Data are checked, verified and uploaded into a tool
where the data are connected to the product sheet. The data are collected on a
representative sample of POS and are exploded to the universe.

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

**6.12.3**

</td>  
<td>

**Dataset FORMAT**

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

The dataset has a CSV format. It collects data since 2004 related to all
European countries (except:

Albania, Kosovo, Macedonia and Montenegro). The data is updated monthly.

#  Table 73 DATASET FORMAT – Sales data  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

Data are stored in a global data warehouse accessible on line. The inputs are
four dimensions Product, Time, Facts, Channels that can be processed like an
excel pivot table.

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

**Dataset format**

</td>  
<td>

structured tabular data, CSV

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

**Time coverage**

</td>  
<td>

Monthly data since 2004

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

**Spatial coverage**

</td>  
<td>

All European (except: Albania, Kosovo, Macedonia and Montenegro)

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

**Languages**

</td>  
<td>

English

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

**Identifiability of data**

</td>  
<td>

Yes

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

**Naming convention**

</td>  
<td>

Static DB

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

**Versioning**

</td>  
<td>

Monthly

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.12.4**

</td>  
<td>

**Dataset ACCESS**

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

The dataset is private and it is available only for Università Bicocca. The
data is available through ftp but username and password are required.

#  Table 74 MAKING DATA ACCESSIBLE – Sales data  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

The data will be transferred to Università Bicocca for data analysis while the
analysis (not the data) will be transferred by Università Bicocca to the
consortium.

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

**Availability (public | private)** 
</td>  
<td>

Private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

CSV files via ftp

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

**Tools to access**

</td>  
<td>

No

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

**Dataset source URL**

</td>  
<td>

FTP

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

**Access restrictions**

</td>  
<td>

username and password needed to access ftp

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

**Keyword/Tags**

</td>  
<td>

sales data

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

**Archiving and preservation**

</td>  
<td>

N/A

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

#  Table 75 MAKING DATA INTEROPERABLE – Sales data  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Publication as linked data (RDF-ization)

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

</td>  
<td>

•

</td>  
<td>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Interlinked product classification

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

</td>  
<td>

•

</td>  
<td>

Linked product data

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

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

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

**6.12.5**

</td>  
<td>

**Dataset SECURITY**

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

The dataset does not contain PD.

#  Table 76 DATASET SECURITY – Sales data  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

N

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

**Data recovery and secure storage**

</td>  
<td>

N/A

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

**Privacy management procedures**

</td>  
<td>

N/A

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N/A

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

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

**6.12.6**

</td>  
<td>

**Ethics and Legal requirements**

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

Based on the above dataset description, the dataset “Sales Data” does not
contain personal data, therefore the national and European legal framework
that regulates the use of personal data does not apply and copy of opinion is
not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.13 GfK Dataset – Products & Categories: Product attributes **

**6.13.1 Dataset IDENTIFICATION**

The dataset “Product attributes” contains Technical Product Data Sheets of all
the products of Consumer Electronics, IT, Telecommunication, Major domestic
appliances, Small domestic Appliances sectors.

#  Table 77. DATASET IDENTIFICATION – Product attributes  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Products & Categories

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

**Data name**

</td>  
<td>

Product attributes

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

**Description**

</td>  
<td>

Technical Product Data Sheets of all the products of Consumer Electronics, IT,
Telecommunication, Major domestic appliances, Small domestic Appliances
sectors. Products sheets are defined within the GfK

categorization and include: Brand, Product name, Model, ID, data, EAN code (on
80% of the products) and Technical features.

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

**Provider**

</td>  
<td>

GfK

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

**Contact Person**

</td>  
<td>

Marco Tobaldo

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

**Business Cases number**

</td>  
<td>

BC1, BC2, BC4

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

**6.13.2**

</th>  
<th>

**Dataset ORIGIN**

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

The dataset is available from February 2017 and it can be defined as “core
data”. Its size is of 2GB per country (Germany, UK, Italy) with a growth of 2%
per year.

#  Table 78 DATASET ORIGIN – Product attributes  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M2

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

**Core Data (Y|N)**

</td>  
<td>

Y

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

**Size**

</td>  
<td>

2GB per country (Germany, UK, Italy)

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

**Growth**

</td>  
<td>

2% per year

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

**Type and format**

</td>  
<td>

Relational

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

GfK receive the data of all the sold products in POS. When there is a new
product GfK set its sheet getting the features of the product from the
manufacturer. All the sheets are created manually, according the GfK data
plan, in the country where the new product has been sold.

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

**6.13.3**

</td>  
<td>

**Dataset FORMAT**

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

The dataset has a CSV or xml format. It collects product data since 1982 and
has a European coverage. The dataset is updated daily (every day the dataset
contains only the data newly generated).

#  Table 79 DATASET FORMAT – Product attributes  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

We describe here the main structure of the relational database (RDB), by
describing the four CSV files that we extract from it and share in EW-Shopp:

Country_EWS_2017_12_31_Feature_Data.txt (Value of the technical features of
the products)

Country_EWS_2017_12_31_Feature_List.txt (name of the features of the products)

Country_EWS_2017_12_31_Feature_Value_List.txt (code frame of the features)

Country_EWS_2017_12_31_Master_Data.txt (main information about the products)

Country_EWS_2017_12_31_Productgroup_Feature_List.txt (list of the technical
features available for each product)

Each file contains several columns, thus for the complete structure we refer
to documentation in "Spex_retail_CSVrelationalidbased.pdf" shared with the
consortium.

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

**Dataset format**

</td>  
<td>

structured (R-DB), CSV o xml

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

**Time coverage**

</td>  
<td>

The dataset includes product data since 1982 and it is daily updated

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

**Spatial coverage**

</td>  
<td>

European coverage: Austria, Belgio, Danimarca, Finlandia, Francia, Germania,
UK, Grecia, Italia, Lussemburgo, Olanda, Polonia, Portogallo, Repubblica ceca,
Slovacchia, Italia, Svezia, , Norvegia, Ungheria. Catalog not available in
Irlanda,

Slovenia, Croazia. Bulgaria, Cipro, Estonia, Lettonia, Lituania, Malta,
Romania,

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

**Languages**

</td>  
<td>

Arabic, Czech, Chinese, Korean, Danish, French, Greek, English, Italian,
Dutch, Polish, Portuguese, Russian, Slovak, Spanish, Swedish, German, Turkish,
Hungarian

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

**Identifiability of data**

</td>  
<td>

Yes

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

**Naming convention**

</td>  
<td>

Country_EWS_2017_12_31_Feature_Data.txt

Country_EWS_2017_12_31_Feature_List.txt

Country_EWS_2017_12_31_Feature_Value_List.txt

Country_EWS_2017_12_31_Master_Data.txt

Country_EWS_2017_12_31_Productgroup_Feature_List.txt

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

**Versioning**

</td>  
<td>

Daily (every day the dataset contains only the data newly generated).
Overwrite old data.

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.13.4**

</td>  
<td>

**Dataset ACCESS**

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

The dataset is private and it is available to all consortium members. The data
are available through ftp.

#  Table 80 MAKING DATA ACCESSIBLE – Product attributes  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Private license: The data will be transferred to Università Bicocca for data
analysis while the analysis (not the data) will be transferred by Università
Bicocca to the consortium

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

**Availability (public | private)**

</td>  
<td>

Private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

ftp

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

**Tools to access**

</td>  
<td>

No tools

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

**Dataset source URL**

</td>  
<td>

It will be created when needed

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

**Access restrictions**

</td>  
<td>

username and password needed to access ftp

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

**Keyword/Tags**

</td>  
<td>

product categories / product features / value

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

**Archiving and preservation**

</td>  
<td>

Regular disaster recovery / backup on original data

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

#  Table 81 MAKING DATA INTEROPERABLE – Product attributes  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Publication as linked data (RDF-ization)

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

</td>  
<td>

•

</td>  
<td>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Interlinked product classification

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

</td>  
<td>

•

</td>  
<td>

Linked product data

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

**6.13.5**

</td>  
<td>

**Dataset SECURITY**

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

The dataset does not contain PD.

#  Table 82 DATASET SECURITY – Product attributes  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

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

**Data recovery and secure storage**

</td>  
<td>

N/A

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

**Privacy management procedures**

</td>  
<td>

N/A

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N/A

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N/A

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

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

**6.13.6**

</td>  
<td>

**Ethics and Legal requirements**

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

Based on the above dataset description, the dataset “Product attributes” does
not contain personal data, therefore the national and European legal framework
that regulates the use of personal data does not apply and copy of opinion is
not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.14 ME Dataset - Consumer Data: Door counter data**

**6.14.1 Dataset IDENTIFICATION**

The dataset “Door counter data” contains data from customers' door counters.

#  Table 83. DATASET IDENTIFICATION – Door counter data  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Consumer Data

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

**Data name**

</td>  
<td>

Door counter data

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

**Description**

</td>  
<td>

Data from customers' door counters

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

**Provider**

</td>  
<td>

Measurence

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

**Contact Person**

</td>  
<td>

Olga Melnyk

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

**Business Cases number**

</td>  
<td>

BC3

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

**6.14.2**

</td>  
<td>

**Dataset ORIGIN**

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

The dataset is available from January 2017 and it can’t be defined as “core
data”. Its size is of 2Mb with a growth of 60kB/mb/location. The dataset
already existed.

#  Table 84 DATASET ORIGIN – Door counter data  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

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

**Core Data (Y|N)**

</td>  
<td>

N

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

**Size**

</td>  
<td>

2Mb

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

**Growth**

</td>  
<td>

60kB/mb/location

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

**Type and format**

</td>  
<td>

structured data

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

Measurence's customers own data

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

**6.14.3**

</th>  
<th>

**Dataset FORMAT**

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

The dataset has a CSV format. It collects numerical data since 2016 related to
Milan area. The dataset is updated daily.

#  Table 85 DATASET FORMAT – Door counter data  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

N/A because there is no access to the data through URL

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

**Dataset format**

</td>  
<td>

CSV

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

**Time coverage**

</td>  
<td>

2016

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

**Spatial coverage**

</td>  
<td>

Milan

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

**Languages**

</td>  
<td>

EN (numerical data)

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

**Identifiability of data**

</td>  
<td>

N/A

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

**Naming convention**

</td>  
<td>

/location_idYYYY/MM/week

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

**Versioning**

</td>  
<td>

Daily

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.14.4**

</th>  
<th>

**Dataset ACCESS**

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

The dataset is private and it is not available to all consortium members.

#  Table 86 MAKING DATA ACCESSIBLE – Door counter data  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: ME.

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

**Availability (public | private)** 
</td>  
<td>

Private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

N

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

**Availability method**

</td>  
<td>

CSV

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

**Tools to access**

</td>  
<td>

text editor/spreadsheet

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

**Dataset source URL**

</td>  
<td>

N/A

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

**Access restrictions**

</td>  
<td>

N/A

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

**Keyword/Tags**

</td>  
<td>

door counters

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

**Archiving and preservation**

</td>  
<td>

cloud

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

#  Table 87 MAKING DATA INTEROPERABLE – Door counter data  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

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

**6.14.5**

</td>  
<td>

**Dataset SECURITY**

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

The dataset does not contain PD.

##  Table 88 DATASET SECURITY – Door counter data  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

N

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

**Data recovery and secure storage**

</td>  
<td>

Y

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

**Privacy management procedures**

</td>  
<td>

N/A

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N

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

**6.14.6**

</td>  
<td>

**Ethics and Legal requirements**

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

This dataset does not contain personal data, therefore the national and
European legal framework that regulates the use of personal data does not
apply and copy of opinion is not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.15 BB Dataset - Products and Categories: Product Attributes**

**6.15.1 Dataset IDENTIFICATION**

The dataset “Product attributes” is proprietary and contains data on product
specifications.

##  Table 89. DATASET IDENTIFICATION – Product Attributes  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Products and categories

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

**Data name**

</td>  
<td>

Product attributes

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

**Description**

</td>  
<td>

Detailed product specifications for products which are included in Big Bang's
selling portfolio (from generic to specific technical details)

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

**Provider**

</td>  
<td>

Big Bang

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

**Contact Person**

</td>  
<td>

Matija Torlak

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

**Business Cases number**

</td>  
<td>

BC1

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

**6.15.2**

</td>  
<td>

**Dataset ORIGIN**

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

The dataset is available from January 2017 and it can be defined as “core
data”. Its size is of 20000 products with a growth of 1.000 new products per
year.

##  Table 90 DATASET ORIGIN – Product Attributes  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

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

**Core Data (Y|N)**

</td>  
<td>

Y

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

**Size**

</td>  
<td>

20000 products

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

**Growth**

</td>  
<td>

1.000 new products per year

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

**Type and format**

</td>  
<td>

character and numeric

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

DWH

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

**6.15.3**

</th>  
<th>

**Dataset FORMAT**

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

The dataset has a XLS format. It collects data related to Slovenia in
Slovenian and English languages.

The dataset is updated daily.

##  Table 91 DATASET FORMAT – Product Attributes  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

BB Classification - can be mostly matched with GS1 Classification

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

**Dataset format**

</td>  
<td>

XLS, SQL, CSV

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

**Time coverage**

</td>  
<td>

All Time

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

**Spatial coverage**

</td>  
<td>

Slovenia for all Products

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

**Languages**

</td>  
<td>

Slovenian, English

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

**Identifiability of data**

</td>  
<td>

Yes

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

**Naming convention**

</td>  
<td>

BB_productCategoriesYYYY/MM/dd

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

**Versioning**

</td>  
<td>

daily (new + history)

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.15.4**

</td>  
<td>

**Dataset ACCESS**

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

The dataset is private but it is available to all consortium members. The data
is available through download by means of VPN.

##  Table 92 MAKING DATA ACCESSIBLE – Product Attributes  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: Big Bang. Access: All members

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

**Availability (public |**

**private)**

</td>  
<td>

Public, restricted with credentials

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

Download, view

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

**Tools to access**

</td>  
<td>

URL with Credentials

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

**Dataset source URL**

</td>  
<td>

URL link secured with Credentials

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

**Access restrictions**

</td>  
<td>

Credentials

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

**Keyword/Tags**

</td>  
<td>

Database Keywords

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

**Archiving and preservation**

</td>  
<td>

Secure Storage, Back up

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

##  Table 93 MAKING DATA INTEROPERABLE – Product Attributes  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Publication as linked data (RDF-ization)

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

</td>  
<td>

•

</td>  
<td>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Interlinked product classification

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

</td>  
<td>

•

</td>  
<td>

Linked product data

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

**6.15.5**

</td>  
<td>

**Dataset SECURITY**

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

The dataset does not contain PD.

##  Table 94 DATASET SECURITY – Product Attributes  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

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

**Data recovery and secure storage**

</td>  
<td>

Secure storage, daily backup

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

**Privacy management procedures**

</td>  
<td>

Data only on the level of product / category

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

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

**6.15.6**

</td>  
<td>

**Ethics and Legal requirements**

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

Based on the above dataset description, the dataset does not contain personal
data, therefore the national and European legal framework that regulates the
use of personal data does not apply and copy of opinion is not required to be
collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.16 CE Dataset - Market data: Products price history**

**6.16.1 Dataset IDENTIFICATION**

The dataset “Products price history” is proprietary and contains quotes for
various products.

#  Table 95\. DATASET IDENTIFICATION – Products price history  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Market data

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

**Data name**

</td>  
<td>

Products price history

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

**Description**

</td>  
<td>

A collection of seller quotes for products. Prices for all of Ceneje's
organized products have been recorded and regularly archived since 2016.

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

**Provider**

</td>  
<td>

Ceneje

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

**Contact Person**

</td>  
<td>

David Creslovnik Uros Mevc

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

**Business Cases number**

</td>  
<td>

BC1

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

**6.16.2**

</td>  
<td>

**Dataset ORIGIN**

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

The dataset is available from January 2017 and it can’t be defined as “core
data”. Its size is about 3 billion quotes with a growth of 2 million per day.

#  Table 96 DATASET ORIGIN - Products price history  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

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

**Core Data (Y|N)**

</td>  
<td>

N

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

**Size**

</td>  
<td>

about 3 billion quotes

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

**Growth**

</td>  
<td>

2 million per day

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

**Type and format**

</td>  
<td>

structured tabular data

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

SQL tables

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

**6.16.3**

</th>  
<th>

**Dataset FORMAT**

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

The dataset collects data related to Country area since 2016. The dataset is
updated daily.

#  Table 97 DATASET FORMAT – Products price history  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

History

  * IdProduct (INT) 

  

  * NameProduct (STRING) 

  

  * L1 (STRING) 

  

  * L2 (STRING) 

  

  * L3 (STRING) 

  

  * IdSeller (INT) 

  

  * Price (MONEY) 

  

  * Timestamp (Slovenian time GMT+1) 

  

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

**Dataset format**

</td>  
<td>

SQL: tabular (tsv)

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

**Time coverage**

</td>  
<td>

since 2016

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

**Spatial coverage**

</td>  
<td>

Country

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

**Languages**

</td>  
<td>

not language specific

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

**Identifiability of data**

</td>  
<td>

Yes

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

**Naming convention**

</td>  
<td>

{country}/YYYY/mm/DD/history.tsv

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

**Versioning**

</td>  
<td>

Daily (every day the dataset contains only the data newly generated)

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

**Metadata standards**

</td>  
<td>

N/A

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

**6.16.4**

</td>  
<td>

**Dataset ACCESS**

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

The dataset is private but it is available to all consortium members. The data
is available through file download.

#  Table 98 MAKING DATA ACCESSIBLE – Products price history  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: Ceneje

Access: All members

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

**Availability (public | private)** 
</td>  
<td>

private

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

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

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

**Availability method**

</td>  
<td>

File download (zip)

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

**Tools to access**

</td>  
<td>

WGET/Curl

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

**Dataset source URL**

</td>  
<td>

N/A

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

**Access restrictions**

</td>  
<td>

Credentials

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

**Keyword/Tags**

</td>  
<td>

N/A

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

**Archiving and preservation**

</td>  
<td>

N/A (can be generated on demand)

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

#  Table 99 MAKING DATA INTEROPERABLE – Products price history  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Publication as linked data (RDF-ization)

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

</td>  
<td>

•

</td>  
<td>

Semantic data enrichment

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

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Interlinked product classification

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

</td>  
<td>

•

</td>  
<td>

Linked product data

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

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

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

**6.16.5**

</td>  
<td>

**Dataset SECURITY**

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

The dataset does not contain PD.

#  Table 100 DATASET SECURITY – Products price history  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

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

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

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

**Data recovery and secure storage**

</td>  
<td>

Secure storage, regular backups

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

**Privacy management procedures**

</td>  
<td>

N/A

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

**PD at the source (Y|N)**

</td>  
<td>

N

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

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

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

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

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

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

Product|Seller level

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

**6.16.6**

</th>  
<th>

**Ethics and Legal requirements**

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

Based on the above dataset description, the dataset “Products price history”
does not contain personal data, therefore the national and European legal
framework that regulates the use of personal data does not apply and copy of
opinion is not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.17 ME Dataset - Consumer Data: Sales data**

**6.17.1 Dataset IDENTIFICATION**

The dataset “Sales data” contains number of receipts get from customers.

#  Table 101. DATASET IDENTIFICATION – Sales data  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Consumer Data

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

**Data name**

</td>  
<td>

Sales data

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

**Description**

</td>  
<td>

number of receipts we get from our customers

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

**Provider**

</td>  
<td>

Measurence

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

**Contact Person**

</td>  
<td>

Olga Melnyk

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

**Business Cases number**

</td>  
<td>

BC2

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

**6.17.2**

</td>  
<td>

**Dataset ORIGIN**

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

The dataset is available from January 2017 and it can’t be defined as “core
data”. Its size is about 2Mb with a growth of 60kB/mb/location.

#  Table 102 DATASET ORIGIN \- Sales data  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

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

**Core Data (Y|N)**

</td>  
<td>

N

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

**Size**

</td>  
<td>

2Mb

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

**Growth**

</td>  
<td>

60kB/mb/location

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

**Type and format**

</td>  
<td>

structured data

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

**Existing data (Y|N)**

</td>  
<td>

Y

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

**Data origin**

</td>  
<td>

Measurence customers' own data

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

**6.17.3**

</th>  
<th>

**Dataset FORMAT**

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

The dataset collects data related to Milan area since 2016. The dataset is
updated weekly.

#  Table 103 DATASET FORMAT – Sales data  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

N/A because there is no access to the data through URL

</th> </tr>  
<tr>  
<td>

**Dataset format**

</td>  
<td>

CSV

</td> </tr>  
<tr>  
<td>

**Time coverage**

</td>  
<td>

2016

</td> </tr>  
<tr>  
<td>

**Spatial coverage**

</td>  
<td>

Milan

</td> </tr>  
<tr>  
<td>

**Languages**

</td>  
<td>

EN (numerical data)

</td> </tr>  
<tr>  
<td>

**Identifiability of data**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Naming convention**

</td>  
<td>

/location_id/YYYY/MM/week

</td> </tr>  
<tr>  
<td>

**Versioning**

</td>  
<td>

weekly

</td> </tr>  
<tr>  
<td>

**Metadata standards**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**6.17.4**

</td>  
<td>

**Dataset ACCESS**

</td> </tr> </table>

The dataset is private and it is not available to consortium members.

#  Table 104 MAKING DATA ACCESSIBLE – Sales data  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: ME

</th> </tr>  
<tr>  
<td>

**Availability (public | private)** 
</td>  
<td>

private

</td> </tr>  
<tr>  
<td>

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Availability method**

</td>  
<td>

CSV

</td> </tr>  
<tr>  
<td>

**Tools to access**

</td>  
<td>

text editor/spreadsheet

</td> </tr>  
<tr>  
<td>

**Dataset source URL**

</td>  
<td>

N/A because company’s dataset is not available through URL

</td> </tr>  
<tr>  
<td>

**Access restrictions**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Keyword/Tags**

</td>  
<td>

receipts

</td> </tr>  
<tr>  
<td>

**Archiving and preservation**

</td>  
<td>

Cloud

</td> </tr> </table>

#  Table 105 MAKING DATA INTEROPERABLE – Sales data  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

</th> </tr>  
<tr>  
<td>

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

</td> </tr> </table>  
<table>  
<tr>  
<th>

**6.17.5**

</th>  
<th>

**Dataset SECURITY**

</th> </tr> </table>

The dataset does not contain PD.

#  Table 106 DATASET SECURITY – Sales data  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

</th> </tr>  
<tr>  
<td>

**Anonymized (Y|N|NA)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Data recovery and secure storage**

</td>  
<td>

Y

</td> </tr>  
<tr>  
<td>

**Privacy management procedures**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD at the source (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**6.17.6**

</td>  
<td>

**Ethics and Legal requirements**

</td> </tr> </table>

This dataset does not contain personal data, therefore the national and
European legal framework that regulates the use of personal data does not
apply and copy of opinion is not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.18 JOT Dataset - Consumer data: Traffic source (Bing)**

**6.18.1 Dataset IDENTIFICATION**

The dataset “Traffic sources (Bing)”, provided by JOT, focuses on historical
campaign performance statistics of search data in Bing advertising platforms.

#  Table 107 DATASET IDENTIFICATION – Traffic source (Bing)  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Consumer Data

</th>  
<th>

</th> </tr>  
<tr>  
<td>

**Data name**

</td>  
<td>

Traffic sources (Bing)

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Description**

</td>  
<td>

Historical campaign performance statistics search data in Bing advertising
platforms

</td>  
<td>

of

</td> </tr>  
<tr>  
<td>

**Provider**

</td>  
<td>

JOT

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Contact Person**

</td>  
<td>

Ignacio Martínez / Elías Badenes

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Business Cases number**

</td>  
<td>

BC4

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**6.18.2**

</td>  
<td>

**Dataset ORIGIN**

</td> </tr> </table>

This dataset is available from February 2017 and it cannot be defined as “core
data”. It has a structured format with a size of 1 TB and a growth of 1.5GB
daily. The dataset is generated expressly for the project’s purpose in CSV
format.

#  Table 108 DATASET ORIGIN - Traffic source (Bing)  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M2

</th> </tr>  
<tr>  
<td>

**Core Data (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Size**

</td>  
<td>

1 TB

</td> </tr>  
<tr>  
<td>

**Growth**

</td>  
<td>

1.5GB daily

</td> </tr>  
<tr>  
<td>

**Type and format**

</td>  
<td>

structured, CSV

</td> </tr>  
<tr>  
<td>

**Existing data (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Data origin**

</td>  
<td>

BING API

</td> </tr>  
<tr>  
<td>

**6.18.3**

</td>  
<td>

**Dataset FORMAT**

</td> </tr> </table>

The dataset “Traffic source (Bing)” has a CSV format, the data structure is
illustrated in the following table. It collects data gathered from different
European countries, in different language (German, Spanish, French, English),
since 2016 and it covers information related to City/Region/Country. The data
is updated daily that means every day the dataset contains only the data newly
generated.

#  Table 109 DATASET FORMAT – Traffic source (Bing)  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

Country: Country where the campaign is oriented.

Language: Language of the keywords and ads.

Category: Topic of the keyword. We have 22 categories such as Travel, Finance,
Vehicles and so forth  48

Campaign Name: An account is form by campaigns. The name of these campaign
contains some information like the language or the category. AdgroupId: Number
given by Bing that identify an ad group. A campaign is form by ad groups.

AdNetworkType2: The network where keywords appear. It can be Bing search (the
typical bing search engine in www.bing.com) or partner network (other webpages
with the bing search box).

Clicks: When a user clicks your ad.

Impressions: Each time your ad is served and appears on the web.

Date: Date (XXXX/XX/XX) when the ad appears.

DayOfWeek: Day of the week when the ad appears.

Device: The device (PC, Tablet, Mobile) where the ad appears.

</th> </tr>  
<tr>  
<td>

</td>  
<td>

MonthOfYear: Month of the year when the ad appears.

Keyword: It’s the search that the user types.

Bing_posicion_anuncio (Bing_Ad_Position): Position of the ad in the browser.

Location: City/Region/Country

Concordancia (Match type): Match type of the keyword. It shows how similar
needs to be the query of a user to show an ad

</td> </tr>  
<tr>  
<td>

**Dataset format**

</td>  
<td>

CSV

</td> </tr>  
<tr>  
<td>

**Time coverage**

</td>  
<td>

since 2016

</td> </tr>  
<tr>  
<td>

**Spatial coverage**

</td>  
<td>

City/Region/Country

</td> </tr>  
<tr>  
<td>

**Languages**

</td>  
<td>

German, Spanish, French, English

</td> </tr>  
<tr>  
<td>

**Identifiability of data**

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

**Naming convention**

</td>  
<td>

BING_YYMMDD_XX

</td> </tr>  
<tr>  
<td>

**Versioning**

</td>  
<td>

Daily (every day the dataset contains only the data newly generated)

</td> </tr>  
<tr>  
<td>

**Metadata standards**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**6.18.4**

</td>  
<td>

**Dataset ACCESS**

</td> </tr> </table>

The dataset is private, but it is accessible to all the consortium members.
The data will be made available through File-download by means of FTP Client.
Dataset are deposited on Azure Platform and the access is provided by
credentials.

#  Table 110 MAKING DATA ACCESSIBLE – Traffic source (Bing)  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: JOT. Access: All members

</th> </tr>  
<tr>  
<td>

**Availability (public | private)** 
</td>  
<td>

private

</td> </tr>  
<tr>  
<td>

**Availability to EW-Shopp**

**partners (Y|N)**

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

**Availability method**

</td>  
<td>

File-download

</td> </tr>  
<tr>  
<td>

**Tools to access**

</td>  
<td>

FTP Client (Open Source) or Web Page

</td> </tr>  
<tr>  
<td>

**Dataset source URL**

</td>  
<td>

Azure platform. The URL will be created when needed.

</td> </tr>  
<tr>  
<td>

**Access restrictions**

</td>  
<td>

Credentials

</td> </tr>  
<tr>  
<td>

**Keyword/Tags**

</td>  
<td>

Online Searches (Keywords)

</td> </tr>  
<tr>  
<td>

**Archiving and preservation**

</td>  
<td>

5 years after project end

</td> </tr> </table>

#  Table 111 MAKING DATA INTEROPERABLE – Traffic source (Bing)  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

</th> </tr>  
<tr>  
<td>

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

</td> </tr>  
<tr>  
<td>

**6.18.5**

</td>  
<td>

**Dataset SECURITY**

</td> </tr> </table>

The dataset “Traffic source (Bing)” does not contain personal data. It is
expected a secure storage and JOT data recovery.

#  Table 112 DATASET SECURITY –Traffic source (Bing)  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

</th> </tr>  
<tr>  
<td>

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Data recovery and secure storage**

</td>  
<td>

Secure storage, no sensitive data, JOT data recovery

</td> </tr>  
<tr>  
<td>

**Privacy management procedures**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD at the source (Y|N)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD - anonymised during project (Y|N)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD - anonymised before project (Y|N)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**6.18.6**

</td>  
<td>

**Ethics and Legal requirements**

</td> </tr> </table>

All the data that JOT Internet is generating, sharing and processing (in
compliance with Spanish Organic Law 15/1999 for personal data protection,
ISO/IEC 2382-1 and the General Data Protection Regulation (GDPR)) for the
purpose of EW Shopp project does not include personal data. For that reason,
JOT believe that data managed in the project does not include any personal
data and that is why no further action is needed.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.19 JOT Dataset - Consumer data: Traffic source (Google)**

**6.19.1 Dataset IDENTIFICATION**

The dataset “Traffic sources (Google)”, provided by JOT, focuses on historical
campaign performance statistics of search data in Google platforms.

#  Table 113 DATASET IDENTIFICATION – Traffic source (Google)  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Consumer Data

</th> </tr>  
<tr>  
<td>

**Data name**

</td>  
<td>

Traffic sources (Google)

</td> </tr>  
<tr>  
<td>

**Description**

</td>  
<td>

Historical campaign performance statistics of data in Google platform.

</td> </tr>  
<tr>  
<td>

**Provider**

</td>  
<td>

JOT

</td> </tr>  
<tr>  
<td>

**Contact Person**

</td>  
<td>

Ignacio Martínez/ Elías Badenes

</td> </tr>  
<tr>  
<td>

**Business Cases number**

</td>  
<td>

BC4

</td> </tr>  
<tr>  
<td>

**6.19.2**

</td>  
<td>

**Dataset ORIGIN**

</td> </tr> </table>

The dataset is available from February 2017 and it is defined as “core data”.
It has a structured format (i.e. CSV) with a size up to 3 TB and a growth of
4GB daily. The dataset is generated expressly for the project’s purpose.

#  Table 114 DATASET ORIGIN - Traffic source (Google)  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M2

</th> </tr>  
<tr>  
<td>

**Core Data (Y|N)**

</td>  
<td>

Y

</td> </tr>  
<tr>  
<td>

**Size**

</td>  
<td>

> 3TB
</td> </tr>  
<tr>  
<td>

**Growth**

</td>  
<td>

4GB daily

</td> </tr>  
<tr>  
<td>

**Type and format**

</td>  
<td>

structured, CSV

</td> </tr>  
<tr>  
<td>

**Existing data (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Data origin**

</td>  
<td>

GOOGLE API

</td> </tr>  
<tr>  
<td>

**6.19.3**

</td>  
<td>

**Dataset FORMAT**

</td> </tr> </table>

The dataset “Traffic source (Google)” has a CSV format. It collects data
gathered from different countries, in different language (German, Spanish,
Italian, Dutch, French, English, Portuguese, Russian), since 2016 and it
covers information related to City/Region/Country. The data is updated daily
that means every day the dataset contains only the data newly generated. The
data structure is illustrated in the following table.

#  Table 115 DATASET FORMAT – Traffic source (Google)  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

Country: Country where the campaign is oriented.

Language: Language of the keywords and ads.

Category: Topic of the keyword. We have 22 categories such as Travel, Finance,
Vehicles and so forth  49

Campaign Name: An account is form by campaigns. The name of these campaign
contains some information like the language or the category. AdgroupId: Number
given by Google that identify an ad group. A campaign is form by ad groups.

AdNetworkType2: The network where keywords appear. It can be Google search
(the typical google search engine in www.google.com) or partner

</th> </tr>  
<tr>  
<td>

</td>  
<td>

network (other webpages with the google search box).

Clicks: When a user clicks your ad.

Impressions: Each time your ad is served and appears on the web.

Date: Date (XXXX/XX/XX) when the ad appears.

DayOfWeek: Day of the week when the ad appears.

Device: The device (PC, Tablet, Mobile) where the ad appears.

MonthOfYear: Month of the year when the ad appears.

Keyword: It’s the search that the user types.

Google_posicion_anuncio (Google_Ad_Position): Position of the ad in the
browser.

Location: City/Region/Country

Concordancia (Match type): Match type of the keyword. It shows how similar
needs to be the query of a user to show an ad

</td> </tr>  
<tr>  
<td>

**Dataset format**

</td>  
<td>

CSV

</td> </tr>  
<tr>  
<td>

**Time coverage**

</td>  
<td>

since 2016

</td> </tr>  
<tr>  
<td>

**Spatial coverage**

</td>  
<td>

City/Region/Country

</td> </tr>  
<tr>  
<td>

**Languages**

</td>  
<td>

German, Spanish, Italian, Dutch, French, English, Portuguese, Russian

</td> </tr>  
<tr>  
<td>

**Identifiability of data**

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

**Naming convention**

</td>  
<td>

GOOGLE_YYMMDD_XX

</td> </tr>  
<tr>  
<td>

**Versioning**

</td>  
<td>

Daily (every day the dataset contains only the data newly generated)

</td> </tr>  
<tr>  
<td>

**Metadata standards**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**6.19.4**

</td>  
<td>

**Dataset ACCESS**

</td> </tr> </table>

The dataset is private but it is accessible to all the consortium members. The
data will be made available through File-download by means of FTP Client.
Dataset are deposited on Azure Platform and the access is provided by
credentials.

#  Table 116 MAKING DATA ACCESSIBLE – Traffic source (Google)  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: JOT. Access: All members

</th> </tr>  
<tr>  
<td>

**Availability (public | private)** 
</td>  
<td>

private

</td> </tr>  
<tr>  
<td>

**Availability to EW-Shopp**

**partners (Y|N)**

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

**Availability method**

</td>  
<td>

File-download

</td> </tr>  
<tr>  
<td>

**Tools to access**

</td>  
<td>

FTP Client (Open Source) or Web Page

</td> </tr>  
<tr>  
<td>

**Dataset source URL**

</td>  
<td>

Azure platform. The URL will be created when needed.

</td> </tr>  
<tr>  
<td>

**Access restrictions**

</td>  
<td>

Credentials

</td> </tr>  
<tr>  
<td>

**Keyword/Tags**

</td>  
<td>

Online Searches (Keywords)

</td> </tr>  
<tr>  
<td>

**Archiving and preservation**

</td>  
<td>

5 years after project end

</td> </tr> </table>

#  Table 117 MAKING DATA INTEROPERABLE – Traffic source (Google)  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

</th> </tr>  
<tr>  
<td>

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

</td> </tr>  
<tr>  
<td>

**6.19.5**

</td>  
<td>

**Dataset SECURITY**

</td> </tr> </table>

The dataset “Traffic source (Google)” does not contain personal data. It is
expected a secure storage and JOT data recovery.

#  Table 118 DATASET SECURITY –Traffic source (Google)  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

</th> </tr>  
<tr>  
<td>

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Data recovery and secure storage**

</td>  
<td>

Secure storage, no sensitive data, JOT data recovery

</td> </tr>  
<tr>  
<td>

**Privacy management procedures**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD at the source (Y|N)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD - anonymised during project (Y|N)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD - anonymised before project (Y|N)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**6.19.6**

</td>  
<td>

**Ethics and Legal requirements**

</td> </tr> </table>

All the data that JOT Internet is generating, sharing and processing (in
compliance with Spanish Organic Law 15/1999 for personal data protection,
ISO/IEC 2382-1 and the General Data Protection Regulation (GDPR)) for the
purpose of EW Shopp project does not include personal data. For that reason,
JOT believe that data managed in the project does not include any personal
data and that is why no further action is needed.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.20 JOT Dataset - Market data: Twitter trends**

**6.20.1 Dataset IDENTIFICATION**

The dataset “Twitter Trends” is Open data and focuses on trending topics as
available through Twitter APIs.

#  Table 119 DATASET IDENTIFICATION – Twitter trends  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Twitter Trends

</th> </tr>  
<tr>  
<td>

**Data name**

</td>  
<td>

Market data

</td> </tr>  
<tr>  
<td>

**Description**

</td>  
<td>

Trending topics as available through Twitter APIs

</td> </tr>  
<tr>  
<td>

**Provider**

</td>  
<td>

Open Data

</td> </tr>  
<tr>  
<td>

**Contact Person**

</td>  
<td>

Ignacio Martínez/ Elías Badenes

</td> </tr>  
<tr>  
<td>

**Business Cases number**

</td>  
<td>

BC4

</td> </tr>  
<tr>  
<td>

**6.20.2**

</td>  
<td>

**Dataset ORIGIN**

</td> </tr> </table>

The dataset “Twitter Trends” is available from May 2017 and it cannot be
defined as “core data”. It has a structured format with a growth of 10MB
daily. The dataset is generated expressly for the project’s purpose.

#  Table 120 DATASET ORIGIN –Twitter trends  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M5

</th> </tr>  
<tr>  
<td>

**Core Data (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Size**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Growth**

</td>  
<td>

50 trending topic / every 15min / country (10MB daily)

</td> </tr>  
<tr>  
<td>

**Type and format**

</td>  
<td>

structured, CSV

</td> </tr>  
<tr>  
<td>

**Existing data (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Data origin**

</td>  
<td>

Twitter API

</td> </tr>  
<tr>  
<td>

**6.20.3**

</td>  
<td>

**Dataset FORMAT**

</td> </tr> </table>

The dataset “Twitter trends” has a CSV format, the data structure is
illustrated in the following table. The dataset does not depend on language.
Its spatial coverage is the country and it collects data since May 2017. The
data is updated daily.

#  Table 121 DATASET FORMAT – Twitter trends  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

Location: Country of the hashtag. Date: Day of the list.

</th> </tr>  
<tr>  
<td>

</td>  
<td>

Hashtag: Name of the hashtag.

Promoted_Content: Shows is a hashtag is promoted or not.

Tweets_Volume: Number of tweets of a hashtag.

Relevance: Hashtag's position.

</td> </tr>  
<tr>  
<td>

**Dataset format**

</td>  
<td>

CSV

</td> </tr>  
<tr>  
<td>

**Time coverage**

</td>  
<td>

M5

</td> </tr>  
<tr>  
<td>

**Spatial coverage**

</td>  
<td>

Country

</td> </tr>  
<tr>  
<td>

**Languages**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Identifiability of data**

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

**Naming convention**

</td>  
<td>

TWITTER_YYMMDD_XX

</td> </tr>  
<tr>  
<td>

**Versioning**

</td>  
<td>

Daily

</td> </tr>  
<tr>  
<td>

**Metadata standards**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**6.20.4**

</td>  
<td>

**Dataset ACCESS**

</td> </tr> </table>

The dataset is private but it is accessible to all the consortium members. The
data will be made available through File-download by means of FTP Client.
Dataset are deposited on Azure Platform and the access is provided by
credentials.

#  Table 122 MAKING DATA ACCESSIBLE – Twitter trends  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

Owner: JOT. Access: All members

</th> </tr>  
<tr>  
<td>

**Availability (public | private)** 
</td>  
<td>

private

</td> </tr>  
<tr>  
<td>

**Availability to EW-Shopp**

**partners (Y|N)**

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

**Availability method**

</td>  
<td>

File-download

</td> </tr>  
<tr>  
<td>

**Tools to access**

</td>  
<td>

FTP Client (Open Source) or Web Page

</td> </tr>  
<tr>  
<td>

**Dataset source URL**

</td>  
<td>

Azure platform. The URL will be created when needed.

</td> </tr>  
<tr>  
<td>

**Access restrictions**

</td>  
<td>

Credentials

</td> </tr>  
<tr>  
<td>

**Keyword/Tags**

</td>  
<td>

Hashtags

</td> </tr>  
<tr>  
<td>

**Archiving and preservation**

</td>  
<td>

5 years after project end

</td> </tr> </table>

Standard vocabulary or taxonomy is not available for “Twitter trends” dataset.

#  Table 123 MAKING DATA INTEROPERABLE –Twitter trends  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

Semantic data enrichment

</th> </tr>  
<tr>  
<td>

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Wikipedia entities

</td> </tr>  
<tr>  
<td>

**6.20.5**

</td>  
<td>

**Dataset SECURITY**

</td> </tr> </table>

The dataset “Twitter trends” does not contain personal data. It is expected a
secure storage and JOT data recovery.

#  Table 124 DATASET SECURITY –Twitter trends  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

</th> </tr>  
<tr>  
<td>

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Data recovery and secure storage**

</td>  
<td>

Secure storage, no sensitive data, JOT data recovery

</td> </tr>  
<tr>  
<td>

**Privacy management procedures**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD at the source (Y|N)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD - anonymised during project (Y|N)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD - anonymised before project (Y|N)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**6.20.6**

</td>  
<td>

**Ethics and Legal requirements**

</td> </tr> </table>

All the data that JOT Internet is generating, sharing and processing (in
compliance with Spanish Organic Law 15/1999 for personal data protection,
ISO/IEC 2382-1 and the General Data Protection Regulation (GDPR)) for the
purpose of EW Shopp project does not include personal data. For that reason,
JOT believe that data managed in the project does not include any personal
data and that is why no further action is needed.

There are no ethical issues that can have an impact on sharing this dataset.
All data are returned by analytics engine that provides only aggregated data
about users grouped by specific characteristics, taking all the necessary
measures to avoid discrimination, stigmatization, limitation to free
association, etc.

**6.21 LOD Dataset - Geographic: DBpedia**

**6.21.1 Dataset IDENTIFICATION**

The dataset “DBpedia” is publicly available and contains factual information
from different areas of human knowledge extracted from Wikipedia pages.

#  Table 125. DATASET IDENTIFICATION – DBpedia  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Geographic Dataset

</th> </tr>  
<tr>  
<td>

**Data name**

</td>  
<td>

DBpedia

</td> </tr>  
<tr>  
<td>

**Description**

</td>  
<td>

DBpedia is a crowd-sourced community effort to extract structured information
from Wikipedia and make this

</td> </tr>  
<tr>  
<td>

</td>  
<td>

information available on the Web. The English version of the DBpedia knowledge
base describes 4.58 million things, out of which 4.22 million are classified
in a consistent ontology, including 1,445,000 persons, 735,000 places
(including 478,000 populated places), 411,000 creative works (including
123,000 music albums, 87,000 films and 19,000 video games), 241,000
organizations (including 58,000 companies and 49,000 educational
institutions), 251,000 species and 6,000 diseases

</td> </tr>  
<tr>  
<td>

**Provider**

</td>  
<td>

LOD - Access facilitated by UNIMIB

</td> </tr>  
<tr>  
<td>

**Contact Person**

</td>  
<td>

Andrea Maurino

</td> </tr>  
<tr>  
<td>

**Business Cases number**

</td>  
<td>

BC1, BC2, BC3, BC4

</td> </tr>  
<tr>  
<td>

**6.21.2**

</td>  
<td>

**Dataset ORIGIN**

</td> </tr> </table>

The dataset is available from January 2017 and it can’t be defined as “core
data”.

#  Table 126 DATASET ORIGIN – DBpedia  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

</th> </tr>  
<tr>  
<td>

**Core Data (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Size**

</td>  
<td>

735,000 places (including 478,000 populated places)

</td> </tr>  
<tr>  
<td>

**Growth**

</td>  
<td>

Not a fixed number, e.g, Dbpedia 3.8 2.8GB, Dbpedia 3.9 2.4GB, while
DBpedia2015-04 4.7GB. More info http://wiki.dbpedia.org/downloads-2016-04

</td> </tr>  
<tr>  
<td>

**Type and format**

</td>  
<td>

rdf, tuples

</td> </tr>  
<tr>  
<td>

**Existing data (Y|N)**

</td>  
<td>

Y

</td> </tr>  
<tr>  
<td>

**Data origin**

</td>  
<td>

_http://wiki.dbpedia.org/datasets_

</td> </tr>  
<tr>  
<td>

**6.21.3**

</td>  
<td>

**Dataset FORMAT**

</td> </tr> </table>

The dataset has a worldwide coverage and collects data since October 2016 in
125 languages.

#  Table 127 DATASET FORMAT – DBpedia  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

provides data in n-triple format (<subject> <predicate> <object> .)

</th> </tr>  
<tr>  
<td>

**Dataset format**

</td>  
<td>

.ttl, .qtl

</td> </tr>  
<tr>  
<td>

**Time coverage**

</td>  
<td>

up to 10/2016

</td> </tr>  
<tr>  
<td>

**Spatial coverage**

</td>  
<td>

Global

</td> </tr>  
<tr>  
<td>

**Languages**

</td>  
<td>

Localized versions of DBpedia in 125 languages. English, German, Spanish,
Catalan, Portuguese, Italian, French, Russian, Chinese, Slovenian, Croatian,
Serbian, Arabic, Turkish, etc.

</td> </tr>  
<tr>  
<td>

**Identifiability of data**

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**Naming convention**

</td>  
<td>

dbpedia_version/year

</td> </tr>  
<tr>  
<td>

**Versioning**

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**Metadata standards**

</td>  
<td>

Yes: DBO, FOAF, SCHEMA.ORG, SKOS, etc.

</td> </tr>  
<tr>  
<td>

**6.21.4**

</td>  
<td>

**Dataset ACCESS**

</td> </tr> </table>

The dataset is public and it is accessible to all the consortium members.

#  Table 128 MAKING DATA ACCESSIBLE – DBpedia  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

GNU Free Documentation License.

</th> </tr>  
<tr>  
<td>

**Availability (public | private)** 
</td>  
<td>

Public

</td> </tr>  
<tr>  
<td>

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

</td> </tr>  
<tr>  
<td>

**Availability method**

</td>  
<td>

SPARQL ENDPOINT, DUMP

</td> </tr>  
<tr>  
<td>

**Tools to access**

</td>  
<td>

web service (REST/SOAP APIs), query endpoint

</td> </tr>  
<tr>  
<td>

**Dataset source URL**

</td>  
<td>

_http://wiki.dbpedia.org/datasets_

</td> </tr>  
<tr>  
<td>

**Access restrictions**

</td>  
<td>

No access restriction

</td> </tr>  
<tr>  
<td>

**Keyword/Tags**

</td>  
<td>

cross-domain: places, person, films, food, music, history etc.

</td> </tr>  
<tr>  
<td>

**Archiving and preservation**

</td>  
<td>

N/A

</td> </tr> </table>

#  Table 129 MAKING DATA INTEROPERABLE – DBpedia  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

N/A (Linked Open Data)

</th> </tr>  
<tr>  
<td>

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Wikipedia entities

</td> </tr>  
<tr>  
<td>

**6.21.5**

</td>  
<td>

**Dataset SECURITY**

</td> </tr> </table>

The dataset does not contain personal data.

#  Table 130 DATASET SECURITY – DBpedia  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

</th> </tr>  
<tr>  
<td>

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Data recovery and secure storage**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Privacy management procedures**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD at the source (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**6.21.6**

</td>  
<td>

**Ethics and Legal requirements**

</td> </tr> </table>

Based on the above dataset description, the dataset “DBpedia” does not contain
personal data, therefore the national and European legal framework that
regulates the use of personal data does not apply and copy of opinion is not
required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.

**6.22 LOD Dataset - Geographic: Linked Open Street Maps**

**6.22.1 Dataset IDENTIFICATION**

The dataset “Linked Open Street Maps” is publicly available and contains
editable map of the whole world.

#  Table 131\. DATASET IDENTIFICATION – Linked Open Street Maps  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Geographic Dataset

</th> </tr>  
<tr>  
<td>

**Data name**

</td>  
<td>

Linked Open Street Maps

</td> </tr>  
<tr>  
<td>

**Description**

</td>  
<td>

OpenStreetMap is built by a community of mappers that contribute and maintain
data about roads, trails, cafés, railway stations, and much more, all over the
world.

</td> </tr>  
<tr>  
<td>

**Provider**

</td>  
<td>

LOD - Access facilitated by UNIMIB

</td> </tr>  
<tr>  
<td>

**Contact Person**

</td>  
<td>

Andrea Maurino

</td> </tr>  
<tr>  
<td>

**Business Cases number**

</td>  
<td>

BC1, BC2, BC3, BC4

</td> </tr> </table>  
<table>  
<tr>  
<th>

**6.22.2**

</th>  
<th>

**Dataset ORIGIN**

</th> </tr> </table>

The dataset is available from January 2017 and it can’t be defined as “core
data”.

#  Table 132 DATASET ORIGIN – Linked Open Street Maps  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

</th> </tr>  
<tr>  
<td>

**Core Data (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Size**

</td>  
<td>

5,027,330,590 GPS points

</td> </tr>  
<tr>  
<td>

**Growth**

</td>  
<td>

Not a fixed number

</td> </tr>  
<tr>  
<td>

**Type and format**

</td>  
<td>

Data normally comes in the form of XML formatted OSM files

</td> </tr>  
<tr>  
<td>

**Existing data (Y|N)**

</td>  
<td>

Y

</td> </tr>  
<tr>  
<td>

**Data origin**

</td>  
<td>

_http://planet.openstreetmap.org/planet/planetlatest.osm.bz2_

</td> </tr>  
<tr>  
<td>

**6.22.3**

</td>  
<td>

**Dataset FORMAT**

</td> </tr> </table>

The dataset has a worldwide coverage and collects data in all languages.

#  Table 133 DATASET FORMAT – Linked Open Street Maps  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

XML

</th> </tr>  
<tr>  
<td>

**Dataset format**

</td>  
<td>

The two main formats used are PBF or compressed OSM XML. PBF is a binary
format that is smaller to download and much faster to process and should be
used when possible. Most common tools using OSM data support PBF.

</td> </tr>  
<tr>  
<td>

**Time coverage**

</td>  
<td>

up to date

</td> </tr>  
<tr>  
<td>

**Spatial coverage**

</td>  
<td>

Worldwide. All the nodes, ways and relations that make up our map

</td> </tr>  
<tr>  
<td>

**Languages**

</td>  
<td>

All languages

</td> </tr>  
<tr>  
<td>

**Identifiability of data**

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**Naming convention**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Versioning**

</td>  
<td>

Each week, a new and complete copy of all data in OpenStreetMap is made
available as both a compressed XML file and a custom PBF format file. Also
available is the 'history' file, which contains not only up-to-date data but
also older versions of data and deleted data items.

</td> </tr>  
<tr>  
<td>

**Metadata standards**

</td>  
<td>

Yes: DBO, FOAF, SCHEMA.ORG, SKOS, etc.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**6.22.4**

</th>  
<th>

**Dataset ACCESS**

</th> </tr> </table>

The dataset is public and it is accessible to all the consortium members.

#  Table 134 MAKING DATA ACCESSIBLE – Linked Open Street Maps  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

</th>  
<th>

OpenStreetMap is _open data_ , licensed under the Open Data Commons Open
Database License (ODbL) by the OpenStreetMap Foundation (OSMF).

</th> </tr>  
<tr>  
<td>

**Availability (public | private)**

</td>  
<td>

</td>  
<td>

Public

</td> </tr>  
<tr>  
<td>

**Availability to EW-Shopp (Y|N)**

</td>  
<td>

**partners**

</td>  
<td>

Y

</td> </tr>  
<tr>  
<td>

**Availability method**

</td>  
<td>

</td>  
<td>

dump, keyword based

</td> </tr>  
<tr>  
<td>

**Tools to access**

</td>  
<td>

</td>  
<td>

API / dump, SPARQL wrapper

</td> </tr>  
<tr>  
<td>

**Dataset source URL**

</td>  
<td>

</td>  
<td>

_http://wiki.openstreetmap.org/wiki/Use_OpenStreetMap_

</td> </tr>  
<tr>  
<td>

**Access restrictions**

</td>  
<td>

</td>  
<td>

No access restriction

</td> </tr>  
<tr>  
<td>

**Keyword/Tags**

</td>  
<td>

</td>  
<td>

cities, towns, places, municipalities, etc.

</td> </tr>  
<tr>  
<td>

**Archiving and preservation**

</td>  
<td>

</td>  
<td>

N/A

</td> </tr> </table>

#  Table 135 MAKING DATA INTEROPERABLE – Linked Open Street Maps  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

N/A (Linked Open Data)

</th> </tr>  
<tr>  
<td>

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Wikipedia entities

</td> </tr>  
<tr>  
<td>

**6.22.5**

</td>  
<td>

**Dataset SECURITY**

</td> </tr> </table>

The dataset does not contain personal data.

##  Table 136 DATASET SECURITY – Linked Open Street Maps  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

</th> </tr>  
<tr>  
<td>

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Data recovery and secure storage**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Privacy management procedures**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD at the source (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

</td> </tr> </table>  
<table>  
<tr>  
<th>

**6.22.6**

</th>  
<th>

**Ethics and Legal requirements**

</th> </tr> </table>

Based on the above dataset description, the dataset “Linked Open Street Maps”
does not contain personal data, therefore the national and European legal
framework that regulates the use of personal data does not apply and copy of
opinion is not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.

**6.23 LOD Dataset - Geographic: Linked Geo Data**

**6.23.1 Dataset IDENTIFICATION**

The dataset “Linked Geo Data” is publicly available and contains geographic
information for places, cities, countries, etc..

##  Table 137. DATASET IDENTIFICATION – Linked Geo Data  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Geographic Dataset

</th> </tr>  
<tr>  
<td>

**Data name**

</td>  
<td>

Linked Geo Data

</td> </tr>  
<tr>  
<td>

**Description**

</td>  
<td>

LinkedGeoData is an effort to add a spatial dimension to the Web of Data /
Semantic Web. LinkedGeoData uses the information collected by the
OpenStreetMap project and makes it available as an RDF knowledge base
according to the Linked Data principles. It interlinks this data with other
knowledge bases in the Linking Open

Data initiative.

</td> </tr>  
<tr>  
<td>

**Provider**

</td>  
<td>

LOD - Access facilitated by UNIMIB

</td> </tr>  
<tr>  
<td>

**Contact Person**

</td>  
<td>

Andrea Maurino

</td> </tr>  
<tr>  
<td>

**Business Cases number**

</td>  
<td>

BC1, BC2, BC3, BC4

</td> </tr> </table>  
<table>  
<tr>  
<th>

**6.23.2**

</th>  
<th>

**Dataset ORIGIN**

</th> </tr> </table>

The dataset is available from January 2017 and it can’t be defined as “core
data”.

##  Table 138 DATASET ORIGIN – Linked Geo Data  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

</th> </tr>  
<tr>  
<td>

**Core Data (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Size**

</td>  
<td>

8,3GB

</td> </tr>  
<tr>  
<td>

**Growth**

</td>  
<td>

Not a fixed number

</td> </tr>  
<tr>  
<td>

**Type and format**

</td>  
<td>

.nt

</td> </tr>  
<tr>  
<td>

**Existing data (Y|N)**

</td>  
<td>

Y

</td> </tr>  
<tr>  
<td>

**Data origin**

</td>  
<td>

_http://downloads.linkedgeodata.org/releases/_

</td> </tr>  
<tr>  
<td>

**6.23.3**

</td>  
<td>

**Dataset FORMAT**

</td> </tr> </table>

The dataset collects data since November 2015 in English.

##  Table 139 DATASET FORMAT – Linked Geo Data  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

N-triples

</th> </tr>  
<tr>  
<td>

**Dataset format**

</td>  
<td>

.nt

</td> </tr>  
<tr>  
<td>

**Time coverage**

</td>  
<td>

up to november 2015

</td> </tr>  
<tr>  
<td>

**Spatial coverage**

</td>  
<td>

It consists of more than 3 billion nodes and 300 million ways and the
resulting RDF data comprises approximately 20 billion triples. The data is
available according to the Linked Data principles and interlinked with DBpedia
and Geo Names.

</td> </tr>  
<tr>  
<td>

**Languages**

</td>  
<td>

English

</td> </tr>  
<tr>  
<td>

**Identifiability of data**

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**Naming convention**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Versioning**

</td>  
<td>

No versioning

</td> </tr>  
<tr>  
<td>

**Metadata standards**

</td>  
<td>

Linked open geo vocabulary

</td> </tr> </table>  
<table>  
<tr>  
<th>

**6.23.4**

</th>  
<th>

**Dataset ACCESS**

</th> </tr> </table>

The dataset is public and it is accessible to all the consortium members
through dump.

##  Table 140 MAKING DATA ACCESSIBLE – Linked Geo Data  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

ODbL

</th> </tr>  
<tr>  
<td>

**Availability (public | private)**

</td>  
<td>

Public

</td> </tr>  
<tr>  
<td>

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

</td> </tr>  
<tr>  
<td>

**Availability method**

</td>  
<td>

dump,

</td> </tr>  
<tr>  
<td>

**Tools to access**

</td>  
<td>

dump

</td> </tr>  
<tr>  
<td>

**Dataset source URL**

</td>  
<td>

_http://downloads.linkedgeodata.org/releases/_

</td> </tr>  
<tr>  
<td>

**Access restrictions**

</td>  
<td>

No access restriction

</td> </tr>  
<tr>  
<td>

**Keyword/Tags**

</td>  
<td>

cities, towns, places, municipalities, etc

</td> </tr>  
<tr>  
<td>

**Archiving and preservation**

</td>  
<td>

N/A

</td> </tr> </table>

##  Table 141 MAKING DATA INTEROPERABLE – Linked Geo Data  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

N/A (Linked Open Data)

</th> </tr>  
<tr>  
<td>

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Wikipedia entities

</td> </tr>  
<tr>  
<td>

**6.23.5**

</td>  
<td>

**Dataset SECURITY**

</td> </tr> </table>

The dataset does not contain personal data.

##  Table 142 DATASET SECURITY – Linked Geo Data  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

</th> </tr>  
<tr>  
<td>

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Data recovery and secure storage**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Privacy management procedures**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD at the source (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**6.23.6**

</td>  
<td>

**Ethics and Legal requirements**

</td> </tr> </table>

Based on the above dataset description, the dataset “Linked Geo Data” does not
contain personal data, therefore the national and European legal framework
that regulates the use of personal data does not apply and copy of opinion is
not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.

**6.24 LOD Dataset - Geographic: GeoNames**

**6.24.1 Dataset IDENTIFICATION**

The dataset “GeoNames” is publicly available and contains geographic
information for places, cities, countries, etc.

#  Table 143. DATASET IDENTIFICATION – GeoNames  
  
<table>  
<tr>  
<th>

**Category**

</th>  
<th>

Geographic Dataset

</th> </tr>  
<tr>  
<td>

**Data name**

</td>  
<td>

GeoNames

</td> </tr>  
<tr>  
<td>

**Description**

</td>  
<td>

The GeoNames geographical database is available for download free of charge
under a creative commons attribution license. It contains over 10 million
geographical names and consists of over 9 million unique features whereof 2.8
million populated places and 5.5

</td> </tr>  
<tr>  
<td>

</td>  
<td>

million alternate names. All features are categorized into one out of nine
feature classes and further subcategorized into one out of 645 feature codes.

</td> </tr>  
<tr>  
<td>

**Provider**

</td>  
<td>

LOD - Access facilitated by UNIMIB

</td> </tr>  
<tr>  
<td>

**Contact Person**

</td>  
<td>

Andrea Maurino

</td> </tr>  
<tr>  
<td>

**Business Cases number**

</td>  
<td>

BC1, BC2, BC3, BC4

</td> </tr> </table>  
<table>  
<tr>  
<th>

**6.24.2**

</th>  
<th>

**Dataset ORIGIN**

</th> </tr> </table>

The dataset is available from January 2017 and it can’t be defined as “core
data”.

#  Table 144 DATASET ORIGIN – GeoNames  
  
<table>  
<tr>  
<th>

**Available at (M)**

</th>  
<th>

M1

</th> </tr>  
<tr>  
<td>

**Core Data (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Size**

</td>  
<td>

10.6GB zipped

</td> </tr>  
<tr>  
<td>

**Growth**

</td>  
<td>

Not a fixed number

</td> </tr>  
<tr>  
<td>

**Type and format**

</td>  
<td>

RDF

</td> </tr>  
<tr>  
<td>

**Existing data (Y|N)**

</td>  
<td>

Y

</td> </tr>  
<tr>  
<td>

**Data origin**

</td>  
<td>

_https://drive.google.com/file/d/0B1tUDhWNTjOWEZZb2VwOG5vZkU/edit?usp=sharing/_

</td> </tr>  
<tr>  
<td>

**6.24.3**

</td>  
<td>

**Dataset FORMAT**

</td> </tr> </table>

The dataset collects data related to all countries.

#  Table 145 DATASET FORMAT – GeoNames  
  
<table>  
<tr>  
<th>

**Dataset structure**

</th>  
<th>

RDF

</th> </tr>  
<tr>  
<td>

**Dataset format**

</td>  
<td>

RDF

</td> </tr>  
<tr>  
<td>

**Time coverage**

</td>  
<td>

up to date

</td> </tr>  
<tr>  
<td>

**Spatial coverage**

</td>  
<td>

All countries and points in degree (long & lat)

</td> </tr>  
<tr>  
<td>

**Languages**

</td>  
<td>

English

</td> </tr>  
<tr>  
<td>

**Identifiability of data**

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**Naming convention**

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**Versioning**

</td>  
<td>

daily dump

</td> </tr>  
<tr>  
<td>

**Metadata standards**

</td>  
<td>

geonames vocab

</td> </tr> </table>  
<table>  
<tr>  
<th>

**6.24.4**

</th>  
<th>

**Dataset ACCESS**

</th> </tr> </table>

The dataset is public and it is accessible to all the consortium members
through dump.

#  Table 146 MAKING DATA ACCESSIBLE – GeoNames  
  
<table>  
<tr>  
<th>

**Dataset license**

</th>  
<th>

CC-BY 3.0  50  
</th> </tr>  
<tr>  
<td>

**Availability (public | private)** 
</td>  
<td>

Public

</td> </tr>  
<tr>  
<td>

**Availability to EW-Shopp partners (Y|N)**

</td>  
<td>

Y

</td> </tr>  
<tr>  
<td>

**Availability method**

</td>  
<td>

dump,

</td> </tr>  
<tr>  
<td>

**Tools to access**

</td>  
<td>

dump

</td> </tr>  
<tr>  
<td>

**Dataset source URL**

</td>  
<td>

_http://download.geonames.org/export/dump/_

</td> </tr>  
<tr>  
<td>

**Access restrictions**

</td>  
<td>

No access restriction

</td> </tr>  
<tr>  
<td>

**Keyword/Tags**

</td>  
<td>

cities, towns, places, municipalities, etc.

</td> </tr>  
<tr>  
<td>

**Archiving and preservation**

</td>  
<td>

N/A

</td> </tr> </table>

#  Table 147 MAKING DATA INTEROPERABLE – GeoNames  
  
<table>  
<tr>  
<th>

**Data interoperability**

</th>  
<th>

•

</th>  
<th>

N/A (Linked Open Data)

</th> </tr>  
<tr>  
<td>

**Standard vocabulary**

</td>  
<td>

•

</td>  
<td>

Temporal ontologies

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Spatial ontologies and locations

</td> </tr>  
<tr>  
<td>

</td>  
<td>

•

</td>  
<td>

Wikipedia entities

</td> </tr>  
<tr>  
<td>

**6.24.5**

</td>  
<td>

**Dataset SECURITY**

</td> </tr> </table>

The dataset does not contain personal data.

#  Table 148 DATASET SECURITY – GeoNames  
  
<table>  
<tr>  
<th>

**Personal Data (Y|N)**

</th>  
<th>

N

</th> </tr>  
<tr>  
<td>

**Anonymized (Y|N|NA)**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Data recovery and secure storage**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**Privacy management procedures**

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

**PD at the source (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**PD - anonymised during project (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**PD - anonymised before project (Y|N)**

</td>  
<td>

N

</td> </tr>  
<tr>  
<td>

**Level of Aggregation (for PD anonymized by aggregation)**

</td>  
<td>

N/A

</td> </tr> </table>  
<table>  
<tr>  
<th>

**6.24.6**

</th>  
<th>

**Ethics and Legal requirements**

</th> </tr> </table>

Based on the above dataset description, the dataset “GeoNames” does not
contain personal data, therefore the national and European legal framework
that regulates the use of personal data does not apply and copy of opinion is
not required to be collected.

There are no ethical issues that can have an impact on sharing this dataset.

**6.25 Mapping between Dataset and Business case**

In the following table it is possible to see which are all the datasets that
refer to a business case.

#  Table 149 Mapping Dataset and Business case  
  
<table>  
<tr>  
<th>

**id**

</th>  
<th>

**Dataset name**

</th>  
<th>

**Provider**

</th>  
<th>

**BC1**

</th>  
<th>

**BC2**

</th>  
<th>

**BC3**

</th>  
<th>

**BC4**

</th> </tr>  
<tr>  
<td>

1

</td>  
<td>

Purchase intent

</td>  
<td>

Ceneje

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

2

</td>  
<td>

Location analytics data (hourly)

</td>  
<td>

Measurence

</td>  
<td>

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td> </tr>  
<tr>  
<td>

3

</td>  
<td>

Location analytics data (daily)

</td>  
<td>

Measurence

</td>  
<td>

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td> </tr>  
<tr>  
<td>

4

</td>  
<td>

Customer Purchase History

</td>  
<td>

Big Bang

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

5

</td>  
<td>

Consumer Intent and Interaction

</td>  
<td>

Big Bang

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

6

</td>  
<td>

Location analytics data (Weekly)

</td>  
<td>

Measurence

</td>  
<td>

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td> </tr>  
<tr>  
<td>

7

</td>  
<td>

Contact and Consumer Interaction History

</td>  
<td>

Browsetel

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

8

</td>  
<td>

MARS (historical data)

</td>  
<td>

ECMWF

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

9

</td>  
<td>

Product attributes

</td>  
<td>

Ceneje

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

10

</td>  
<td>

Event Registry

</td>  
<td>

JSI

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

11

</td>  
<td>

Consumer data

</td>  
<td>

GfK

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

12

</td>  
<td>

Sales data

</td>  
<td>

GfK

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

</td> </tr>  
<tr>  
<td>

13

</td>  
<td>

Product attributes

</td>  
<td>

GfK

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

14

</td>  
<td>

Door counter data

</td>  
<td>

Measurence

</td>  
<td>

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td> </tr>  
<tr>  
<td>

15

</td>  
<td>

Product attributes

</td>  
<td>

Bing Bang

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

16

</td>  
<td>

Products price history

</td>  
<td>

Ceneje

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

17

</td>  
<td>

Sales data

</td>  
<td>

Measurence

</td>  
<td>

</td>  
<td>

X

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

18

</td>  
<td>

Traffic sources (Bing)

</td>  
<td>

JOT

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

19

</td>  
<td>

Traffic sources (Google)

</td>  
<td>

JOT

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

20

</td>  
<td>

Twitter Trends

</td>  
<td>

JOT

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

21

</td>  
<td>

Dbpedia

</td>  
<td>

LOD

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

22

</td>  
<td>

Linked Open Street Maps

</td>  
<td>

LOD

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

23

</td>  
<td>

Linked Geo Data

</td>  
<td>

LOD

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

24

</td>  
<td>

GeoNames

</td>  
<td>

LOD

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td>  
<td>

X

</td> </tr> </table>

**Chapter 7 Storage and Re-use**

**7.1 Storage**

Data in the EW-Shopp will be exchanged and made available through a two-tier
storage policy. The policy will consist of:

  * Tier 1: a shared data space for exchanging raw input data between Consortium partners. 

  

  * Tier 2: structured data storage with integrated data based on the DataGraft platform, which will be used to produce the integrated data according to a shared data model. 

  

Tier 1 will be implemented using a file or data sharing solution. It will use
cloud hosting infrastructure services to enable easy access over the web. Data
will be stored using data hosting service and secure data sharing protocols to
ensure that data are not compromised.

Tier 2 will be implemented based on the DataGraft platform where the shared
data model will be published and the output data will be imported in a
database management system and registered in the catalogue, taking into
account the user access restrictions for each dataset.  
  
<table>  
<tr>  
<th>

**7.2**

</th>  
<th>

**Backup and Recovery**

</th> </tr> </table>

Back-up and recovery mechanisms will be implemented on a case by case basis
with respect to each output datasets. Input datasets have already back-up and
recovery in place (when needed) and are directly managed by the data
providers; therefore, no backup and/or recovery mechanism for input datasets
falls within the scope of the EW-Shopp platform.

The concrete data back-up and recovery mechanisms to be adopted at EW-Shopp
platform level will be discussed in the future versions of the Data Management
Plan as they evolve throughout the project, or in other deliverables dealing
with technical aspects (such as the detailed design of the platform or the
business cases implementation plans).  
  
<table>  
<tr>  
<th>

**7.3**

</th>  
<th>

**Data Archiving**

</th> </tr> </table>

The data used and produced during the project development will be updated each
time they change in project lifetime. For each dataset update, a reference
document will also be produced. This document will report the changes of the
dataset respect to previous version _._

EW-Shopp datasets used in the demonstrator will be maintained for at least
five years after project termination. Sensitive data preservation will follow
the guidelines that EW-Shopp consortium will provide during the project
development.  
  
<table>  
<tr>  
<th>

**7.4**

</th>  
<th>

**Security**

</th> </tr> </table>

The EW-Shopp framework will ensure the secure storage and exchange of data in
the project to protect against compromising of sensitive data. One of the main
components that will be used for the EW-Shopp framework and set up of data is
the DataGraft platform (tier 2). DataGraft security is implemented on several
layers as follows:

  1. User login – Account information is protected by a password, which is encrypted and DataGraft does not store the non-encrypted version. Furthermore, current deployments of DataGraft use SSL certificates enabled through the CloudFront CDN on AWS. Other configurations of SSL are also possible if necessary; 

  

  2. OAuth2 – DataGraft uses a standard implementation of RFC 6749 – token-based authorisation layer for control of client access to resources; 

  

  3. API keys for database – The public API of the back-end database of DataGraft (Ontotext S4) is accessible through an API key, which can be created and managed by registered users of the platform; and 

  

  4. Encrypted cookies – Front-end cookies containing session information are exchanged between the web UI and the back-end. This cookie stores a session identifier and encrypted session data when users are logged in to the DataGraft Portal. 

  

  

Security will be considered additionally for the purposes of data exchange
between partners (tier 1) and sharing before the final data
integration/publication. The particular security measures will be taken on a
case by case basis based on the medium for data exchange and the precise needs
of each data provide. They will include the following:

  1. Setting up security policies on cloud service providers 

  

  2. Setting up secure FTP server for file transfer of any files over the Internet 

  

  3. Setting up secret SSH keys for accessing servers/clusters of servers with running databases that host any shared dataset 

  

  
  
<table>  
<tr>  
<th>

**7.5**

</th>  
<th>

**Permission**

</th> </tr> </table>

Permission policies will be provided to make EW-Shopp compliant with the
privacy-preserving data management. The platform will provide authentication
mechanisms that ensure data security, as stated in Section 7.4 (supported by
the chosen data exchange medium in tier 1 and the DataGraft platform), in
order to restrict access to data files to the research personnel involved in
EW-Shopp development  
  
<table>  
<tr>  
<th>

**7.6**

</th>  
<th>

**Access, Re-use and Licensing**

</th> </tr> </table>

The individual input dataset sharing can be found in Chapter 6 under "Dataset
ACCESS", together with the individual license for each of them. To this end
access will be provided to the whole EWShopp Consortium and exclusively for
the project objectives.

Datasets produced as a result of the project work will be shared within the
Consortium and will only be allowed for external sharing with a consensual
Consortium approval of the relevant stakeholders, by accepting the terms and
conditions of use, as appropriate. The license for the access, sharing and re-
use of EW-Shopp material and output datasets will be defined by the Consortium
on a case by case basis _._

The research data will be present in scientific publications that the
consortium will write and publish during the funding period. Materials
generated under the Project will be disseminated in accordance with Consortium
Agreement.