#  Description of the deliverable

Deliverable D8.4 relates to Work Package 8 - Dissemination and Exploitation;
more specifically, D8.4 details the first version of the Data Management Plan
produced in Task T8.2 (Plans for Dissemination,

Exploitation, Data management). According to the CARESSES DoA, Deliverable
D8.1 _includes the Data Management Plan, according to the requirements of the
pilot on Open Research Data (to which CARESSES takes part)._

In particular, due to CARESSES’ peculiarities, the data produced during the
project will belong to two different classes:

  1. Data that are produced as the outcome of RTD activities performed by a partner or a team of partners according to the DoA; 

  

  2. Data that are produced in run-time by a software or hardware component of the system (i.e., the robot operating in the smart environments) during experiments. 

  

  

To clarify the difference between the two classes above, please notice that
data of the first kind typically correspond to the output of tasks performed
by CARESSES partners, either in parallel or in cascade. An example is the
Cultural Knowledge Base, which contains information on how the robot shall
adapt its behavior depending on the cultural identity of the user. The
Cultural Knowledge Base includes data that are the ultimate output of “Task
1.4 Cultural competence encoded with formal tools”, which – on its turn -
relies on previous tasks such as “Task 1.1 Definition of scenarios”; “Task 1.2
Guidelines for culturally competent robots”; “Task 2.2 Cultural knowledge
representation” (to mention but a few). Another example are the data collected
in the pre- and post-testing structured interviews with clients and informal
caregivers in the last year of the project, which are the output of “Task 7.1
Pre- and post-testing structured interviews”, but iteratively rely on a set of
previous tasks that constitute the basis for making experiments and collecting
such data.

Data of the second kind are not the direct output of an RTD activity performed
by partners, but are typically produced by the system itself during
experiments, and correspond to the log of information exchanged in run-time
among different software components. An example are the data acquired by
sensors over time, which are then processed in order to detect the user’s
emotion or action, or the actions that have been chosen for execution by the
planner depending on the context at a time.

The Consortium has made the effort, since the first months of the project, to
identify all the data that will be produced in CARESSES, by making a clear
distinction among data of the first and second class. Converging on agreed
data formats as early as possible has played a key role for producing a
detailed Data Dissemination Plan within the first five months of the project,
it will be crucial to maintain a correct flow of information between
participants throughout the project, and it will lay the basis to make the
integration of software components easier.

Section 2 briefly describes the methodology that has been adopted by CARESSES’
partners in order to converge on shared data formats, and to select the data
types to be included in the initial release of the Data Dissemination Plan.
Section 3 describes the data types that have been selected for publication as
Open Research Data. Section 4 comments on how this document may be used, and
updated. Finally Conclusions are given. The attachment reports our initial
answers to most of the issues raised by the guidelines for DMP preparation (
_https://dmponline.dcc.ac.uk/_ )  , laying the basis for producing highquality
data that comply with all the constraints of the Open Research Data pilot.

#  Methodology

The definition of the Data Management Plan has started since the first month
of the project, by relying on procedures and tools for collaborative working
that have allowed partners to aim at the definition of shared data formats:
FlashMeeting - a browser-based application for videoconference, GoogleDrive
online tools, a CARESSES repository hosted on gitLab and, obviously, emails.

##  Procedures for converging to shared data formats

During the Kick-off meeting, a special session was devoted to making partners
aware of the importance of open data. Specifically, a top-down approach has
been proposed and approved by the consortium, based on the principle of
valuing the needs and expertise of each participant in its respective area of
research as a starting point, and establishing policies and a procedure to
rapidly converge to agreed data formats through subsequent steps of iterative
refinement.

According to this rationale, the following steps have been performed in
January-May 2017.

  * January 2017: the coordinator prepares Input and Output data templates, that are presented and discussed during videoconference meetings: in the templates, partners are asked to describe the Input data that they need to receive from other partners, as well as the Output data that they are able to produce. As usual, data are distinguished in the two classes 1 and 2 above, i.e., data that are produced as the outcome of RTD activities _versus_ data that are produced in run-time by a component of the system. Templates have a structure that follows the guidelines for DMP preparation, in order to ease the mapping onto the online tool. 

  

  * 30th -31st January, Kick-off meeting in London: starting from the Input and Output templates filled by partners, the Coordinator describes the procedure to be used to converge to agreed data formats and then identify the data to be made public. The procedure can be summarized as follows: 

    * in a first phase, partners try to find a match between the Output Data they expect to produce and the Input Data that other partners expect to receive, in order to guarantee that each required Input has a matching corresponding Output; in this process, a unique format for matching Input/Output data is negotiated; 

  

    * in a second phase, after Input/Output data formats have been uniquely defined, data that are relevant to be included in the Data Management Plan are chosen, and described at a greater level of detail according the guidelines for DMP preparation. 

  

  

  * February – April: partners implement the two phases described above, by negotiating, during videoconference meetings, the exact format of each Input/Output data type of class 1 or 2. Data of class 2 require the additional effort of specifying details of the whole architecture of the system, including the three main components Cultural Knowledge Base, Culturally-Sensitive Planning & Execution, and Culture-aware Human-Robot Interaction, as well as the subcomponents that ultimately produce / consume those Input/Output data. The final outcome of this process is a “Living document about CARESSES Data Types”  1  describing the exact format of all the data exchanged in the system, which partners can use as a reference for the software development, and will be updated as the project progresses and new needs may arise. 

  

  * April – May: partners select, during videoconference meetings, the data of class 1 and 2 to be included in the Data Management Plan, which are then refined and described in greater detail according to the guidelines for DMP preparation. The final outcome of this process has been uploaded using the online tool, and is attached to this document. 

  

#  Data included in the ORDP

According to the procedure described in Section 2, the following Data types
have been selected to be included in the Data Management Plan. All of the data
will be collected in an ethically appropriate manner, with Ethics Committee
approval and in compliance with the principles and requirements of General
Data Protection Regulation (EU) 2016/679. Additional details can be found in
Deliverable 10.1 Ethics Requirements.

##  Dataset 1: Cultural Knowledge

“Cultural Knowledge” is a dataset of the first class, i.e., it is produced by
RTD activity performed by partners in the context of WP1 (Transcultural
Nursing) and WP2 (Cultural Knowledge Representation). Specifically, WP1 leads
to the collection of a large corpus of knowledge, that play a key role for any
assistive robot which aims at showing a culturally competent behavior
(Hofstede 2001; Papadopoulos 2006). Such knowledge includes the scenarios
tables describing possible interactions between the robot and clients
belonging to different cultural group (WP1, Deliverable D1.1), the guidelines
for achieving a culturally competent robotic behavior (WP1, Deliverable D1.2),
as well as additional sources of information that may be found on dedicated
publications or websites (describing geographical regions of different
countries, customs, manners, etc.). This heterogeneous knowledge is then
structured using a formal language for knowledge representations in WP2 (using
the Ontology Web Language  2  ) allowing for a unique representation,
automatic acquisition, update and reasoning.

By making this data available to the scientific community we:

1) Foster the discussion on what knowledge is required for cultural
competence; 2) Allow other research groups to contribute to our cultural
knowledge base;

3) Foster the research on efficient representations of the cultural knowledge,
proposing the CARESSES Cultural Knowledge Base as a benchmark.

The Cultural Knowledge Base, properly encoded using the OWL2 formalism, will
be stored in a public repository. Public repositories of ontologies are
becoming more and more popular. As an example, the SmartCity website
_http://smartcity.linkeddata.es/index.html_ collects ontologies defining
concepts and relationships about smart cities, energy and related fields, as
well as related datasets. Specifically, we propose the publication of

  * the OWL2 ontology that we developed for the representation of cultural knowledge in WP2, together with 

  

  * the set of all sources of cultural knowledge produced or collected in WP2 that we deem relevant for the development of a culture-aware assistive robot (scenarios tables, guidelines, other sources of the knowledge encoded in the Cultural Knowledge Base in the form of a list of links to web sources). 

  

The data contained in the Cultural Knowledge Base are not personal data, and
therefore do not fall under the General Data Protection Regulation (EU)
2016/679.

##  Dataset 2: Interaction Logs

“Interaction Logs” is a dataset of the second class, i.e., it consists in the
log / history of the interactions between the system (robot plus smart
environment) and the user, in the form of a temporally ordered list of all
messages shared among the software components of the system. The dataset
includes the logs produced in WP6 (Testing in Health-Care Facilities and the
iHouse), but also those produced in WP5 (System Integration) during system
level integration of CARESSES modules, i.e., before the testing in health-care
facilities that is performed in WP6.

The messages shared among the components (goals, actions to be executed,
sensor data, position, posture and gesture of the user, etc.) during one
encounter between the robot and a user provide a persistent recording of the
events occurred during the encounter, which can be later analyzed:

  * In itself, to find correlations between events, user actions and robot actions; 

  

  * Together with the pre- and post-testing structured interviews (see Dataset 3), to find correlations between events, user actions, robot actions and the users’ and caregivers’ responses By making this data available to the scientific community we: 

  

  1. Foster the research on culturally-competent robot behavior; 

  

  2. Allow for the study, discovery and definition of robot behaviors that have a positive/negative impact on the user and the caregiver, which can ultimately lead to the definition of standards in terms of actions and capabilities required for (effective) assistive robots. 

  

  

The Interaction Logs data set will be stored in a public repository. More
specifically, as it is common for logs of software components, we are
considering to store the data on Github (  _https://github.com/_ )  , which is
among the largest and most popular repository hosting services. Github
repositories can be given a

DOI and released using the data archiving tool Zenodo (  _https://zenodo.org/_
)  , which also ensures that all metadata required for the identification of
the repository are filled before its public release.

All the data type exchanged among software components of the system are not
personal data (according to their current definition in the “Living document
about CARESSES Data Types”), and therefore do not fall under the General Data
Protection Regulation (EU) 2016/679.

Whenever possible, video / audio recordings and annotations will be collected
following informed consent and anonymized in compliance with the General Data
Protection Regulation (EU) 2016/679, in order to describe events occurred
during the encounter (the additional cost for anonymization and the possible
impact on participants during experiments will be carefully considered before
collecting supporting video/audio data).

##  Dataset 3: End-user Evaluation

“End-user Evaluation” is a dataset of the first class, i.e., it is produced by
RTD activity performed by partners in the context of WP6 (Testing in Health-
Care Facilities) and WP7 (End-User Evaluation). The research within WP6 and
WP7 leads to the acquisition of the corpus of CARESSES end-users’ responses to
pre- and post-testing structured interviews, aimed at evaluating the key
feature of cultural competence in designing robots more sensitive to the
user’s needs, customs and lifestyle, improving the quality of life of users
and their caregivers, reducing caregiver burden and improving the system’s
efficiency and effectiveness. Data include results of

  * Client perception of the system’s cultural competence, Adapted CCATool (Papadopoulos et al., 2004); 

  

  * Client and informal caregiver related quality of life, SF-36 (Hays et al 1993); 

  

  * Caregivers burden, ZBI tool (Zarit et al., 1980); 

  

  * Client satisfaction about the system’s efficiency and effectiveness (Chin et al, 1988);  Qualitative semi-structured interviews transcripts. 

  

By making this data available to the scientific community we:

  1. Allow other researchers to validate the findings of CARESSES. 

  

  2. Foster the research on the evaluation of (culture-aware) assistive robots. 

  

  

End-user Evaluation data will be released as a publicly accessible dataset
using the data archiving tool Zenodo (  _https://zenodo.org/_ )  , which also
ensures that all metadata required for the identification of the dataset are
filled before its public release. The data will be collected following
informed consent and will be pseudonymized, in compliance with the General
Data Protection Regulation (EU) 2016/679.

##  Summary of data included in the ODRP

The following table summarizes the data to be openly published in CARESSES and
a tentative release date, after the data has been used by project’s
participants for the project’s RTD activities and to prepare scientific
publications.  
  
<table>  
<tr>  
<th>

Name

</th>  
<th>

Class

</th>  
<th>

Content

</th>  
<th>

Work Packages

</th>  
<th>

Supporting material

</th>  
<th>

Personal data

</th>  
<th>

First release date

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

Cultural

Knowledge

</td>  
<td>

1

</td>  
<td>

Cultural Knowledge Base in OWL2.

</td>  
<td>

WP1, WP2

</td>  
<td>

Scenarios tables, guidelines, other sources of knowledge encoded in

the Cultural Knowledge Base

</td>  
<td>

NO

</td>  
<td>

M24

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

Interaction Logs

</td>  
<td>

2

</td>  
<td>

Logs of the interactions between the robot and a user, in the form of a
temporally ordered

list of all messages

shared among CARESSES components.

</td>  
<td>

WP5, WP6: Collected during the testing

phases of

CARESSES

</td>  
<td>

Video / audio recordings and annotations in order to describe events occurred
during the encounter

</td>  
<td>

NO

(supporting material

must be

collected and

handled in

line with

GDPR

2016/679)

</td>  
<td>

M27

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

End-User Evaluation

</td>  
<td>

1

</td>  
<td>

Adapted CCATool responses SF-36 responses

ZBI responses

QUIS responses Qualitative semistructured interviews transcripts.

</td>  
<td>

WP7:

Collected from the end-users in the pre-and post-testing phases of

CARESSES

</td>  
<td>

N.A.

</td>  
<td>

YES

To be collected and

managed in

line with

GDPR

2016/679.

</td>  
<td>

M37

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

_Figure 1: Summary of the datasets to be included in the CARESSES Data
Management Plan (more details in the Attachment)._

D8.4: Data Management Plan (updated during the project) Page 10

#  How to

As the project will progress, the consortium will use this deliverable, as
well as the detailed Data Management Plan that has been uploaded using the
online tool (see the Attachment), as a reference for the publication of open
data. The Data Management Plan, even in its preliminary form (to be updated as
the project progresses), includes a detailed set of guidelines, that
participants will carefully considered for the production and publications of
high quality data meeting the required standards.

#  Conclusions

##  Compliance with the DoA and corrective actions

The Deliverable is the output of Tasks 8.2. According to the Description of
Action (DoA), deliverable D8.4:

_includes the Data Management Plan, according to the requirements of the pilot
on Open Research Data (to which CARESSES takes part)._

By considering that the draft Data Management Plan included in this
deliverable will be periodically updated during the project under the
supervision of the Exploitation, Dissemination and IPR Board, the work
reported in this document and its attachments fully complies with the plans in
the DoA.

##  Achievements

A draft Data Management Plan has been prepared, which is the output of a
process aimed at identifying, since the first months of the project, all the
data that will be produced in CARESSES, in order to converge to agreed data
formats as early as possible. As an additional achievement, this process has
produced a “Living document about CARESSES Data Types”, describing the exact
format of all the data exchanged in the system, that partners can use as a
reference for the software development. This document will allow for
maintaining a correct flow of information between participants throughout the
project, and will lay the basis to make the integration of software components
easier.

Among all data produced in CARESSES, datasets to be openly published have been
chosen, described in greater detail according to the guidelines for DMP
preparation, and finally uploaded using the online tool  (
_https://dmponline.dcc.ac.uk/_ )  .

As required by the Grant Agreement, updates to the Data Management Plan will
be made online, and discussed in the periodic technical report, in the section
dedicated to WP8 ‘Dissemination and Exploitation”.

D8.4: Data Management Plan (updated during the project) Page 11

##  Next steps

In the next months, the Data Management Plan will be updated as the project
progresses and new needs may arise.

#  Bibliography

  1. Papadopoulos I (2006) Transcultural health and social care: development of culturally competent practitioners. Elsevier Health Sciences, 2006. 

  

  2. Hays R.D., Sherbourne C.D., Mazel R.M. (1993) The RAND 36-Item Health Survey 1.0. Health Econ 2(3): 217-27 

  

  3. Hofstede, G. (2001) Culture's Consequences: Comparing Values, Behaviors, Institutions and Organizations Across Nations. 2nd Edition, Thousand Oaks CA: Sage Publications. 

  

  4. Papadopoulos I, Tilki M, Lees S (2004) Promoting cultural competence in health care through a research based intervention. Journal of Diversity in Health and Social Care, 1(2): 107-115 

  

  5. Zarit S.H., Reever K.E., Bach-Peterson J. (1980) Relatives of the impaired elderly: correlates of feelings of burden. Gerontologist 20(6): 649-55. DOI: 10.1093/geront/20.6.649 

  

  6. Chin, J.P., Diehl, V.A., Norman, K.L. (1988) Development of an Instrument Measuring User Satisfaction of the Human-Computer Interface. CHI’88: 213-218 

  

  

#  Attachments

Attachment 1: The attachment reports the information uploaded using the online
tool for DMP preparation  ( _https://dmponline.dcc.ac.uk/_ )  .

D8.4: Data Management Plan (updated during the project) Page 12

**DMP title**

**Project Name** My plan (Horizon 2020 DMP) - DMP title

**Project Identifier** CARESSES

**Grant Title** 737858

**Principal Investigator / Researcher** Antonio Sgorbissa

**Description** The groundbreaking objective of CARESSES is to build
culturally competent care robots, able to autonomously re-configure their way
of acting and speaking, when offering a service, to match the culture, customs
and etiquette of the person they are assisting. By designing robots that are
more sensitive to the userâ€™s needs, CARESSESâ€™ innovative solution will
offer elderly clients a safe, reliable and intuitive system to foster their
independence and autonomy, with a greater impact on quality of life, a reduced
caregiver burden, and an improved efficiency and efficacy. The need for
cultural competence has been deeply investigated in the Nursing literature.
However, it has been totally neglected in Robotics. CARESSES stems from the
consideration that cultural competence is crucial for care robots as it is for
human caregivers. From the userâ€™s perspective, a culturally appropriate
behavior is key to improve acceptability; from the commercial perspective, it
will open new avenues for marketing robots across different countries.
CARESSES will adopt the following approach. First, we will study how to
represent cultural models, how to use these models in sensing, planning and
acting, and how to acquire them. Second, we will consider three (physically
identical) replicas of a commercial robot on the market and integrate cultural
models into them, by making them culturally competent. Third, we will test the
three robots, customized for three different cultures, in the EU (two cultural
groups) and Japan (one cultural group), on a number of elderly volunteers and
their informal caregivers. Evaluation will be conducted through quantitative
and qualitative investigation. To achieve its groundbreaking objective,
CARESSES will involve a multidisciplinary team of EU and Japanese researchers
with a background in Transcultural Nursing, AI, Robotics, Testing and
evaluations of health-care technology, a worldwide leading company in Robotics
and a network of Nursing care homes.

**Funder** European Commission (Horizon 2020)

**1\. Data summary**

**Provide a summary of the data addressing the following issues:**

**State the purpose of the data collection/generation**

**Explain the relation to the objectives of the project**

**Specify the types and formats of data generated/collected**

**Specify if existing data is being re-used (if any)**

**Specify the origin of the data**

**State the expected size of the data (if known)**

**Outline the data utility: to whom will it be useful**

Three datasets have been selected to be included in the Data Management Plan:

Dataset 1: Cultural Knowledge Base (CKB)

Dataset 2: Interaction logs (CKB)

Dataset 3: End-Users Responses (EUR)

**Dataset 1: Cultural Knowledge Base (CKB)**

_State the purpose of the data collection/generation_

The purpose of WP1 and WP2 is to: 1) collect the corpus of knowledge allowing
an assistive robot to exhibit a culturally competent behavior (with a specific
focus on the three cultures considered during the final testing stage); and 2)
formalize it in a framework allowing for the automated acquisition, update and
retrieval of culturerelated information. This framework is the Cultural
Knowledge Base, that will allow for performing a cultural assessment of the
user and aligning plans and sensorimotor behaviours to the user’s cultural
identity.

_Explain the relation to the objectives of the project_

The design and development of a framework for cultural knowledge
representation, allowing for the automated acquisition, update and retrieval
of culture-related information is the purpose of KRA2, and directly matching
the scientific objectives O2, O3, O4 and the technological objectives O5, O6
of the project. Moreover, the Cultural Knowledge Base is key to performing a
cultural assessment of the user and aligning plans and sensorimotor behaviours
to the user’s cultural identity, which is the main goal of the project.

_Specify the types and formats of data generated/collected_

_What format will your data be in (SPSS, Open Document Format, tab-delimited
format, etc)?_

The CKB will be an ontology written in the OWL 2 language  (
_https://www.w3.org/OWL/_ ).

_Why have you chosen to use a particular format?_

OWL is described as “a Semantic Web language designed to represent rich and
complex knowledge about things, groups of things, and relations between
things. OWL is a computational logic-based language such that knowledge
expressed in OWL can be exploited by computer programs, e.g., to verify the
consistency of that knowledge or to make implicit knowledge explicit.” (
_https://www.w3.org/OWL/_ ) As such, the language perfectly matches the
requirements for the Cultural Knowledge Base, as described in the previous
sections.

_Do the chosen formats and software enable sharing and long-term validity of
data?_

OWL and its current version OWL 2 are a standard developed by the W3C
consortium

( _http://www.w3.org/_ ), which is the main international standards
organization for the World Wide Web, and are arguably the most popular
knowledge representation language. OWL (OWL 2 since 2009) was first published
in 2004 and it has always been actively maintained by the W3C.

_Specify if existing data is being re-used_

_Are there any existing data or methods that you can reuse?_

We will reuse, as far as our application permits it, existing ontologies for
the description of concepts of relevance in the context of the CARESSES
project.

_Do you need to pay to reuse existing data?_

Many ontologies are published under licenses that allow for free use, sharing
and reuse, such as the CC BY 4.0 license (
_https://creativecommons.org/licenses/by/4.0/_ ). At the moment, there is no
evidence that we will have to reuse data which is not freely accessible.

_Are there any restrictions on the reuse of third-party data?_

We will refer to the licenses of the third-party ontologies we will include in
the CKB ontology (if any) to determine possible restrictions.

_Can the data that you create - which may be derived from third-party data -
be shared?_

We will refer to the licenses of the third-party ontologies we will include in
the CKB ontology (if any) to define the conditions under which the CKB can be
accessed, used and shared.

_Specify the origin of the data_

_How are the data produced and collected (possibly with reference to the
CARESSES WorkPlan)?_

Task 1.1, Task 1.2 and Task 1.3 are devoted to the identification, collection
and validation of all the knowledge required by culturally competent robots
for elderly assistance. At the same time, Task 2.1, Task 2.2 and Task 2.3 are
devoted to the identification and development of the framework and tools for
the representation of cultural knowledge. Task 1.4 is devoted to the
formalization of the knowledge collected in Tasks 1.1-3 with the tools
developed in Tasks 2.1-3

_State the expected size of the data_

_State the expected size, not necessarily in terms of “memory storage”; this
can be the number of records in a Database, a number of “facts” or “rules”,
values versus time, and so on._

Ontologies are usually described in terms of number of classes, properties,
datatypes and instances they provide (see for example the Time Ontology:

_http://lov.okfn.org/dataset/lov/vocabs/time_ ). As a reference, the DOGONT
ontology for the description of intelligent domotic environments

( _http://lov.okfn.org/dataset/lov/vocabs/dogont_ ) describes 893 classes and
74 properties.

_Outline the data utility: to whom it will be useful_

An ontology describing the corpus of knowledge required for culturally
competent assistive robots can be useful: 1) in the field of Robotics, as a
guideline and reference for the development of robots able to interact with
people while keeping cultural information into account; 2) in the field of
Transcultural Nursing, as a validated and publicly available ontology for the
description of concepts related to cultural competence and the detailing of a
number of cultures (specifically, the ones to be considered during the testing
phase of CARESSES).

_Please provide a concrete example of the data produced in the right format_

_Example 1: OWL ontology (with examples of object properties, data properties,
classes and individuals) describing some of the concepts contained in the CKB_

_ <?xml version="1.0"?> _

_ <rdf:RDF xmlns="http://example.com/caressesontology#"
xml:base="http://example.com/caressesontology" _

_[…]_

_xmlns:caressesontology="http://example.com/caressesontology#" > _

_ <owl:Ontology rdf:about="http://example.com/caressesontology"> _

_ <rdfs:comment>This is the Knowledge Base for Caresses</rdfs:comment>
</owl:Ontology> _

_ <!-- _

_///////////////////////////////////////////////////////////////////////////////////////_

_// Object Properties_

_///////////////////////////////////////////////////////////////////////////////////////_

_\-- > _

_ <!-- http://example.com/caressesontology#has_Positive \--> _

_ <owl:ObjectProperty
rdf:about="http://example.com/caressesontology#has_Positive"> _

_ <rdfs:domain rdf:resource="http://example.com/caressesontology#User"/> _

_ <rdfs:range rdf:resource="http://example.com/caressesontology#Topic"/>
</owl:ObjectProperty> _

_ <!-- _

_///////////////////////////////////////////////////////////////////////////////////////_

_// Data properties_

_///////////////////////////////////////////////////////////////////////////////////////
\-- > _

_ <!-- http://example.com/caressesontology#age --> _

_ <owl:DatatypeProperty rdf:about="http://example.com/caressesontology#age"> _

_ <rdfs:domain rdf:resource="http://example.com/caressesontology#User"/> _

_ <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> _

_ </owl:DatatypeProperty> _

_ <!-- http://example.com/caressesontology#gender \--> _

_ <owl:DatatypeProperty
rdf:about="http://example.com/caressesontology#gender"> _

_ <rdfs:domain rdf:resource="http://example.com/caressesontology#User"/> _

_ <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <!-- _

_///////////////////////////////////////////////////////////////////////////////////////_

_// Classes_

_///////////////////////////////////////////////////////////////////////////////////////_

_\-- > _

_ <!-- http://example.com/caressesontology#AlmondChicken \--> _

_ <owl:Class rdf:about="http://example.com/caressesontology#AlmondChicken"> _

_ <rdfs:subClassOf
rdf:resource="http://example.com/caressesontology#ChineseFood"/> _

_ <owl:disjointWith
rdf:resource="http://example.com/caressesontology#CantoneseFriedRice"/> _

_ <rdfs:comment>Almond chicken</rdfs:comment> _

_ </owl:Class> _

_ <!-- http://example.com/caressesontology#Badminton \--> _

_ <owl:Class rdf:about="http://example.com/caressesontology#Badminton"> _

_ <rdfs:subClassOf rdf:resource="http://example.com/caressesontology#Sport"/>
_

_ <rdfs:comment>Badminton</rdfs:comment> _

_ </owl:Class> _

_ <!-- _

_///////////////////////////////////////////////////////////////////////////////////////_

_// Individuals_

_///////////////////////////////////////////////////////////////////////////////////////_

_\-- > _

_ <!-- http://example.com/caressesontology#SCH_AlmondChicken \--> _

_ <owl:NamedIndividual
rdf:about="http://example.com/caressesontology#SCH_AlmondChicken"> _

_ <rdf:type rdf:resource="http://example.com/caressesontology#AlmondChicken"/>
_

_ <likeliness
rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal">0.7</likeliness> _

_ <neg>I really don’t like almond chicken</neg> _

_ <pos>Almond chicken is my favourite chinese food!</pos> _

_ <pos>Almond chicken is so tasty!</pos> _

_ <pos>Chinese almond chicken is lovely!</pos> _

_ <pos>I always eat almond chicken</pos> _

_ <pos>I love almond chicken!</pos> _

_ <poswait>Almond chicken is delicious, isn’t it?</poswait> _

_ <poswait>Do you know a good place here around where I can eat almond
chicken?</poswait> _

_ <poswait>Have you eaten almond chicken recently?</poswait> _

_ <poswait>What about some almond chicken today?</poswait> _

_ <que>Do you like almond chicken?</que> _

_ <topicname>AlmondChicken</topicname> _

_ <rdfs:comment>Topic Almond Chicken related to a Chinese User</rdfs:comment>
</owl:NamedIndividual> _

**Dataset 2: Interaction Logs (IL)**

_State the purpose of the data collection/generation_

The IL data set is the collection of messages shared among the CARESSES
components during interactions between the culturally competent robot and a
person. Each IL file captures the events occurred during the encounter, the
actions and status of the person (as perceived by the robot) and the actions
of the robot, and it is acquired to the aim of allowing offline analyses and
replays of the events occurred during the interaction.

_Explain the relation to the objectives of the project_

In the course of Task 5.6, the analysis of the Interaction Logs is key to
evaluate the performance of the components developed in WP2, WP3 and WP4,
which refer to the technical objectives O5-O12 of the project. In the context
of the end-user evaluation performed in WP7, the analysis of the Interaction
Logs collected during the tests in WP6 can help in assessing the performance
of the culturally competent assistive robot, which contributes to the
validation objective O15.

_Specify the types and formats of data generated/collected_

_What format will your data be in (SPSS, Open Document Format, tab-delimited
format, etc)?_

The IL data set will be a collection of text files in CSV format, which is
among the most readable formats for information storage. Each line corresponds
to a record, i.e. all the info related to a message shared over universAAL by
any of the software components of the culturally competent robot during an
encounter with a person. A record is divided into fields, separated by a
delimiter (e.g. a comma). Fields of relevance in our case include: 1)
timestamp of the message; 2) owner of the message; 3) content of the message.

_Why have you chosen to use a particular format?_

The CSV format is a very popular format for data exchange, widely supported by
consumer, business and scientific applications (e.g Microsoft Excel, MATLAB).
The fields to store in the IL records comply with popular standards for log
files (e.g. the ROS Bag file format for the log files of ROS applications
defined in  _http://wiki.ros.org/Bags/Format/2.0_ , or the Extended Log file
Format for the log files of web servers defined in  _http://www.w3.org/TR/WD-
logfile.html_ ). In particular, the ROS middleware (  _http://www.ros.org/_ )
is the de-facto standard in robotics applications and log files written in the
ROS Bag file format can be replayed and accessed within ROS by any other
component. Conversion from the CSV format to the ROS Bag file format is  not
difficult (see _http://answers.ros.org/question/119211/creating-a-ros-bag-
file-fromcsv-file-data/_ ).

_Do the chosen formats and software enable sharing and long-term validity of
data?_

The CSV format, is among the most readable formats for information storage,
supported by the vast majority of software for numerical and data analysis.

_Specify if existing data is being re-used_

_Are there any existing data or methods that you can reuse?_

No. The IL data will be entirely produced in the course of CARESSES, during
interactions between the culturally competent robot and a person.

_Can the data that you create - which may be derived from third-party data -
be shared?_

We do not foresee any restriction to sharing the IL data set.

_Specify the origin of the data_

_How are the data produced and collected (possibly with reference to the_

_CARESSES WorkPlan_

Interaction Logs are collected during two separate stages of the project: 1)
in the course of Task 5.6 (evaluation of the integrated CARESSES modules as
validation stage within the development process) and 2) in the course of Task
6.3 (experimental evaluation of the culturally competent robot with the
participants in the control and experimental groups) and Task 6.4
(experimental evaluation of the culturally competent robot in the smart house
iHouse).

_State the expected size of the data_

_State the expected size, not necessarily in terms of “memory storage”; this
can be the number of records in a Database, a number of “facts” or “rules”,
values versus time, and so on._

The IL data set will be described in terms of number of files (i.e., number of
recorded interactions between the culturally competent robot and a person) and
number of records in each file.

_Outline the data utility: to whom it will be useful_

The IL data set, as a collection of quantitative data describing interactions
between a person and an assistive robot can be useful to academic and
industrial researchers aiming at defining guidelines, best practices and
standards in the field of HumanRobot Interaction (e.g., identifying which
robot actions are frequently requested by people, identifying recurrent
sequences of robot actions – human actions that a robot could rely on to
exhibit predictive behaviours). Portions of the dataset may also be used by
roboticists for the development and testing of specific robotic applications
(e.g., the IL dataset can be used to train and test algorithms for learning
the habits/routines of a person from the analysis of recurring events).

_Please provide a concrete example of the data produced in the right format_

_Log of messages shared over universAAL, as provided by the universAAL
component Log Monitor_  
  
<table>  
<tr>  
<th>

Message

Type

</th>  
<th>

Timestamp

</th>  
<th>

Content

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

D5.1 _(user request)_

</td>  
<td>

1496049951891

</td>  
<td>

[Remind_medication : blue_pill : between 12.00 and

12.30]

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

D6.1 _(user state)_

</td>  
<td>

1496049973842

</td>  
<td>

[Greta : Greta Ahlgren : 10/04/2017: 12:05 : (2.3, 1.0,

0.0): (1.2, 0.0, 90.0) : Kitchen.FridgeArea : Standing :

\- : Cooking : Eating : Excited]

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

**Dataset 3: End-Users Responses (EUR)**

_State the purpose of the data collection/generation_

The end-user evaluation of the culturally competent robot performed within the
CARESSES project implies gathering the responses of the end user to a number
of tools (at present they include: Adapted CCA tool, SF-36, ZBI, QUIS) and the
transcripts of qualitative semi-structured interviews. The analysis of such
responses: 1) enables us to be able to describe the differences in baseline
characteristics of the clients within and between the arms they are allocated
to, which is crucial for controlling and thus minimizing the impact of
confounding variables; 2) allows for assessing the impact of the (culturally
competent) assistive robot in terms of quality of life, increased independence
and autonomy, health and care efficiency gains.

_Explain the relation to the objectives of the project_

The assessment of the impact of the culturally competent assistive robot on
the lives of elderly people and their informal carers is a key goal of the
whole CARESSES project. More specifically, the evaluation of the robot with
elderly participants belonging to different cultures refers to validation
objectives O15, O16 and O17.

_Specify the types and formats of data generated/collected_

_What format will your data be in (SPSS, Open Document Format, tab-delimited
format, etc)?_

Quantitative data collected from structured questionnaires will comply with
the SPSS v21 format. Qualitative data collected from semi-structured
interviews will be transcribed verbatim using Microsoft Word and subsequently
imported into QSR NVivo 11.

_Why have you chosen to use a particular format?_

We hold expertise in both SPSS and QSR NVivo, both of which are advanced and
appropriate analytical software tools.

_Do the chosen formats and software enable sharing and long-term validity of
data?_

Yes.

_Specify if exsisting data is being re-used_

_Are there any existing data or methods that you can reuse?_

No. The EUR data will be entirely produced in the course of CARESSES, during
interactions between the culturally competent robot and the end-users
recruited for the testing phase.

_Do you need to pay to reuse existing data?_

No, but we will need permission to use outcome tools of interest.

_Are there any restrictions on the reuse of third-party data?_

No.

_Can the data that you create - which may be derived from third-party data -
be shared?_

Yes within the CARESSES consortium. Anonymised / non-identifiable data will be
used in outputs.

_Specify the origin of the data_

_How are the data produced and collected (possibly with reference to the_

_CARESSES WorkPlan_

Quantitative data will be produced in the course of Tasks 6.1, 6.2, 6.3, 7.1,
7.3 through the following structured tools applied during the testing phase:

  * Background data: Cultural group, age, gender, client diagnosis, educational level,marital status, religion and religiosity, and data collected during screening (i.e. aggression, cognitive competence etc) 

  

  * Outcome data: Adapted RCTSH Cultural Competence Assessment Tool (CCATool, 

  

Papadopoulos et al., 2004), Short Form (36) Health Survey (SF-36 v2, Hays et
al 1993), the Zarit Burden Inventory (ZBI; Zarit et al., 1980), and
Questionnaire for user interface satisfaction (QUIS) (Chin et al, 1988). Also
we need to record screening results and response rates – all of this data will
be compiled into SPSS.

Qualitative data will be collected in the course of Tasks 6.1, 6.2, 6.3, 7.2,
7.3 during semi-structured interviews with clients and informal caregivers.

_State the expected size of the data_

_State the expected size, not necessarily in terms of “memory storage”; this
can be the number of records in a Database, a number of “facts” or “rules”,
values versus time, and so on._

SPSS database: 45 clients and up to 45 caregivers, background and screening
associated data per client, background data per caregiver, two time points for
SF 36 and ZBI, one time point for CCATool and QUIS. Therefore, approximately
90 rows and

100 columns of data

NVivo database: Transcripts of 15 clients and up to 15 caregivers

_Outline the data utility: to whom it will be useful_

Anyone involved with the analysis and dissemination activities associated with
WP7 data.

_Please provide a concrete example of the data produced in the right format_

_SPSS data:_

_Client number, cultural group, age, gender, diagnosis, educational level,
marital status, religion, religiosity, InterRai aggression, InterRai cognitive
competence, CCATool questions and scores, SF36 questions and scores, ZBI
questions and scores, QUIS questions and scores_  
  
<table>  
<tr>  
<th>

_1_

</th>  
<th>

_WE_

</th>  
<th>

_71_

</th>  
<th>

_M_

</th>  
<th>

_Mild dementia_

</th>  
<th>

_University degree_

</th>  
<th>

_Widowed_

</th>  
<th>

_C of E_

</th>  
<th>

_medium_

</th>  
<th>

_low_

</th>  
<th>

_high_

</th>  
<th>

_5_

</th>  
<th>

_…_

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

_2_

</td>  
<td>

_IND_

</td>  
<td>

_77_

</td>  
<td>

_F_

</td>  
<td>

_Depression_

</td>  
<td>

_College level_

</td>  
<td>

_Widowed_

</td>  
<td>

_Hinduisim_

</td>  
<td>

_low_

</td>  
<td>

_low_

</td>  
<td>

_high_

</td>  
<td>

_7_

</td>  
<td>

_…_

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

  2. **FAIR data**

  

  

**2.1 Making data findable, including provisions for metadata:**

**Outline the discoverability of data (metadata provision)**

**Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and unique identifiers such as**

**Digital Object Identifiers?**

**Outline naming conventions used**

**Outline the approach towards search keyword**

**Outline the approach for clear versioning**

**Specify standards for metadata creation (if any). If there are no standards
in your discipline describe what metadata will be created and how**

**Dataset 1: Cultural Knowledge Base (CKB)**

_Outline the discoverability of data (metadata provision)_

_What metadata, documentation or other supporting material should accompany
the data for it to be interpreted correctly?_

The Linked Open Vocabularies (LOV) initiative (
_http://lov.okfn.org/dataset/lov_ ) hosts a large number of vocabularies and
ontologies for the semantic web, and actively promotes the design and
publication of high quality ontologies. Their recommendations for the metadata
and documentation supporting an ontology are publicly available at
_http://lov.okfn.org/Recommendations_Vocabulary_Design.pdf_ . We will adhere,
as far as the peculiarities of our application allow it, to those guidelines
in the preparation of the metadata and documentation of the CKB. As an
example, the above recommendations define the fields and formats of the
metadata to associate to classes and properties as “rdfs:label” (element
title), “rdfs:comment” (element role), “rdfs:isDefinedBy” (explicit link
between an element and the namespace it belongs to),

“vs:term_status” (element status among “stable”, “testing”, “unstable”,
“deprecated”).

The ontology itself together with the metadata allow for the automatic
generation of documentation.

We will also provide as much as possible of the original cultural information
formalized in the CKB, to provide the rationale for the formalization we
propose and foster the research on, on the one hand, what knowledge makes for
a culturally competent robot and, on the other hand, how such knowledge should
be formalized for its effective use by the robot.

_What information needs to be retained to enable the data to be read and_

_interpreted in the future?_

The metadata written in accordance with the aforementioned recommendations and
the documentation automatically generated from the CKB ontology contain all
the information to be retained to ensure its readability.

_How will you capture / create the metadata?_

Metadata will be created and updated manually, concurrently with the data, in
the course of WP1 and WP2 as described in the above sections. The
creation/update of metadata, specifically consists in the writing of a number
of text fields for each element of the ontology.

_Can any of this information be created automatically?_

Metadata will be manually inserted in the CKB ontology. A number of tools
exist to automatically generate the documentation of an ontology starting from
its description and metadata in the OWL / RDF language, e.g. Parrot
_http://idi.fundacionctic.org/parrot/parrot_ .

_What metadata standards will you use and why?_

We will adhere to the recommendations for metadata and documentation of
ontologies drafted by the LOV initiative (publicly available at
_http://lov.okfn.org/Recommendations_Vocabulary_Design.pdf_ ), which are aimed
at maximizing the readability and usability of the ontology by other users.

Such guidelines require no big effort for the production of the metadata and
documentation and ensure the compatibility with the requirements of many
freely available tools, such as WebVOWL, for the interpretation and
visualization of ontologies (for example in the case of the Time ontology
_http://visualdataweb.de/webvowl/#iri=http://www.w3.org/2006/time_ ).

_Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and unique identifiers such as
Digital Object Identifiers?_

Once made publicly available, the CKB will be identified by a unique Uniform
Resource Identifier (URI). We will consider suggesting the CKB ontology for
inclusion in databases such as Protégé Ontology Library

( _https://protegewiki.stanford.edu/wiki/Protege_Ontology_Library_ ) and LOV,
which provides rich indexing and search tools.

_Outline naming conventions used_

A number of different style guidelines and naming conventions for ontologies
have been proposed. [1] surveys the most popular ones and tries to extrapolate
guidelines which are valid in a multilingual scenario. Considering the
intrinsic multilingual nature of the CARESSES project, we will adopt, whenever
possible, the guidelines they propose for multilingual applications.

[1] Montiel-Ponsoda, E., Vila Suero, D., Villazón-Terrazas, B., Dunsire, G.,
Escolano Rodríguez, E., & Gómez-Pérez, A. (2011). Style guidelines for naming
and labeling ontologies in the multilingual web.

_Outline the approach towards search keyword_

Indexing and search engines automatically identify the names of classes,
properties, datatypes and instances as valid search keywords (see for example
_http://lov.okfn.org/dataset/lov/about_ ).

_Outline the approach for clear versioning_

The metadata of the CKB ontology will include information about the date of
publication of the ontology (“dc:issued” element of the Dublic Core vocabulary
for resource description), date of the last modification (“dc:modified”),
version code

(“owl:versionInfo”) and change log with respect to the previous version
(rdfs:comment). In addition to this, popular Git repository hosting services
provide a large number of tools for version control.

_Specify standards for metadata creation (if any). If there are no standards
in your discipline describe what metadata will be created and how_

We will adhere, as far as the peculiarities of our project will allow it, to
the recommendations for metadata and documentation of ontologies drafted by
the LOV initiative (
_http://lov.okfn.org/Recommendations_Vocabulary_Design.pdf_ ).

**Dataset 2: Interaction Logs (IL)**

_Outline the discoverability of data (metadata provision)_

_What metadata, documentation or other supporting material should accompany
the data for it to be interpreted correctly?_

The IL data set requires documentation describing: 1) the system’s functional
architecture (in terms of what the different CARESSES components require and
provide and how they are connected) and 2) the details of the messages shared
over universAAL, that are stored in the IL files.

Metadata are divided in two categories. Metadata related to a IL file (e.g.
time and location of the recorded interaction) will be manually added to each
file. Metadata related to the messages (time, owner, message type) are stored
in the fields of each record together with the message content and will be
automatically associated to the messages by the logging tool.

_What information needs to be retained to enable the data to be read and
interpreted in the future?_

The documentation and metadata written in accordance with the aforementioned
specifications contain all the information to be retained to ensure the
readability of the IL files.

_How will you capture / create the metadata?_

IL files are automatically generated during an encounter between the
culturally competent robot and a person. As mentioned above, metadata related
to the messages (time, owner, message type) will be automatically created by
the universAAL communication middleware and stored in the IL files at runtime
by the logging tool. Metadata related to a IL file (e.g. time and location of
the recorded interaction) will be manually added at a later stage.

_Can any of this information be created automatically?_

Metadata related to the messages are automatically created by the universAAL
communication middleware. Some of the metadata related to a IL file (e.g.
starting time and location of the recorded interaction) can also be generated
automatically by the logging tool.

Documentation cannot be generated automatically.

_What metadata standards will you use and why?_

The rationale for choosing the metadata related to the messages, stored in the
fields of each record together with the message content, draws inspiration
from popular standards for log files (e.g. the ROS Bag file format for the log
files of ROS applications defined in  _http://wiki.ros.org/Bags/Format/2.0_ ,
or the Extended Log file Format for the log files of web servers defined in
_http://www.w3.org/TR/WD-logfile.html_ ). The notation and naming convention
will adhere with those of the universAAL platform.

_Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and unique identifiers such as
Digital Object Identifiers?_

Github (  _https://github.com/_ ) is among the largest and most popular
repository hosting services. Github repositories can be given a DOI and
released using the data archiving tool Zenodo (  _https://zenodo.org/_ ),
which also ensures that all metadata required for the identification of the
repository are filled before its public release. We will consider this option
for the publication of the IL dataset.

_Outline naming conventions used_

The metadata associated with the dataset itself with adhere to the conventions
of the chosen archiving tool (e.g., Zenodo). Metadata associated with files
and records with follow the naming convention of the universAAL platform.

_Outline the approach towards search keyword_

Archiving services such as Zenodo allow for specifying a list of search
keywords to associate with the dataset, as part of the publication process.

_Outline the approach for clear versioning_

Github (as most repository hosting services) provides a large number of tools
for version control, in particular allowing for making different releases of a
repository. By default, Zenodo takes an archive of the associated Github
repository every time a new release is created.

_Specify standards for metadata creation (if any). If there are no standards
in your discipline describe what metadata will be created and how_

The metadata requested by Zenodo for the publication of an archive comply with
several standard metadata format such as MARCXML, Dublin Core and DataCite

Metadata Schema (  _http://about.zenodo.org/policies/_ ).

**Dataset 3: End-Users Responses (EUR)**

_Outline the discoverability of data (metadata provision)_

_What metadata, documentation or other supporting material should accompany
the data for it to be interpreted correctly?_

The EUR data set requires metadata describing the real-world meaning of
values, variables and files, as well as technical information such as variable
types and formats. Qualitative metadata pertaining to the file type, data
source, the geographic and temporal coverage, source descriptions,
annotations, coding structures and explanations will be documented,

_What information needs to be retained to enable the data to be read and
interpreted in the future?_

The metadata written in accordance with the aforementioned specifications
contain all the information to be retained to ensure the readability of the
EUR data.

_How will you capture / create the metadata?_

SPSS stores all metadata associated with a dataset in a Dictionary, and
provides tools for its creation, validation and export in easily readable
formats. The SPSS Dictionary will be created together with the insertion of
the quantitative EUR data in SPSS. QSR NVivo 11 also enables data management
including providing tools for documentation files, classification and
attributes, and enables exporting into a wide range of formats appropriate for
archiving.

_Can any of this information be created automatically?_

SPSS metadata to be stored in the Dictionary will be created manually. For
NVivo, a log of information about the data sources, editing done, coding and
analysis carried out is created automatically. Other information will be
created manually.

_What metadata standards will you use and why?_

Metadata and documentation standards will adhere to those described by the UK
Data

Archive (  _http://www.data-archive.ac.uk/_ ), which is the UK’s largest
collection of digital research data in the social sciences and humanities and
is connected to a network of data archives across the world.

_Outline the identifiability of data and refer to standard identification
mechanism. Do you make use of persistent and unique identifiers such as
Digital Object Identifiers?_

The UK Data Archive supports the use of persistent identifiers across its work
so that data, metadata and other outputs can be reliably referenced and
linked, in particular promoting the association of data sets with the ORCID of
the contributors and with DataCite DOIs for persistent data citation. Other
archives, such as Zenodo  ( _https://zenodo.org/_ ), allow for associating a
DOI to the data sets. We will consider these options for the publication of
the EUR data set.

_Outline naming conventions used_

The EUR data set will adhere, as far as possible, to the conventions of the
chosen archiving service (e.g., UK Data Archive, Zenodo) and of the tools it
refers to.

_Outline the approach towards search keyword_

Both aforementioned archiving services make sure that search keywords and
metadata required for finding the data set with their search tools are
provided as part of the publication process.

_Outline the approach for clear versioning_

A number of solutions for clear versioning of the EUR data set are available.
Most metadata standards (e.g. Dublin Core) allow for specifying the version
and other related information inside the data set. Moreover, a number of
repository hosting services (e.g. Github) provide a large number of tools for
version control, in particular allowing for making different releases of a
repository.

_Specify standards for metadata creation (if any). If there are no standards
in your discipline describe what metadata will be created and how_

Metadata creation of the quantitative and qualitative data will adhere to the
standards described by the UK Data Archive. It is important to mention that
the UK Data Archive is a member of the Data Documentation Initiative, whose
aims include the development of robust metadata standards for social science
data.

**2.2 Making data openly accessible:**

**Specify which data will be made openly available? If some data is kept
closed provide rationale for doing so**

**Specify how the data will be made available**

**Specify what methods or software tools are needed to access the data? Is
documentation about the software needed to access the data included? Is it
possible to include the relevant software (e.g. in open source code)?**

**Specify where the data and associated metadata, documentation and code are
deposited**

**Specify how access will be provided in case there are any restrictions**

**Dataset 1: Cultural Knowledge Base (CKB)**

_Is the data made openly available (YES/NO/PARTIALLY)_

YES

_Specify how and where (in which repository) the data will be made available_

For the storage of the CKB ontology we will consider different solutions,
evaluating their performance in terms of data persistence, security and
accessibility. To allow other researchers to easily find the ontology, we will
apply for its insertion in popular ontology libraries and search engines, such
as Protégé Ontology Library, LOV and

Google.

_Specify what methods or software tools are needed to access the data?_

_Name the required methods or software tools_

A list of existing tools for accessing, visualizing and managing ontologies
such as the

CKB ontology is available at:
_https://en.wikipedia.org/wiki/Ontology_(information_science)#Editor_

_Is the software pre-existing or developed as an output of CARESSES_

All the tools listed above are pre-existing and independent from CARESSES.

_Is documentation about the software available to access the data included?_

Most of the tools listed above provide documentation and support (see for
example

Protégé:  _http://protege.stanford.edu/_ )

_Is it possible to include the relevant software (e.g. in open source code)?_

Many of the tools listed above (e.g. Protégé) are open source.

**Dataset 2: Interaction Logs (IL)**

_Is the data made openly available (YES/NO/PARTIALLY)_

YES

_Specify how and where (in which repository) the data will be made available_

We are considering to publish the IL dataset on a public Github repository and
to use

Zenodo for assigning it a DOI.

_Specify what methods or software tools are needed to access the data?_

_Name the required methods or software tools_

Files in the CSV format can be accessed by a wide variety of software
applications, including proprietary (e.g., Microsoft Excel, MATLAB) and open
source applications (e.g. Open Office Calc, Octave, R).

_Is the software pre-existing or developed as an output of CARESSES_

All the applications mentioned above are pre-existing and independent from

CARESSES.

According to the needs of the project, we will maybe develop software
applications (e.g. ROS packages) or scripts for existing software (e.g. MATLAB
or R scripts) specifically for the management of the data within the IL files.
In such case, we will consider publishing such code together with the dataset.

_Is documentation about the software available to access the data included?_

Most of the applications mentioned above come with rich documentation and
support  functionalities (see for example MATLAB
_https://uk.mathworks.com/support/?_

_s_tid=gn_supp_ ).

_Is it possible to include the relevant software (e.g. in open source code)?_

The applications mentioned above which are not open source (e.g. Microsoft
Excel, MATLAB) provide free trials. Moreover, both Microsoft and Mathworks
have special licensing contracts for students and academic institutions.

**Dataset 3: End-Users Responses (EUR)**

_Is the data made openly available (YES/NO/PARTIALLY)_

PARTIALLY

_If some data is kept closed provide rationale for doing so_

We will withhold screening data (pertaining to cognitive competence and
aggression) since this data is purely used to determine their eligibility
rather than for data analysis.

_With whom will you share the data, and under what conditions?_

This data will not be shared unless we consider the data to be of considerable
health importance to the research participant. In this case we shall be guided
by our incidental findings policy and may in some cases disclose this data to
the research participant.

_Specify how and where (in which repository) the data will be made available_

We are considering to publish the EUR dataset in the UK Data Archive or
Zenodo.

Specify what methods or software tools are needed to access the data?

_Name the required methods or software tools_

Quantitative data in SPSS format (.sav) can be accessed with IBM SPSS  (
_https://www.ibm.com/analytics/us/en/technology/spss/_ ), and open source data
analysis software such as R (  _https://www.r-project.org/_ ). Both software
allow for exporting the data set in a number of other formats, including
Microsoft Excel format (.xls, xlsx) and CSV.

Qualitative data in Microsoft Word format (.doc, .docx) can be accessed with
Microsoft

Word and open source text editing software such as Apache OpenOffice  (
_https://www.openoffice.org/_ ).

_Is the software pre-existing or developed as an output of CARESSES_

All the applications mentioned above are pre-existing and independent from

CARESSES.

_Is documentation about the software available to access the data included?_

Most of the applications mentioned above come with rich documentation and
support functionalities (see for example R
_https://cran.r-project.org/manuals.html_ ).

_Is it possible to include the relevant software (e.g. in open source code)?_

The applications mentioned above which are not open source (e.g. IBM SPSS,
Microsoft Word) provide free trials.

**2.3 Making data interoperable:**

**Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability.**

**Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies?**

**Dataset 1: Cultural Knowledge Base (CKB)**

_Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability_

Ontologies themselves are a tool for interoperability. Within CARESSES, the
CKB ontology constitutes the vocabulary for the culturally competent assistive
robot to be developed in the course of the project and facilitates the use and
interaction among all software tools developed within the project. In its
construction, whenever possible, we will adopt terms and definitions which are
standard in the field or culture they refer to.

_Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies?_

When and however possible, we will refer to standard vocabularies.

**Dataset 2: Interaction Logs (IL)**

_Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability_

Zenodo complies with several standard metadata format such as MARCXML, Dublin

Core and DataCite Metadata Schema (  _http://about.zenodo.org/policies/_ ).
Moreover, the CSV format is among the most readable formats for information
storage, supported by the vast majority of software for numerical and data
analysis.

_Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies?**)** _

We will provide mapping to the CKB ontology, as well as other existing
vocabularies, whenever possible.

**Dataset 3: End-Users Responses (EUR)**

_Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability_

Zenodo complies with several standard metadata format such as MARCXML, Dublin
Core and DataCite Metadata Schema (  _http://about.zenodo.org/policies/_ ).

Quantitative data in the EUR dataset will comply with the data vocabulary of
the tools they refer to, thus ensuring exchange and re-use by any researcher
making use of the same or compatible tools. We will try to adhere, as far as
our application permits it, to the European Language Social Science Thesaurus
(ELSST  _https://elsst.ukdataservice.ac.uk/elsst-guide/elsst-structure_ ).

_Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies?_

We will provide mapping to the ELSST thesaurus, the CKB ontology, as well as
other existing vocabularies, whenever possible.

**2.4 Increase data re-use (through clarifying licenses):**

**Specify how the data will be licenced to permit the widest reuse possible
Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed**

**Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project? If the re-use of
some data is restricted, explain why**

**Describe data quality assurance processes**

**Specify the length of time for which the data will remain re-usable**

**Dataset 1: Cultural Knowledge Base (CKB)**

_Specify how the data will be licensed to permit the widest reuse possible_

_Who owns the data?_

The matter of the ownership of data produced within the project is discussed
in the Coordination Agreement among partners. This matter will be handled
under the supervision of the Exploitation, Dissemination and IPR board.

_How will the data be licensed for reuse?_

Licensing terms will be defined by the CARESSES partners and in accordance
with the restrictions, if any, of any third-party data used in the CKB
ontology.

_If you are using third-party data, how do the permissions you have been
granted affect licensing?_

A number of ontologies (such as the Time Ontology from W3C) grant “permission
to copy, and distribute their contents in any medium for any purpose and
without fee or royalty”. We will keep the licensing terms of any third-party
ontology we will use in the CKB ontology into account in the definition of the
licensing terms of the CKB ontology

itself.

_Will data sharing be postponed / restricted e.g. to seek patents?_

Probably not. However, it will most likely be postponed to comply with
publication regulations. This matter will be handled under the supervision of
the Exploitation,

Dissemination and IPR board.

_Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed (no later than
publication of the main findings and should be in-line with established best
practice in the field)_

According to the CARESSES Work plan, the CKB ontology will be ready for
publication approx. from month 25 (third year of the project). The CKB
ontology will be officially publicly released upon the publication of related
articles.

_Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project?_

_Who may be interested in using your data?_

As previously stated, we envision the CKB ontology to be especially useful
for: 1) researchers in the field of Robotics, who may use it as a guideline
and reference for the development of robots able to interact with people while
keeping cultural information into account; 2) companies producing robots and
other devices for personal assistance, who may use it as a source of validated
information for a number of cultures (specifically, the ones to be considered
during the testing phase of CARESSES), allowing for culture-aware human-robot
interaction; 3) researchers and practitioners in the field of Transcultural
Nursing, who may use it as a validated and publicly available ontology for the
description of concepts related to cultural competence and the detailing of a
number of cultures.

_What are the further intended or foreseeable research uses for the data?_

See above

_If the re-use of some data is restricted, explain why_

At the moment, we do not foresee any restriction on the re-use of the CKB
ontology.

_Describe data quality assurance processes_

“Data quality” can be defined in terms of syntactic, semantic and pragmatic
quality (see

ISO 8000-8:2015).

A number of ontology editors, such as Protégé, provide tools for automatically
detecting inconsistencies in the ontology and checking its validity. Moreover,
there exist publicly available tools, such as Oops! (
_http://oops.linkeddata.es/_ ) which automatically check for anomalies, errors
and lack of metadata for documentation. As an example, the full catalogue of
pitfalls detected by Oops! Is available at
_http://oops.linkeddata.es/catalogue.jsp_ . The pragmatic quality of the CKB
ontology (i.e., whether it fits for its intended use) will be checked during
its creation by the experts involved in the CARESSES project, and
experimentally evaluated in the testing phase of the project.

_Specify the length of time for which the data will remain re-usable_

Forever.

**Dataset 2: Interaction Logs (IL)**

_Specify how the data will be licensed to permit the widest reuse possible_

_Who owns the data?_

The matter of the ownership of data produced within the project is discussed
in the Coordination Agreement among partners. This matter will be handled
under the supervision of the Exploitation, Dissemination and IPR board.

_How will the data be licensed for reuse?_

Licensing terms will be defined by the CARESSES partners.

_If you are using third-party data, how do the permissions you have been
granted affect licensing?_

We do not foresee the use of any third-party data in the IL dataset.

_Will data sharing be postponed / restricted e.g. to seek patents?_

Probably not. However, it will most likely be postponed to comply with
publication regulations. This matter will be handled under the supervision of
the Exploitation,

Dissemination and IPR board.

_Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed (no later than
publication of the main findings and should be in-line with established best
practice in the field)_

According to the CARESSES Work plan, Interaction Logs are collected in two
separate stages of the project: first in the course of Task 5.6 (m23 – m27)
and then in the course of Task 6.3 (m28-m33) and Task 6.4 (m28-m33). As such,
the first portion of the IL data set will be ready for publication approx.
from month 27, while the second portion of the IL data set will be ready for
publication approx. from month 37(end of the project) and it will be
officially publicly released upon the publication of related articles.

_Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project?_

_Who may be interested in using your data?_

As previously stated, we envision the IL data set to be useful for academic
and industrial researchers aiming at defining guidelines, best practices and
standards in the field of Human-Robot Interaction (e.g., identifying which
robot actions are frequently requested by people, identifying recurrent
sequences of robot actions – human actions that a robot could rely on to
exhibit predictive behaviours). Portions of the dataset may also be used by
roboticists for the development and testing of specific robotic applications
(e.g., the IL dataset can be used to train and test algorithms for learning
the habits/routines of a person from the analysis of recurring events).

_What are the further intended or foreseeable research uses for the data?_

See above

_If the re-use of some data is restricted, explain why_

At the moment, we do not foresee any restriction on the re-use of the IL data
set.

_Describe data quality assurance processes_

“Data quality” can be defined in terms of syntactic, semantic and pragmatic
quality (see ISO 8000-8:2015) or, in other words, in terms of completeness,
validity, accuracy, consistency.

Data completeness indicates whether all the data necessary to meet the current
(and possibly future) information demand are available. By design, the IL data
set fulfills the requirements of the culture-aware robot developed in the
CARESSES project, thus ensuring that it contains sufficient information for an
assistive robot to have meaningful interactions with a person. Data validity
will be assessed in WP2, WP3 and WP4, as part of the development process of
the software modules producing the messages to be stored in the IL data set.
Data accuracy and consistency refer to whether the values stored are correct
or not. Since the data to be stored in the IL data set are used by the
culturally competent robot to tune its behavior towards the assisted person,
one of the goals of the project is to maximize their reliability. To allow for
a quantitative assessment of the accuracy of the data in the IL data set, we
will consider providing, together with the portion of the IL data set acquired
in Task 5.6 in lab conditions, supporting material providing the ground truth
of the stored data.

_Specify the length of time for which the data will remain re-usable_

Forever.

**Dataset 3: End-Users Responses (EUR)**

_Specify how the data will be licensed to permit the widest reuse possible_

_Who owns the data?_

The matter of the ownership of data produced within the project is discussed
in the Coordination Agreement among partners. This matter will be handled
under the supervision of the Exploitation, Dissemination and IPR board.

_How will the data be licensed for reuse?_

Licensing terms will be defined by the CARESSES partners.

_If you are using third-party data, how do the permissions you have been
granted affect licensing?_

We do not foresee the use of any third-party data in the EUR dataset.

_Will data sharing be postponed / restricted e.g. to seek patents?_

Probably not. However, it will most likely be postponed to comply with
publication regulations. This matter will be handled under the supervision of
the Exploitation,

Dissemination and IPR board.

_Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed (no later than
publication of the main findings and should be in-line with established best
practice in the field)_

According to the CARESSES Work plan, End-Users Responses are defined,
structured and collected in the course of Tasks 6.1, 6.2 and 6.3, which span
months 19 to 33 of the project. Quantitative data are then post-processed and
analysed in the course of Tasks 7.1 and 7.3, which span months 27 to 37 of the
project, while qualitative data are post-processed and analysed in the course
of Tasks 7.2 and 7.3, which span months 29 to 37. The EUR data set will
therefore be ready for publication approx. from month 37(end of the project)
and it will be officially publicly released upon the publication of related
articles.

_Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project?_

_Who may be interested in using your data?_

We envisage that the EUR data will be useful for academics interested in
conducting secondary analysis. This could include academics interested in the
acceptability and clinical or cost-effectiveness impact of culturally aware
robots, but also those interested in our baseline characteristics and outcome
measurement data.

_What are the further intended or foreseeable research uses for the data?_

See above

_If the re-use of some data is restricted, explain why_

At the moment, we do not foresee any restriction on the re-use of the EUR data
set.

_Describe data quality assurance processes_

“Data quality” can be defined in terms of syntactic, semantic and pragmatic
quality (see ISO 8000-8:2015) or, in other words, in terms of completeness,
validity, accuracy, consistency.

We will strive for data completeness by constructing methodological protocols
and tools that are user-friendly and sensitive. For the quantitative data, to
increase the likelihood of validity and accuracy, we will employ existing
widely used, previously validated data collection instruments such as the
SF-36 and ZBI. For all of the quantitative tools we employ, we shall conduct a
series of Cronbach’s Alphacoefficient tests in SPSS. This will also help with
establishing internal consistency. Further, we shall conduct Cohen’s kappa
tests to establish the degree of inter-rater consistency between the
researchers collecting data. To help boost the likelihood of consistency being
achieved, the research team will be trained to follow the same strict
protocols throughout. For qualitative data, to help boost the trustworthiness
of our analysis we should engage in respondent validation exercises with our
participants. Our interview schedules and data collection processes will be
sensitive and planned so that they are likely to be complete and effective.

_Specify the length of time for which the data will remain re-usable_

Forever.

**3\. Allocation of resources**

**Explain the allocation of resources, addressing the following issues:**

**Estimate the costs for making your data FAIR. Describe how you intend to
cover these costs**

**Clearly identify responsibilities for data management in your project**

**Describe costs and potential value of long term preservation**

**Dataset 1: Cultural Knowledge Base (CKB)**

_Estimate the costs for making your data FAIR. Describe how you intend to
cover these costs (costs related to open access to research data are eligible
as part of the Horizon_

_2020 gran)_

The costs of making the CKB ontology FAIR are included in Task 2.6.

_Describe costs and potential value of long term preservation_

Once the CKB ontology is publicly available, the only foreseeable cost for its
preservation is the cost of the repository hosting service where it is
located.

**Dataset 2: Interaction Logs (IL)**

_Estimate the costs for making your data FAIR. Describe how you intend to
cover these costs (costs related to open access to research data are eligible
as part of the Horizon_

_2020 gran)_

The costs of making the IL data set FAIR are included in Task 5.6 (for the
first portion of the data set) and in Task 7.3 (for the second portion of the
data set). The cost and effort of making the second portion of the data set
FAIR is expected to be significantly lower than that of the first portion of
the data set.

_Describe costs and potential value of long term preservation_

Once the IL data set is publicly available, the only foreseeable cost for its
preservation is the (eventual) cost of the repository hosting service where it
is located.

**Dataset 3: End-Users Responses (EUR)**

_Estimate the costs for making your data FAIR. Describe how you intend to
cover these costs (costs related to open access to research data are eligible
as part of the Horizon 2020 grant)_

SPSS and NVivo 11 licensing costs may be applicable. Otherwise we do not
envisage any additional costs associated with making our data FAIR.

_Describe costs and potential value of long term preservation_

Once the data set is publicly available, the only foreseeable cost for its
preservation is the (eventual) cost of the repository hosting service where it
is located.

**4\. Data security**

**Address data recovery as well as secure storage and transfer of sensitive
data Dataset 1: Cultural Knowledge Base (CKB)**

_Specify if the data should be safely stored in certified repositories for
long term preservation and curation.**)** _

We are considering applying for the inclusion of the CKB ontology in well
known collections of Ontologies (we will apply for its insertion in popular
ontology libraries and search engines, such as the Protégé Ontology Library,
LOV and Google) to make it publicly available to a large audience. We will
host the CKB ontology on a repository which provides adequate guarantees in
terms of data persistence, security and accessibility.

_Is your data sensitive (e.g. detailed personal data, politically sensitive
information or trade secrets)? (YES/NO)_

NO

**Dataset 2: Interaction logs (IL)**

_Specify if the data should be safely stored in certified repositories for
long term preservation and curation._

We are considering archiving the IL data set with the Zenodo data archiving
tool to ensure long term preservation and curation.

_Is your data sensitive (e.g. detailed personal data, politically sensitive
information or trade secrets)? (YES/NO)_

NO

**Dataset 3: End-Users Responses (EUR)**

_Specify if the data should be safely stored in certified repositories for
long term preservation and curation._

We are considering archiving the EUR data set with the Zenodo data archiving
tool to ensure long term preservation and curation.

_Is your data sensitive (e.g. detailed personal data, politically sensitive
information or trade secrets)? (YES/NO)_

NO

**5\. Ethical aspects**

**To be covered in the context of the ethics review, ethics section of DoA and
ethics deliverables. Include references and related technical aspects if not
covered by the former**

**Dataset 1: Cultural Knowledge Base (CKB)**

_Are the data acquired by carrying out research involving human participants?
(YES/NO)_

YES

_If the answer is YES,_

_Specify the procedure established to gain consent for data preservation and
sharing_

Human participants will be involved in the collection and validation of
culture-specific information. Participants’ responses will be merged and
generalized, and no personspecific detail will be stored in the CKB ontology
(which, by design, captures cultural information at a national/group level).
Therefore, data not fall under the General Data Protection Regulation (EU)
2016/679. All of the data will be collected in an ethically appropriate manner
and with Ethics Committee approval.

_Specify how will sensitive data be handled to ensure it is stored and
transferred securely_

No sensitive data will be stored in the CKB ontology.

_Specify how will you protect the identity of participants, e.g. via
anonymisation or using managed access procedures_

No personal data about the participants will be stored in the CKB ontology.

_Are the data acquired by carrying out research involving human participants?_

_(YES/NO)_

YES

**Dataset 2: Interaction logs (IL)**

_If the answer is YES,_

_Specify the procedure established to gain consent for data preservation and
sharing_

Human participants will be involved in the collection of recordings of
interactions between the culturally competent robot and a person.

By design, the IL data set does not contain any person-specific detail, since
it only captures events and status information which are of relevance for the
robot to plan and tune its behavior. Moreover, messages refer to participants
only by an ID which ensures the protection of their identity both during the
experiments and in the public IL data set. Therefore, data not fall under the
General Data Protection Regulation (EU) 2016/679. All of the data will be
collected in an ethically appropriate manner and with Ethics Committee
approval.

_Specify how will sensitive data be handled to ensure it is stored and
transferred securely_

No sensitive data will be stored in the IL data set.

_Specify how will you protect the identity of participants, e.g. via
anonymisation or using managed access procedures_

No personal data about the participants will be stored in the IL data set.
Moreover, participants will be exclusively identified by an ID.

**Dataset 3: End-Users Responses (EUR)**

_Are the data acquired by carrying out research involving human participants?_

YES

If the answer is YES,

_Specify the procedure established to gain consent for data preservation and
sharing_

Ethical approval from appropriate bodies will be defined before the
experiments and participants will be asked to provide informed consent for
their participation in the study. This will include consent for data
preservation and sharing.

_Specify how will sensitive data be handled to ensure it is stored and
transferred securely_

The data will be collected following informed consent and will be
pseudonymized, in compliance with the General Data Protection Regulation (EU)
2016/679.

_Specify how will you protect the identity of participants, e.g. via
anonymisation or using managed access procedures_

As above (via pseudonymized)

**6\. Other**

**Refer to other national/funder/sectorial/departmental procedures for data
management that you are using (if any)**

We do not consider other procedures for data management.