D4.2 - Peer Search in Smart Societies

SmartSociety

Hybrid and Diversity-Aware Collective Adaptive SystemsWhen People Meet Machines to Build a Smarter Society

Grant Agreement No. 600584

Deliverable D4.2 Working Package 4

Peer Search in Smart Societies

Dissemination Level(Confidentiality):1

PU

Delivery Date in Annex I: December 31, 2014Actual Delivery Date January 16, 2015Status2 FTotal Number of pages: 71Keywords: peers, profiles, privacy protection,

search, ranking

1PU: Public; RE: Restricted to Group; PP: Restricted to Programme; CO: Consortium Confi-dential as specified in the Grant Agreeement

2F: Final; D: Draft; RD: Revised Draft

c© SmartSociety Consortium 2013-2017 Deliverable D4.2

2 of 71 http://www.smart-society-project.eu

Deliverable D4.2 c© SmartSociety Consortium 2013-2017

Disclaimer

This document contains material, which is the copyright of SmartSociety Consortium

parties, and no copying or distributing, in any form or by any means, is allowed without

the prior written agreement of the owner of the property rights. The commercial use of

any information contained in this document may require a license from the proprietor of

that information. Neither the SmartSociety Consortium as a whole, nor a certain party of

the SmartSocietys Consortium warrant that the information contained in this document

is suitable for use, nor that the use of the information is free from risk, and accepts no

liability for loss or damage suffered by any person using this information. This document

reflects only the authors’ view. The European Community is not liable for any use that

may be made of the information contained herein.

Full project title: SmartSociety: Hybrid and Diversity-Aware CollectiveAdaptive Systems: When People Meet Machines toBuild a Smarter Society

Project Acronym: SmartSociety

Grant Agreement Number: 600854

Number and title of work-package:

4 Peer Modeling and Search

Document title: Peer Search in Smart Societies

Work-package leader: Alethia Hume, UNITN

Deliverable owner: Alethia Hume, UNITN

Quality Assessor: Hong-Linh Truong, TU WIEN

c© SmartSociety Consortium 2013-2017 3 of 71


List of Contributors

Partner Acronym ContributorUNITN Ronald Chenu-AbenteUNITN Vincenzo MalteseUNITN Alethia HumeUNITN Uladzimir KharkevichKU Simone Fischer-HubnerKU Leonardo Martucci



Executive Summary

This deliverable reports the evolution of the work done in WP4 during the second year of

the project, in particular it reports the work done on tasks T4.1(privacy-friendly profiling

of peers and representation of atomic tasks), T4.2 (matching atomic-task with peers), and

T4.3 (ranking matching results). Furthermore, the appendix and the year two SmartSo-

ciety Platform integrated demo also contain the first results from T4.4 (implementation

and application). In general the main focus of this year of work was on defining models

and mechanisms to accomplish these tasks while also complying and using as a base the

requirements identified during the first year.

The main WP4-related outcome during the second year of the Smart Society project

is the definition and early prototype implementation of the Peer Manager component,

which is projected to become the main storage for peer information in the SmartSociety

platform and a fundamental building block for managing the information of peers in a

privacy-preserving manner.

More specifically, the definition of the Peer Manager presented in this document in-

cludes:

1. An attribute-based model for data and knowledge representation, which provides

an underlying model for the representation of information related to peers (i.e.,

humans/machines and collectives) and the tasks that they can perform.

2. A model for privacy-aware storage and sharing that introduces the main elements

for the implementation of a privacy-preserving Peer Manager.

3. The mechanisms for search and ranking peers based on the attributes that allow them

to solve a task; and designed upon a privacy-preserving framework thus paying close

attention to privacy issues.

4. The definition of a privacy-by-design architecture for the Peer Manager that is able

to provide the previous services effectively while complying with current European

laws on privacy and being able to enforce the privacy policies defined by each user.

While an initial prototype of the Peer Manager was developed during this year, a more

complete implementation and integration of models and mechanisms proposed during this

year is planned for the next year of the project (year three of SmartSociety).



Table of Contents

1 Introduction 8

2 Attribute-based Peer and Task Modeling 9

2.1 Ground Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 The Peer Manager Core Ontology . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Guidelines followed for the development of the ontology . . . . . . . 11

2.2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.3 Entity classes, relations and attributes . . . . . . . . . . . . . . . . . 13

2.3 Core Entity Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Attribute-based Privacy-enhanced Model 15

3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 The Peer Manager Model Privacy-enhancing Structures . . . . . . . . . . . 17

3.2.1 Peers as distributed storage providers. . . . . . . . . . . . . . . . . . 17

3.2.2 Users structures as subject pseudonyms. . . . . . . . . . . . . . . . . 19

3.2.3 Profiles as object indirections. . . . . . . . . . . . . . . . . . . . . . . 20

4 Privacy-aware Search and Ranking 22

4.1 Attribute-based Search: Defining Search Constraints . . . . . . . . . . . . . 22

4.2 Attribute-based Ranking: Defining Order or Distance Function . . . . . . . 25

4.3 Privacy-aware Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 The Peer Manager Architecture 28

5.1 Peer Manager Internal Architecture . . . . . . . . . . . . . . . . . . . . . . . 28

5.2 The Peer Base Structures and Hybridity Support . . . . . . . . . . . . . . . 30

5.3 The Peer Manager as Part of the SmartSociety Platform . . . . . . . . . . . 31

5.4 Second Year Peer Manager Integrated Proof of Concept . . . . . . . . . . . 32

6 Conclusion and Final Remarks 33

A The Peer Manager Entity Types 38

A.1 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A.2 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38



A.3 Person . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A.4 Software agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A.5 Collective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A.6 Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

A.7 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

A.8 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

A.9 Artifact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

A.10 Mind Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

A.11 Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

A.12 File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A.13 Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A.14 Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

A.15 Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

A.16 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

B Study on Personal Data 46

C Aligning WP1 and WP2 Formal Models 53

D Ethical and Privacy issues 55

D.1 Social and Ethical Issues of Profiles . . . . . . . . . . . . . . . . . . . . . . . 56

D.2 Privacy Issues of Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

E Policy Example 60

F Implementation 66

F.1 Implementation Details and Choices . . . . . . . . . . . . . . . . . . . . . . 66

F.2 Year Two Peer Manager Integrated Proof-of-Concept . . . . . . . . . . . . . 66

F.3 Proof-of-Concept Integration Calls Specification . . . . . . . . . . . . . . . . 67



1 Introduction

The overall objective of WP4 in the SmartSociety project is to provide mechanisms for

the representation of peers and atomic-tasks; and to enable finding peers based on the

characteristics that allow them to fulfil the requirements of a given atomic-task. Because

the context of the project involves dealing with peers that can be human and therefore

manipulating possibly sensitive data (for instance, personal information), in WP4 it is

also fundamental to account for privacy concerns that may arise in relation with these

objectives.

During the first year of the project we focused on the analysis and study of require-

ments derived from the above mentioned objectives within the context of hybrid and

diversity aware collective adaptive systems (HDA-CAS). The results of this initial work

were reported in deliverable D4.1, which included early ideas related to the representa-

tion of peers (using profiles) as well as the introduction of instruments and mechanisms

that can be used to construct profiles of peers. The deliverable D4.1 also included the

identification and discussion of legal privacy requirements for such a system.

Finally, in order to be able to ground the discussions in this deliverable to concrete

examples, we would like to introduce a few reference scenarios that will be used in the

rest of the deliverable when explaining how the different proposed mechanisms can be

concretely applied.

• Example Scenario 1. Maria lives in Milan and she, for work reasons, has to commute

to Trento on a periodic basis. She has a car but she usually travels alone, leaving her

with 4 empty seats in her car. In order to share some of the expenses of the trips and

maybe having also someone to talk to, she wishes to share rides with other commuters

(offer rides). However, she is concerned about sharing her private information openly

in social networks or other platforms that may make this information public and

easily accessible to everyone. As such, she would like to reveal only the minimal

required information for the ride-sharing and, above all, she wishes to maintain full

control over her personal data should she decide to withdraw from the platform.

• Example Scenario 2. Marco, who has lived in Milan his whole life, is passionate

for his city and considers himself quite an expert with regard to recommending

restaurants of different types. Given that he has some spare time every now and

then, he wishes to be able to use this time and his knowledge to help tourists to find

good places to eat. The problem is that he does not want this activity to become

a full-time job but rather to be something that he can do in a very simple way and

without strict commitments, by using different communication channels to respond

the recommendation request tasks.



• Example Scenario 3. Carlo Rossi is a doctor and a board member at the CAS

city hospital, which makes organizing his agenda very complicated. For managing

his always full agenda he receives the help of his assistant; who has to coordinate

meetings with other board members or colleagues, schedule appointments for his

patients, among other activities. To facilitate the requesting of appointments, Dr.

Rossi also wishes to be able to directly share his personal agenda with his colleagues,

patients and even family members; in such a way that they can directly see when

there are available slots. Nevertheless, he does not want to share every little detail

of his agenda with everyone; choosing instead which details to share with each group

of people and only granting permission to directly edit his agenda to his assistant.

The scenarios described here can be considered within macro scenarios in the areas of

transportation, tourism, and health care respectively. These are interest areas for the

project that, in turn, are related to scenarios defined in WP9. More in particular, the first

scenario maps with the SmartShare pilot developed mainly in WPs 2, 5 and 6; and the

second correspond to the Ask SmartSociety application that integrates the work of WPs

4, 6, 7 and 8.

The reminder of the deliverable is organized as follows, Section 2 introduces the model

for data and knowledge representation used in the Peer Manager, while the storage and

privacy protection model is presented in Section 3. The mechanisms for privacy-aware

search and ranking of search results are introduced in Section 4. The Section 5 presents

the internal architecture of the peer manager and Section 6 concludes the deliverable.

2 Attribute-based Peer and Task Modeling

The main purpose of this section is to provide an underlying model for representing knowl-

edge and data related to peers participating in collectives and tasks that they can perform

(i.e., a data and knowledge representation model). Such model is provided by the Peer

Manager (WP4) and it is meant to give a “minimum” common ground of specifications

for the representation of data and knowledge across Smart Society applications, favouring

semantic interoperability among them. It should have at least the following properties:

• In line with WP4, it needs to be able to describe peers, as well as tasks and resources

employed to perform them.

• In line with WP1, it needs to account for the foundational notions of hybridity (peers

are of different nature, i.e. humans/machines and collectives) and diversity (peers

have different capabilities, skills and descriptive features).

• To support interoperability, entities defined with the model should be dereference-

able, i.e. they should be associated an identifier (e.g., URI) such that any application



can refer to them. Also, this is required for the interaction with the other compo-

nents of the SmartSociety platform, in particular the provenance (WP2) and the

orchestration (WP6).

• The model should be minimally defined and extended to accommodate for application-

specific requirements. This is actually what we mean by good enough actionable

semantics, i.e. the semantics, which is strictly required for the tasks at hand.

2.1 Ground Knowledge

In the Peer Manager, the representation of information related to peers builds upon de

notion of a semantic schema that follows an entity-centric approach, using the notion of

entity to refer to a “thing” that exists in the real world. Within the peer manger we

formalize this notion of entity and use it, as the basic element representing information

about peers. In this subsection, we briefly present the evolution of the initial data and

knowledge representation model that was initially discussed in deliverables D1.1 and D4.1.

We distinguish between a Knowledge Base (or schema level) containing the “format” to

represent information and an Entity Base (or instance level) that instantiates the schema

into actual information (i.e., data) [1, 2].

A Knowledge Base KB stores the definition of templates for each type of entity used

in the system3. This serve to establish restrictions on the set of attributes that can be

used to describe a given type of entity, where the meaning is further specified by mapping

single elements (i.e., types of entities, the names of attributes and their values) to concepts

from the underlying ontology that is also part of the same knowledge base.

• A concept is “an idea of what something is or how it works.”4 In the area of

knowledge representation, concepts are used to formalize and represent the mean-

ing of words in a language independent manner. Concepts can be mapped to an

underlying ontology that greatly helps hard to manage limitations for the shared

information (for interoperability) and identifying purposes (for purpose binding),

while also providing the basis for more accurate access control methodologies as

introduced in [3, 4].

• An entity type ET provides a template for the creation of entities by establishing a

set of constraints about the metadata (i.e., attributes) those entities of that type can

instantiate. The template for attributes are defined by mean of the so-called attribute

definitions. An attribute definition AD imposes an explicit constraint about the

name and the quantitative or qualitative values of a certain attribute that can be

3Note that this approach is aligned with the Schema.org (http://schema.org/) initiative.4Merriam-Webster (http://www.merriam-webster.com/dictionary/concept).


http://schema.org/

http://www.merriam-webster.com/dictionary/concept


associated to an entity.

An Entity Base (EB) stores concrete information about abstract and physical entities

that exist in the real world and is represented by the following elements.

• An entity (E) is defined as an abstract or physical object, can be of different types

defined at the knowledge level (e.g., person, location, event, etc.) and is described

by attributes (e.g., name, birth date, latitude-longitude, size, duration, etc.), which

can be different for different types of entities. It is defined by mean of an entity type

(ET ) and a non-empty set of attributes describing the characteristics of the entity

({A}).• An Attribute (A) instantiates an attribute definition AD to represent a particular

characteristic of the entity. Some attributes may have multiple values, its values

may be mapped to a meaning in some knowledge base (i.e., semantic values) or can

represent a relation to another entity when the value is a reference to another E

(i.e., relational attribute). It is formally defined by mean of an attribute definition

(AD) and a set {V } of attribute values of the type of the corresponding AD.

2.2 The Peer Manager Core Ontology

2.2.1 Guidelines followed for the development of the ontology

Gruber [5] defines ontology as a formal specification of a shared conceptualization. The

notion of conceptualization refers to an abstract model of how people theorize (the relevant

part of) the world in terms of basic cognitive units called concepts. Explicit specification

means that the abstract model is made explicit, for instance by providing terms and

definitions for the concepts. In other words the terms and the definition of the concept

provide a specification of its meaning in relation with other concepts. The specification is

said to be formal when it is written in a language with formal syntax and formal semantics,

i.e. in a logic-based language. The conceptualization is shared in the sense that it captures

knowledge, which is common to a community of people and therefore represents concretely

the level of agreement reached in that community.

Accordingly, we attach to each concept in the ontology, a set of terms and a definition.

For instance, the concept of “the date on which a person was born” can be associated in

English with the terms “date of birth” and “birthday”. In developing the ontology we also

comply with principles of ontological analysis [6] and apply the DERA methodology [2]

developed in Trento. The latter draws a neat distinction between ontologies of entity

classes, relations and attributes and gives precise principles, borrowed and adapted

from the faceted approach [7], to be followed in order to develop robust, and easy to

extend, ontologies. For instance, it is essential to make explicit the criteria followed to



arrange concepts when appearing at same level of the ontology (siblings) and the semantic

relations between them. We also frequently follow the guidelines provided by ISO for

thesauri construction [8] that provide (among others) concrete suggestions about how to

appropriately select terms to lexicalize the concepts. Examples of pitfalls to avoid include:

• The usage of labels that indicate mixed notions, e.g. UserAndMachine (two entity

classes), ProvideVote (an activity and an attribute name) or PerformMachineNe-

gotiation (an activity and an entity class); such examples are attempts of making

the ontology enumerative, i.e. attempts to list all possible combinations of concepts

(instead of leveraging on the compositional nature of semantics).

• Forgetting to provide definitions for the concepts, thus leaving them ambiguous. For

instance, the term bank may denote a financial institution or a river slope.

• Forgetting to provide explicit semantic relations between concepts. For instance, we

can say that person is-a agent and that person member-of collective.

• Forgetting to discriminate between entity classes, relations and attributes. Such

concepts need to belong to different ontologies. For instance, it would be wrong to

treat price as a utility (an entity), but it should be rather an attribute of a utility.

2.2.2 Requirements

The main things that we need to model in the Peer Manager are:

• Agents: an agent can be defined as being any entity capable to act independently

and to bring changes in the world. It can correspond to a single person, a software

agent or a collective. In turn a collective is a group whose members include any

number of people, software agents or other collectives.

• Users: Users are associated to agents registered in the platform. Users are typically

of three kinds: standard, administrator and guest users.

• Tasks: a task corresponds to any piece of work that is undertaken or attempted

by one or more agents. It typically requires some pre- and post-requisites, such as

specific resources, capabilities and skills. For instance, in the Ride Sharing applica-

tion a ride requires a driver to be available possessing both a vehicle and a driving

license.

• Roles: a role represents the parametric profile of the resources, capabilities and

skills that are required or expected to be owned by an agent to perform or execute a

certain task. For instance, roles that can be played in the Ride Sharing scenario are

drivers, passengers and ride planners. At any moment of time the same agent can

play any of the roles (the first two not at the same time). Notice that, at the current

status of technology, drivers and riders are roles that can only be played by people,



but it is expected that this will change quite soon. On the other hand, while in

principle a person or software agent can play the role of ride planner, in the current

implementation of the Ride Sharing application it is played by a software agent.

• Entities: they refer to any real world object, such as locations (e.g. the origin and

the destination of a ride), organizations (e.g. a transportation company), artifacts

(e.g. vehicles necessary to perform rides, files necessary to store information), or any

resource required and target of activities performed by agents. We should distinguish

objects (e.g. cars) from their attributes (e.g. color and model) given that the latter

are means to describe the former. Entities can be of any kind and their nature is

highly domain dependent.

Accordingly we define the following core ontology specifying concepts (with terms and

definitions in English) and semantic relations between them. In line with the good enough

principle, the ontology is further extended according to specific applications we may need

to serve in the future.

2.2.3 Entity classes, relations and attributes

Here we provide the core ontology of entities.

• Entity :: anything which is perceived or known or inferred to have its own distinct

existence

– [is-a] Agent :: an entity capable to act independently and to bring changes in

the world

∗ [is-a] Individual :: a single agent

· [is-a] Person :: an individual human being

· [is-a] Software agent :: an individual computer program that acts on

behalf of a user or another program

∗ [is-a] Collective :: any set of entities acting collectively as a single agent

· [is-a] Organization :: a collective constituted by individuals with com-

mon goals and formal rules

· [is-a] Facility :: anything providing a particular service or used for a

particular industry

· [member-of] Individual

· [member-of] Collective

– [is-a] Location :: an entity occupying fixed regions of space

– [is-a] Artifact :: a physical entity created by a human

– [is-a] Data store :: a repository of a set of integrated information objects

∗ [is-a] File :: a single block of arbitrary information or resource for storing



information

– [is-a] Mind Product :: a product of the human intellect

∗ [is-a] Document :: a conventionally text-based work that is used to transfer

information

– [is-a] Event :: anything that happens at a given place and time

∗ [is-a] Task :: any piece of work that is undertaken or attempted

• Role :: the specific frame of activities played by an agent that takes part to a specific

event

Relations and attributes are directly defined as part of the entity types they belong

to (see Appendix A). Here we provide only some examples. Here we provide only some

examples of attributes.

• Attribute :: any qualitative, quantitative or descriptive property of an entity

– [is-a] Address :: a place where an entity can be found or communicated with

– [is-a] Gender :: the properties that distinguish organisms on the basis of their

reproductive roles

∗ [value-of] male

∗ [value-of] female

– [is-a] Date of birth :: the date on which a person was born

2.3 Core Entity Types

Following the notation given in D1.1, in this subsection we provide the entity types for

the core semantic schema of the Peer Manager. The resulting hierarchy (as from the core

ontology) of entity types is shown in the following diagram (Figure 1). As we can see, the

entity types that are lower in the hierarchy extend the parent classes and therefore (similar

to object orientation) they will inherit their attribute definitions. More details related to

the concrete attribute definitions for each entity type are reported in Appendix A. Notice

that, in line with the good enough principle, entity types are defined only for those concepts

for which it is worth defining at least one attribute given the applications for which they

are foreseen to be used.

Additionally, in Appendix B we report the outcome of a study on personal data.

Notice that individual human peers are of high relevance in the context of the project.

The study is carried out from the perspective of knowledge representation, taking into

account philosophical points of view as well as standards that are currently being used for

the representation of person attributes. Finally, we need to show the relation between the

data and knowledge representation model presented in this section (grounded on WP1’s

model) and WP2’s model. The Appendix C discusses how WP1 and WP2 models can be



Figure 1: Entity classes hierarchy

aligned, allowing interoperability with other SmartSociety components (in particular the

provenance - WP2).

3 Attribute-based Privacy-enhanced Model

This section extends the model defined in the previous section, by adding privacy regula-

tions and considerations, to propose a privacy-aware storage and sharing model for entities

that we call here the Peer Manager Storage and Privacy Protection Model. The entities

in this model can act as both subjects and objects of different actions and, for this reason,

they can be used to represent either peers or tasks.

To answer its privacy and knowledge management requirements defined during the

first year of the project, the Storage and Privacy Protection Model is mainly based on the

following three core guiding principles:

1. Well-defined information separation between information owned by different subjects.

For guaranteeing that the subjects control their own data, the Peer Manager creates

distributed environments that host the knowledge container of each subject. There-

fore, as the knowledge containers can be physically and logically distributed, the

personal information of a subject is isolated from the personal information of other

subjects.

2. User-centred identity management. The Peer Manager gives to each subject the

control of the flow over personally identifying information. Furthermore, the identity

management system issues pseudonyms and partial identifiers.

3. A deconstruction and re-imagining of information profiling. While the high-level

objective of the Peer Manager’s Profiles is in general the same as the one of tradi-

tional profiles (i.e. an information-holding structure that is maintained and updated



separately from the subject to which it refers), we have focused on turning around

the regular profiling practices by making them transparent and controllable by the

subjects that they refer to.

3.1 Requirements

We define our requirements for a privacy-enhanced model taking into account our previous

work on D4.1 where we discussed basic privacy principles that apply to peer profiling. As

a quick summary of what was explained in that deliverable, the main requirements that

we need to comply in the Smart Society Peer Manager are:

• Legitimacy & informed consent: The collection and processing of personal data

in profiles needs to be legitimate, which usually implies that the data subjects have

given their informed consent.

• Purpose Specification & binding: Personal data used in the context of profiling

must be collected for specified and legitimate purposes and may later only be used

for those purposes.

• Data minimization: Furthermore, the amount of personal data and the extent

to which they are collected and processed in profiles should be minimized, which

implies that the data in profiles should be anonymised or pseudonymised whenever

possible.

• No sensitive data: The collection and processing of so-called special categories of

data in the context of profiling should in principle be prohibited.

• Transparency & data subject rights: Data subjects that are being profiled have

the right to access (i.e. to obtain information about) their personal data as well

as the right to be informed by the data controller about the logic underpinning the

processing of their profile data. Furthermore, data subjects have rights to correction,

deletion and blocking of their data.

• Security: The data controller has to implement proper technical and organizational

security measures for the protection of personal profile data.

During the second year, the previous requirements were extended by more specific

privacy questions that, although considered for the Peer Manager privacy-aware model and

platform described in this deliverable, still largely remain as challenges to be addressed

within Smart Society in the following years. The most important three of these questions

are the following:

• How can privacy interests of “collectives” (consisting of several individuals and/or

machines) be protected? How can collectives be formed in an anonymous manner,

i.e. in a way that it does not relate to any identified or identifiable person?



• In hybrid systems, peer profiles of machines could include personal data of one or

even several data subjects. For instance, in the Care House scenario, sensors capture

data about when and for how long health care professionals and patients have met.

• Are anonymous credentials suitable PETs (privacy-enhancing technologies) for en-

hancing the privacy of passengers and drivers in the Smart Society car ride sharing

pilot? Both drivers and passengers could be pseudonymously registered by the plat-

form but will the use of anonymous credentials in this context be practically feasible

and socially accepted?

These challenges to privacy are also equally important for a privacy-preserving cas

computing platform. There is related work on privacy on sensor data collection, trust and

reputation, and provenance (see e.g., [9, 10, 11]). Furthermore the ethical implications of

data collecting, profiling and processing (in a big data manner) are elaborated with the

previous three questions in the Appendix D.

The rest of this deliverable will refer to these requirements and challenges when refer-

ring to privacy enhancements but some of them (specially the ones arising from questions

raised during this year) will be addressed in future work within the model of the Peer

Manager and its implementation in the SmartSociety platform.

3.2 The Peer Manager Model Privacy-enhancing Structures

For the Peer Manager Storage and Privacy Protection Model, we use the concept of Infor-

mation Peer not in its traditional network management sense but in the more literal sense

of “equally privileged participants in an information exchange”. Following this definition

the different agents (i.e. human or machine-based actors, parties or participating stake-

holders), represented as peer structures, interact under the same set of rules and are able

to become both providers and subscribers of different exchanges or services at different

times.

To address the previously stated requirements and challenges related to personal data

protection, the Peer Manager Model introduces three main structures: the peer, the user,

and the profile structures.

3.2.1 Peers as distributed storage providers.

Peer structures are units of storage under the control of the Peer Manager and of the

subjects that participate in it. The Peer Manager keeps an entity’s data and knowledge

base. Every entity has a Peer Manager and defines the access control policies related to

their data. The default policy is the most restrictive one, i.e., the data is available only



to the entity that owns it. An entity’s data is kept isolated from the rest. Therefore, the

Peer Manager helps to promote the privacy principle of informational self-determination.

When a subject registers to the SmartSociety platform, it is assigned a peer structure

defined as the the tuple P = 〈ID,KB,EB,ME, {U}〉 where:

• ID is a unique identifier and a reference number to a peer;

• KB is the id of the Knowledge Base owned by the peer that will be used to store

all of the concepts and Etypes that belong to the peer;

• EB is the id of the Entity Base owned by the peer that will be used to store all of

the Entities that belong to the peer;

• ME is the id of the Main Entity of the peer and it is stored in EB. This Entity

contains the information belonging to the subject that the peer represents; so in the

case of a human, the main entity is a person entity but it could also be software

process or a collective of peers (how the peer structure also enables hybridity in the

SmartSociety Platform is shown in Section 5); and

• {U} is a non-empty set of user structures, which is defined below.

The peer structure thus allows each subject in the system to have its own dedicated

storages (to which then they can apply their own policies and AC directives) as shown in

Figure 2.

Figure 2: A data storage handled by the Peer Manager. Each subject is assigned its ownpeer storage, while the platform itself offers a shared storage (for Knowledge and Entities)for different interactions.

Figure 2 shows that each Peeri has its own KBi (Knowledge Base) and EBi (Entity

Base) assigned and clearly separated from the other peers and the platform. The design

of the Peer Manager infrastructure also states that only the subject in control of Peer

structure has access to it by default and allows for each of these Peers to be stored

either in the same server or in different machines altogether. Through this, the platform

guarantees that each subject will be always in control of the information stored in his/her

assigned peer and that nobody (not even the platform holders) would be able to access

this information unless given access by the same subject.



Figure 3: User structures are used instead of the Main Entity when it acts as a subjectand profile structures are used for when the Main Entity is read as an object.

3.2.2 Users structures as subject pseudonyms.

When interacting with other peers registered in the platform, entities have the option

to control the amount of personal data they reveal. User structures (corresponding to

pseudonyms that a subject can act under) are introduced to enhance the privacy of all the

subjects that participate in actions/interactions in the Smart Society platform. Entities

are able to define N user structures (corresponding to N different pseudonyms) defined as

tuples U = 〈UN,AUTH,P,MPD, {PD}〉, where:

• UN is an alphanumeric string used as the unique identifier to the user structure.

This string is a pseudonym for the entity that controls the peer;

• AUTH is an authentication token that is issued by the platform as a proof of peer’s

identity;

• P is the id of the peer to which a user structure corresponds.

• MPD is the id of the Main profile definition structure that is applied to the peer’s

ME. It is used to obfuscate (by pseudonymization or anonymization) the link be-

tween user structure and the peer that owns it. The resulting Entity Profile is

associated to the user structure and (depending on its configuration) may provide

none to full identification of the entity that controls it;

• {PD} a possibly empty set of profile definitions that subjects create for their entities

(e.g. their events, physical and logical objects, and other partial identities) that are

linked to the current user structure.

The left side of Figure 3 shows an user structure being used instead of the ME as the

subject of the action “posted a comment”. As this example illustrates, the user structure

corresponds to a pseudonym for the peer. For achieving a high degree of privacy/unlink-

ability, different user structures (i.e. different transaction pseudonyms) could be used for

different actions. More in general, Figure 3 shows how user structures and profiles enhance

privacy by providing indirect and partial access to the information from the Peer and its

Main Entity, which may contain identifying information about the subject and additional

personal data.



3.2.3 Profiles as object indirections.

Instead of directly allowing access to the information contained in the peer’s entities,

Profile structures are created to reply to queries that are sent to the peer (normally only

revealing partial or obfuscated information about these entities). The right side of Figure 3

shows an example where, upon receiving a read query, the peer allows the requester to

access the Profile named “Profile2”, which contains partial and obfuscated information

from ME but not ME, which may contain personal data that the subject may not want

to disclose. Profile structures, when they refer to ME, may represent partial identities of

the subject controlling the Peer.

The profile structure definition PD is used to define the subset of information to

be included in the profile from the ME. A profile definition is defined as the tuple

PD = 〈ID, PE, {PP}, {GP}, {NR}〉 where:

• ID is a numeric unique identifier. It is a reference to the PD;

• PE is the id of the Profiled Entity, the entity to which this profile refers to;

• {PP} is a non-empty set that specifies the different parameters that feed the algo-

rithms that are to be applied to the profiled entity to obtain the profile, both this

set of parameters and the algorithms are entity type-dependent (although future

versions may consider its generalization);

• {GP} is a possibly empty set that contains the id of all Generated Profiles obtained

from the current definition, and;

• {NR} represents the Negotiation Requirements that need to be complied by the

parties wanting to have access to the information that this profile definition will

generate.

Applying a profile definition to the Entity it refers to materializes the information into

an Entity Profile structure. An Entity Profile is defined as the tuple EP = 〈ID,U, S, {A},{AR}〉 where:

• ID is a numeric unique identifier

• U is the id of the user structure that was the source of this profile

• {A} is a set of attributes defined as before but the specific attribute definitions and

values may be different from the ones in the entity.

• {AR} is the possibly empty set of Agreed Requirements set between the original

controller of the information contained in this profile and the owner of the entity

base where it is now stored, this property can be checked to make sure that the

terms or agreements are not breached.

The profile definition structure (i.e., the filter to apply to the original information

before sharing it) is stored at the source peer’s storage while the materialized Entity



Figure 4: An example containing Entities, simplified profile definitions and profile mate-rializations for sharing an Event Entity.

Profile structure (containing the shared partial and/or obfuscated information) is stored

at the destination peer’s storage, as shown in the example illustrated in Figure 4.

Recalling the example scenarios from the introduction, the left part of Figure 4 shows

an Event (family lunch) that belongs to a doctor’s Peer. The doctor has created two

profile definition structures, which are presented here in a simplified manner, to define

how this event is shared to his assistant and patients. The rest of the figure shows the peer

structures that belong to the subjects with the materialized profiles created from applying

the restrictions from the profile definition. These materializations include examples of

omitted pieces of information (e.g. the ‘food’ attribute is not shared in neither profile)

and partial/obfuscated information (e.g. the time of the event becomes ‘Midday’).

The use of the information contained in the materialized Profiles is restricted by the

Agreed Requirement attribute, which is an agreed upon privacy policy based on ppl [12].

As shown in Figure 5, policy enforcement at the platform-level guarantees that the shared

information is only used for the stated purposes, which are specified in the attribute

level. For example, if profiles are used to share contact information, e.g., the doctor gives

her telephone number to his/her assistant, the doctor may restrict its use to “call over

phone only”. Therefore, any other operation over the data, such as reading or copying

the telephone number is not allowed, i.e., the assistant may call the doctor but the actual

phone number is not revealed to the assistant.

Figure 5: Even outside of the information controller’s storage, Agreed Requirements applyto the materialized Entity Profile to restrict the possible use that the information storedin them is given.

It is important to note that the model in this section does not yet specify how the Ne-



gotiation Requirements (NR) and Agreed Requirements (AR) from the Profile Definition

and Entity Profile structures will be represented. This will be done in the next iteration

of this deliverable (D4.3) by using the ppl policy language introduced last year in D4.1.

A small ppl policy example is given in Appendix refappendix:ppl-example to show inter-

ested readers how a policy may look like. Furthermore, the definition of Collectives in this

model, their privacy considerations and an exploration of their uses and roles within the

SmartSociety Platform will also be better developed in future deliverables.

4 Privacy-aware Search and Ranking

The main objective of the search mechanisms in the Peer Manager (PM) is to find and rank

peers (i.e., individuals and/or collectives of people and machines) that are most capable,

interested and/or efficient in solving a given task. The result of such search need to be

based on the attributes of the peers and the characteristics that may allow them to solve

the task. Thus, having full access to all the attributes from all peers stored in peer profiles

would make the search mechanism produce better results. However, such unlimited access

may include personal or sensitive information, specially in the case of peers that present

people. The PM therefore has to define a search method in such a way that the privacy

of peers is preserved.

Having defined the core data model (Section 2) and the privacy model (Section 3), we

introduce a search mechanism that uses both of these models and it is implemented in the

Peer Manager. In our entity-centric approach, a search request can specify (i) constraints

on search results and optionally (ii) an ideal search result. We first discuss the specification

of search constraints, which define what should be included in the search result, through

the notion of attribute-based search. Next, we show how an ideal search result is used to

define ranking order by specifying what results are preferred in relation to others. The

points mentioned above are focused mainly on showing how an attribute-based search and

ranking can exploit the semantic schema to enhance search capabilities. We will then

present our approach for a privacy-aware search by integrating these notions within the

PM’s storage and privacy protection model.

4.1 Attribute-based Search: Defining Search Constraints

Consider the example scenario 1 from Section 1 (i.e., ride-sharing example). For recruiting

commuters to share a ride with Maria, the application coordinating rides needs to find

a group of peers (individuals and/or collectives) with profile attributes that implicitly or

explicitly indicate an interest in travelling between Milan and Trento. The diversity in the



way in which different peers are described in their profiles challenges the PM to support

the specification of search constraints that can be matched with the attributes from the

profiles of relevant peers even if they are not all described with the exact same words. As

it has been presented in Section 2, the Peer Manager uses the notion of entity to represent

information about peers. Thus, in the remainder of this section we refer to searching

entities as the core mechanism to be used for implementing search in the PM.

In our data model, the characteristics and relations of entities are described not only

by using words, but those words are also extended with concepts from the underlying

knowledge base (see Subsection 2.1). Entity types and entity attributes/relations are rep-

resented as concepts. For string attributes, words are preserved to allow a pure syntactic

search on attribute values and also extended with concepts to allow semantic search. As a

consequence, the entity search approach we implement is capable of semantically matching

a search query to:

• Entity types. For example, based on the etype hierarchy introduced in subsection

2.3, entities of types Person and Software Agent will be considered as relevant results

for a query that is trying to find entities describing Individual agents.

• Attributes/Relations. For example, an entity with an attribute Location set to

Trento will be considered a relevant result for a query that is trying to find entities

with attribute Place equal to Trento.

• Attributes/Relations Values. For example, a person with background in artificial

intelligence will also be considered as a relevant result to a query that is trying to

find people with a computer science background (independently of whether his bio

attribute contains words computer science or not).

In short, attribute-based search is provided by modifying/extending the notion of

semantic search, in particular we use concept search [13], to support entity search in

semantic Entity Bases (EBs). The logic it follows is comparable to Lucene5 and its novelty

is given by the fact that concept search is used to specify the constraints on search results.

Concept search leverages on the core semantic data model of the peer manager that is

stored in Knowledge Bases (KBs) to allow specifying search constraints on entity types,

entity attributes and entity relations.

In order to support the specification of arbitrary complex search constraints, the fol-

lowing elements are defined:

• QueryClause: contains the root node of the input query and allows specifying the

search scope, for example, by providing the entity type of the desired entities.

• QueryNode: defines the list of the atomic queries (see the next item) and query

5http://lucene.apache.org/core/index.html


http://lucene.apache.org/core/index.html


(a) Schematic representation (b) Example

Figure 6: Complex search query

nodes joined with a “AND” or “OR” operator. It allows composing atomic queries

into complex query specifications.

• QueryAttribute: represents an atomic clause in the query, which defines a single

constraint in the desired entities in the form “attribute 〈operator〉 value”, where

the attribute can be specified by providing its name (e.g., age, location, etc.), its

concept or both; the operator is the relation between the attribute and the value

(e.g., EQUAL, MORE, LESS, etc.); and the value is given by a data type and the

desired value.

Figure 6 shows an schematic representation of search constraints (in 6a) and an example

of how a concrete specification of constraints may looks like (in 6b). As it can be seen

a complex query can be visually understood as a tree-like structure with QueryNodes as

internal nodes and QueryAttributes as leafs.

Some relevant features that are provided by using the approach described in this sub-

section are:

1. Semantic search on entity types, attributes and relations (based in the terminology

of the PM’s core ontology) allows finding relevant peers even when they are described

using different terminology in their profiles.

2. Complex search query specification is supported, allowing arbitrary description of

relevant peers (i.e., complex search constraints).

3. The meaning of words in a query can be explicitly selected.

4. We leverage on Concept Search, which allows us to provide a wide range of (semantic)



operations on attributes.

5. Is scalable in terms of future (possible) extensions to the PM’s core ontology.

4.2 Attribute-based Ranking: Defining Order or Distance Function

Ranking of results is a popular and universal approach to ordering (or structuring) oth-

erwise disorganized set of search results. The results of the query are usually ordered by

employing some notion of distance between a given result and the ideal search result. The

goal of computing such distance is to measure the relevance of the result for the corre-

sponding query. This notion of distance that might be intuitive for humans is harder to

encode in such a way that can be processed by computers. For this reason, different types

of functions has to be defined for different types of values.

Let us first introduce some query examples with different types of values:

• Q1: “Find people living in Milan near the city center”

• Q2: “Find people with a computer science background”

• Q3: “Find people with a computer science background living in Milan near the city

center”

• Q4: “Find people living in Milan ordered by names”

• Q5: “Find people living in Milan ordered by age”

From these examples, it can be seen that Q1 imposes a single constraint that a person

of interest must be living within borders of Milan. The ideal search result for this query

would be a person leaving exactly in the center of the city. The result for this query is a

list of people living in Milan ordered in the increasing order of the distance between the

locations where they live and the city center.

Notice that geographical distance is just an example of a distance function used for

spatial entity attributes. For textual entity attributes and keyword based search query,

Vector Space Model [14] can be used instead. Distance in this case can be defined as a

cosine similarity between query and document vectors with terms weighted according to

some sort of term frequency-inverse document frequency (tf-idf) model [15]. In the case of

Q2 (mentioned in the previous subsection), those results will be considered ‘closer’ to the

ideal search result which will have more words computer and science appearing in their

bio attribute.

As it was previously discussed, our model represents entity types, attributes and rela-

tions as concepts. With regard to ranking, this also means that results of the query (in

addition to those exactly matching) can also be semantically similar to the ideal search

result. In this case, some notion of semantic similarity can be used to define distance. An

example of such distance function is a distance between concepts in the knowledge graph



(stored in the KBs). Assuming that concept ‘artificial intelligence’ is a direct successor of

concept ‘computer science’ and the weight for this relation is one, the distance between

those concepts will also be one.

Multiple entity attributes can be used for ranking results in a single query. For instance,

Q1 and Q2 can be combined in Q3, where the final ranking is computed by aggregating

all the independent rankings taking into account their weights. Then, if a query specifies

only constraints on results and does not specify the ideal search result, a natural order of

results can be used. This is true provided that the types of values included in the search

constraints can be associated with some natural order function. For instance Q4 and Q5

will return results ordered alphabetically and numerically.

4.3 Privacy-aware Search

After presenting basic mechanisms for searching and ranking that are used in the Peer

Manager, in this subsection we discuss in more details how the previously defined privacy

model (Section 3) integrates with search. The Figure 7 shows a three-layered search

schema that is defined and will be implemented in the peer manager in order to enable a

privacy-aware search service.

Query Results

Filtering Profiles

Search Result Integration

Purpose Specification

Search Computation

Figure 7: Peer Manager Search Schema

In most search systems the items to be included in the result set only depend on the

search query. One exception is the case of personalized search where the result set depends

also of the user for whom the search is personalized. In a similar way, the peer manager

takes into account the privacy requirements previously discussed in 3.1 and identifies

the need to consider WHO is issuing the search request and for WHAT PURPOSE the

returned information will be used when computing the search result. To account for this,

a Query structure is defined in the peer manager as the tuple Q = 〈UI , PR,QC, IR,UT 〉,



where:

• UI represents the user issuing the search request

• PR represents the context/purpose for which the retrieved information will be used

• QC is the query clause specifying the constrains on the search results

• IR represents the ideal search result that is used for ranking

• UT represents the possibly null target user. A target user is specified to explicitly

specify the scope of the search (i.e., to ask another user, to search globally, etc.).

Having defined the elements from the query, let us now discuss in more details the

search schema from Figure 7. A search layer is able to understand the logic of the search

service. On receiving a search request (i.e, query), parses its different elements and interact

with other layers to compute and build an ordered list of results. It represents a service

layer offering a personalized service based on privacy preferences of information owners.

The privacy layer containing information about users, what data store they can search

and for what purposes, is used to solve the data indirections. The data stores that can

be searched (by a given user and for a given purpose) are identified at this level. It also

allows filtering the profiles (from searchable data stores) that can not be reveled, again

in accordance with the corresponding privacy preferences of its owner. The data layer

containing the data storages (i.e., the different KBs and EBs under the control of the

platform and of users) to be searched, allows finding semantically relevant information.

Although these layers can be conceptually separated in different modules having dif-

ferent functions (as in Figure 7), it is important to note that when used together in the

peer manager they actually work one embedded into the other. As a result, within this

schema, search is performed in a privacy-friendly manner on Entity Profiles instead of the

entities. This allows performing matching only on partial or obfuscated information (i.e.,

data minimization principle) about the peer and revealing also minimal information as

part of the search result. Notice that the decision on which profiles can be included in the

search and how they can be used is regulated by their corresponding privacy policies (i.e.,

based on the Agreed Requirements attribute from the profile).

Finally, the approach presented in this section is designed upon a privacy-preserving

framework offering a number features that can be summarized as follows:

1. The peer performing the search acts indirectly through its user, while the peer as

the object being searched is also accessed indirectly through its profile. This is

particularly important to help achieving the data minimization requirement.

2. Differently from other approaches we do not focus on dataset anonymization, our

focus is on the user as an owner of its information and on enforcing their privacy

preferences during search (i.e,. informed consent).



3. Privacy is embedded into de design of the search mechanism in different forms.

First, we do not need to search the entire repository, we constraint the search to

data storages where the search issuer is authorized to search. Second, we constraint

to return only profiles that can be revealed for a given purpose.

4. Only authorized users and only for the authorized purposes will be enabled to find

profiles that match their query constraints. Informed consent and purpose binding

are two important requirements that this feature can help achieving.

5 The Peer Manager Architecture

The Peer Manager (PM) can be viewed as the main storage of personal information in the

SmartSociety Platform. As such, the PM has the following main objectives:

1. Store metadata and semantics by implementing the Data and Knowledge Represen-

tation Model from Section 2;

2. Protect privacy through the use of the Storage and Privacy Protection model from

Section 3;

3. Provide matching and ranking between peers and tasks, as defined in Section 4; and

4. Support hybridity by allowing the defined peers to represent persons, software agents

or collectives as shown below.

The rest of the section will explain the architectural decisions made when designing

the Peer Manager and will also present the first implementation and integration results

within the SmartSociety Platform.

5.1 Peer Manager Internal Architecture

The different internal components of the Peer Manager, along with their interactions are

shown in Figure 8. More specifically, these components are:

• The Peer Base shown at the bottom is the core of the Peer Manager where all the

represented knowledge, information and structures are stored and managed.

• The Peer Manager Complements shown towards the top as red dotted boxes, rep-

resent additional algorithms or functionalities that work directly on the information

of the Peer Base (and as such they run on the same server) and were developed in

collaboration with other project partners. Examples of possible PM Complements

include:

– The Peer Profiler, used to bootstrap peer information from other existing plat-

forms (e.g., social networks);



Figure 8: Full internal architecture of the Peer Manager.

– The Privacy component implementing the privacy policy language that encodes

the requirements to be enforced platform-wide (mentioned in Section 3);

• The Peer Base Web APIs shown between the Peer Base and the Peer Manager

Complements, is provided by WP4 to allow low level access to the functionalities

from the Peer Base for PM Complement developers.

• The Peer Manager Web APIs shown at the very top, is provided by WP4 to allow

high-level access to all the functionalities from the Peer Base and the PM Comple-

ments.

This particular architecture was chosen to make a clear separation between the Smart-

Society components that are meant to interact directly/frequently with the information in

the Peer Base (e.g., Privacy, Peer Profiler) and those components that only need high level

interactions or results from the Peer Manager (e.g. Orchestration, Programming Frame-

work). This separation enables better performance for those components that operate

from within the Peer Manager (which implies in the same server), while still having good



flexibility in providing services to components that contact the Peer Manager through a

network connection.

5.2 The Peer Base Structures and Hybridity Support

Of the previously explained components, here we focus on the Peer Base to further clarify

its subcomponents. The Peer Base is the responsible for peer’s data storage in the Peer

Manager and, as shown at the bottom of Figure 8, it is internally separated in:

• A Platform-Wide Knowledge Base (KBPW ) that will store the core entity types and

ontology, and can be also used by other components of the SmartSociety platform

(i.e., not only by the Peer Manager). This can potentially include SmartSociety gen-

eral entity types (i.e., agent, person, software agent, collective, task, role, resource,

location, event, etc) and allow all SmartSociety components to interoperate.

• A Platform-Wide Entity Base (EBPW ) that will store entity instances of general

interests as well as public profiles of peers (i.e., information that each peer decides

to publish in the platform about themselves).

• A Knowledge Base (KBi) and an Entity Base (EBi) for each peer, which will store

the peers information. The peer maintains control over its data space and defines the

privacy policies that apply to the data stored in it. The peer’s KB is bootstrapped

with the content of the platform-wide’s KB, which then can be extended/specialized

by the peer. The peer’s EB stores entity instances that are relevant to the peer (i.e.,

peers personal information, its resources, locations, roles, tasks, etc.).

• The Peer structures and User structures are also stored and managed within the

Peer Base.

This storage separation for each of the peers and the platform is one of the Privacy-

by-design decisions made by the Peer Manager in accordance to the theory and model

defined in Section 3. It is also important to notice that the Knowledge Base component

described in the deliverables from the first year of the project, has now been integrated

inside the Peer Manager.

To help understand all these structures and their relations, Figure 9 gives a quick look

at all the data structures that the Peer Base manages. As shown in Figure 9, each Peer

structure includes one Knowledge Base and one Entity Base6 for the peer, where the Main

Entity is one specific entity known to the peer (i.e., contained in EBi) that is used to store

all the information about (and often identifying) the main subject that is represented in

the SmartSociety Platform by that Peer structure. In case of this subject being a human,

6For a full explanation of the structures inside a Knowledge Base and Entity Base please refer toSection 2 and last year’s D4.1.



Peer i

EBi KBi

Mei (Main En+ty)

Pr1

Pr2

Prm

U1

Un …

…

where MEi ∈ PEBi

Collective Entity SWAgent Entity Person Entity

a ME can be either

a ME has M profiles

Profiles Users

a peer has 1 ME

a peer has N users

Profiles are read from

the outside world to give

access to the Peer’s information

Users interact with the outside

world in name of the

Peer Et1 Etn E1 Em … …

Etypes Entities

a peer has n Etypes

a peer has m Entities

Figure 9: A quick explanation of the Peer Manager structures. The arity and relation ofall the structures are shown.

then the main entity is a person entity but the Main Entity could represent a software

process or a collective of peers. The Figure 9 also shows Multiple Users that are used

by the Peer as pseudonyms, meaning that one of these Users7 is revealed as the subject

participating in a given interaction instead of revealing the actual Peer; and Multiple

Profiles that are used to reveal partial and obfuscated information (instead of revealing it

all) about the Peer’s entities.

It is also important to note that Figure 9 also shows how the Peer Manager supports

hybridity within the SmartSociety Platform. Namely by showing that the Main Entity

of the Peer (shown towards the right side of the figure) can be either of the type Person

(for human users), of the type SWAgent (for Software Agents providing services) or of the

type Collective (for a group of peers acting as a unit). Furthermore this choice does not

impact any of the other structures of the peer or their behaviour, making (in theory) the

true identity of subject behind a peer transparent to the platform.

5.3 The Peer Manager as Part of the SmartSociety Platform

As shown in Figure 10, through the use of the Peer Manager Web APIs, the services

provided by the Peer Manager can be invoked directly from a certified client application

or internally by other components of the Smart Society Platform.

The left part of Figure 10 shows two end-user clients directly interacting with the Peer

Manager (through the PM Web API). The first example (at the top left) uses a web-based

client to register new users to the SmartSociety Platform, while the second example (at

the bottom left part) shows a mobile device-based control dashboard where the person

controlling the peer may choose to modify its privacy settings or check different types of

information related to its participation in the platform.

7For a full explanation on how Users and Profiles protect the privacy of the Peer’s Main Entity pleaserefer to Section 4



Figure 10: Example of Connection of the Peer Manager to external clients and otherSmartSociety Platform components.

On the other hand, the right part of Figure 10 shows an incoming call (to the same

PM Web API) with a Peer Search query that gets answered with a list of Peers complying

with the conditions of the search request. This kind of interactions can be used by other

internal components from the SmartSociety Platform (e.g. Orchestration) to match a task

(expressed as a Peer Search query) with a set of Peers (expressed as the list of Peers that

complies with the original query).

More details about how the Peer Manager is integrated into the SmartSociety Platform

and more detailed examples may be found in the deliverable D8.2 - Platform Prototype:

Early Results and System Design.

5.4 Second Year Peer Manager Integrated Proof of Concept

A Proof of concept for the Peer Manager has started development and an integrated demo

(with similar efforts from other work packages) has been produced for the end of the second

year. While the functionalities and specific calls that the Peer Manager part contributes

to this integrated proof of concept can be found at the Appendix F, for a more global view

and operation examples please refer to the deliverable D8.2.

Future development plans includes better integration with the software developed by

other work packages, implementation of the privacy policies, along with implementation

of revisions/improvements based on feedback at all levels.

While the current code of the PM Web API has not yet been released, we aim to

fully release more complete versions of the Peer Manager Web API as open source. It is

important to stress, however, that there are currently no plans for releasing the actual

back-end code for the Peer Manager nor the Knowledge/Entity Base (as they are heavily

based on knowledge and work that pre-dates the start of the Smart Society project).



6 Conclusion and Final Remarks

This deliverable introduces the concept of a privacy-enhanced SmartSociety Peer Manager,

which is a fundamental building block for the implementation of a privacy-preserving cas

computing platform. The Peer Manager allows people and other actors, such as sensors

and actuators, to store their information in a secure and preserving framework. The design

and development of the Peer Manager followed three core guiding principles for enforcing

legal privacy principles including the principles of data minimisation, purpose binding,

transparency and user control.

1. Separation of information among peers.

2. A user-centered identity management.

3. A novel approach to peer profiling.

The representation of the information stored by the Peer Manager follows a semantic

schema that defines an attribute-based representation of a peer’s characteristics. The Peer

Manager allows people (i.e. users) to define profiles that contain and reveal only partial

or obfuscated information that are used for replying to information requests and is thus

enforcing data minimisation. In addition, during year three we plan to specify and limit

the purposes and use of personal data by using a ppl privacy policy.

This deliverable presented a search schema allowing the Peer Manager to provide a

privacy-preserving search service. This search schema includes the mechanisms used for:

(i) the specification of search constraints that can be matched with the attributes from

the profiles of relevant peers overcoming the diversity in the terminology used for their

representation; and (ii) the definition of distance functions for different types of values

that can be used to rank results (i.e., peers matching with the search constraints) based

on their relevance with respect to an ideal search result.

The privacy-preserving part of the search service is provided by integrating the search

and ranking mechanisms with the Peer Managers privacy-aware storage and sharing model.

The resulting search schema, helps addressing the challenge of binding purpose to the

management of peers information by allowing only authorized users and only for the

authorized purposes to find profiles that match their query constraints. Privacy is then

embedded into the design of the search mechanism in two different ways: first, the search

does not operate on the entire data repository but only on the ones in which the search

issuer is authorized; and second, the search results are constrained to include only profiles

that can be revealed for a given purpose.

Regarding the targeted challenges related with information profiling (such as the lack

of information and feedback about how profile data is collected and traded), the Peer



Manager proposes to address them by giving transparency and control of this process

to the actual subject that the profile refers to. Hence, subjects can create their own

profiles with the minimal amount of information needed and share this information with

the promise that their requirements will be enforced by the platform and that the shared

data will not be misused or traded against their will. It is also worth noting that this

approach introduces potential new issues such as:

1. Management complexity for users, as giving full control of the information could be-

come overwhelming to it owners (specially at the scale in which personal information

is produced and managed in current platforms). For this reason, it is key for the

future adoption and practicability of this approach to present itself as an extension

of existing identity management systems. While some people may not be interested

in fine-grained privacy settings, we plan to provide the possibility to individuals to

review and change their privacy settings in a usable way.

2. Lack of a concrete business model, many companies and platforms that base their

revenue on the harvesting, processing and reselling customer information may ini-

tially be reluctant to give back to their customers more control over their information.

There are however, other organizations (e.g. public utilities, health organizations)

that value much highly the trust that their customers have in them. Moreover, this

higher-degree of customer trust and sense of being in control may also make setting

partial limits and transparency settings beneficial to some of the applications that

do use this information as source of revenue. There is already some literature on the

subject but this will be studied more in depth in future deliverables.

The close attention we pay to privacy and social values for profiles within Smart Society

does not mean that all difficulties are circumvented - there are a host of future challenges

too. We have to be continually vigilant over whether autonomy and self-determination

are indeed preserved by the envisaged technical measures implemented to protect profiles

within Smart Society. For example, despite having the tools to control circulation of their

data, a participant may still feel compelled to disclose an item to the system if refusing to

do so leaves them materially disadvantaged. This means that we have to keep sight of the

wider governance of Smart Society at the same time as we focus at specific technical means

that preserve privacy locally. Furthermore, there are still technical challenges to be tackled

when providing a high-granularity privacy friendly Platform that operates within human

user acceptable responses times while also providing other resource intensive functionalities

like provenance and search.



References

[1] V. Maltese, F. Giunchiglia, and B. Dutta, “Domains and context: first steps

towards managing diversity in knowledge,” Web Semantics: Science, Services

and Agents on the World Wide Web, vol. 12, no. 0, 2012. [Online]. Available:

http://www.websemanticsjournal.org/index.php/ps/article/view/229

[2] F. Giunchiglia, B. Dutta, and V. Maltese, “From knowledge organization to

knowledge representation,” in ISKO UK Conference, 2013. [Online]. Available:

http://www.iskouk.org/conf2013/papers/GiunchigliaPaper.pdf

[3] R. Chenu-Abente, I. Zaihrayeu, and F. Giunchiglia, “A semantic-enabled engine

for mobile social networks,” in The Semantic Web: ESWC 2013 Satellite Events,

ser. Lecture Notes in Computer Science, P. Cimiano, M. Fernandez, V. Lopez,

S. Schlobach, and J. Volker, Eds. Springer Berlin Heidelberg, 2013, vol. 7955, pp.

298–299. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-41242-4 50

[4] F. Giunchiglia, B. Crispo, and R. Zhang, “Access control via lightweight ontologies,”

in Semantic Computing (ICSC), 2011 Fifth IEEE International Conference on, Sept

2011, pp. 352–355.

[5] T. R. Gruber, “A translation approach to portable ontology specifications,”

Knowledge Acquisition, vol. 5, no. 2, pp. 199 – 220, 1993. [Online]. Available:

http://www.sciencedirect.com/science/article/pii/S1042814383710083

[6] N. Guarino and C. Welty, “Evaluating ontological decisions with ontoclean,”

Commun. ACM, vol. 45, no. 2, pp. 61–65, Feb. 2002. [Online]. Available:

http://doi.acm.org/10.1145/503124.503150

[7] S. R. Ranganathan, “Prolegomena to library classification,” The Five Laws of Library

Science, 1967.

[8] I. ISO, “25964-1: 2011,” Information and documentation - Thesauri and interoper-

ability with other vocabularies. Part, vol. 1.

[9] D. Christin, C. Roßkopf, M. Hollick, L. A. Martucci, and S. S. Kanhere,

“Incognisense: An anonymity-preserving reputation framework for participatory

sensing applications,” Pervasive and Mobile Computing, vol. 9, no. 3, pp. 353–371,

2013. [Online]. Available: http://dx.doi.org/10.1016/j.pmcj.2013.01.003


http://www.websemanticsjournal.org/index.php/ps/article/view/229

http://www.iskouk.org/conf2013/papers/GiunchigliaPaper.pdf

http://dx.doi.org/10.1007/978-3-642-41242-4_50

http://www.sciencedirect.com/science/article/pii/S1042814383710083

http://doi.acm.org/10.1145/503124.503150

http://dx.doi.org/10.1016/j.pmcj.2013.01.003


[10] L. A. Martucci, S. Ries, and M. Muhlhauser, “Sybil-Free Pseudonyms, Privacy and

Trust: Identity Management in the Internet of Services,” Journal of Information

Processing, vol. 19, pp. 317–331, Jul 2011.

[11] S. B. Davidson, S. Khanna, S. Roy, J. Stoyanovich, V. Tannen, and Y. Chen, “On

provenance and privacy,” in Proc. of the 14th Int. Conf. on Database Theory - ICDT,

2011, pp. 3–10. [Online]. Available: http://doi.acm.org/10.1145/1938551.1938554

[12] S. Trabelsi, G. Neven, and D. Raggett, Eds., PrimeLife Public Deliverable D5.3.4 –

Report on design and implementation, 20 May 2011.

[13] F. Giunchiglia, U. Kharkevich, and I. Zaihrayeu, “Concept search,” in The Semantic

Web: Research and Applications, ser. Lecture Notes in Computer Science, L. Aroyo,

P. Traverso, F. Ciravegna, P. Cimiano, T. Heath, E. Hyvonen, R. Mizoguchi, E. Oren,

M. Sabou, and E. Simperl, Eds. Springer Berlin Heidelberg, 2009, vol. 5554, pp.

429–444. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02121-3 33

[14] G. Salton, A. Wong, and C. S. Yang, “A vector space model for automatic

indexing,” Commun. ACM, vol. 18, no. 11, pp. 613–620, 1975. [Online]. Available:

http://doi.acm.org/10.1145/361219.361220

[15] G. Salton and M. J. McGill, Introduction to Modern Information Retrieval. New

York, NY, USA: McGraw-Hill, Inc., 1986.

[16] J. Kang, “Information privacy in cyberspace transactions,” Stanford Law Review, pp.

1193–1294, 1998.

[17] S. Perreault, “vcard format specification,” 2011.

[18] E. Goodman, “Design and ethics in the era of big data,” interactions, vol. 21, no. 3,

pp. 22–24, May 2014. [Online]. Available: http://doi.acm.org/10.1145/2598902

[19] H. Nissenbaum, “Privacy as contextual integrity,” Wash. L. Rev., vol. 79, p. 119,

2004.

[20] T. Monahan, “Surveillance and inequality,” Surveillance & Society, vol. 5, no. 3, 2002.

[21] S. van der Hof, , and C. Prins, “Personalisation and its influence on

identities, behaviour and social values,” M. Hildebrandt and S. Gutwirth,

Eds. New York: Springer, 2008, ch. 6, pp. 111–127. [Online]. Available:

http://opac.inria.fr/record=b1126046


http://doi.acm.org/10.1145/1938551.1938554

http://dx.doi.org/10.1007/978-3-642-02121-3_33

http://doi.acm.org/10.1145/361219.361220

http://doi.acm.org/10.1145/2598902

http://opac.inria.fr/record=b1126046


[22] Council of Europe, “Recommendation cm/rec(2010)13 of the committee of ministers

to member states on the protection of individuals with regard to automatic processing

of personal data in the context of profiling,” Available from https://wcd.coe.int/

ViewDoc.jsp?id=1710949, 11 2010.

[23] M. Kosinski, D. Stillwell, and T. Graepel, “Private traits and attributes are pre-

dictable from digital records of human behavior,” Proceedings of the National

Academy of Sciences, vol. 110, no. 15, pp. 5802–5805, Mar. 2013.


https://wcd.coe.int/ViewDoc.jsp?id=1710949

https://wcd.coe.int/ViewDoc.jsp?id=1710949


A The Peer Manager Entity Types

In this appendix we present a mode detailed definition for each entity type including

concrete attribute specifications.

A.1 Entity

ID 100 EC Entity PT -

Description Anything which is perceived or known or inferred to have its owndistinct existence (living or nonliving). An entity is any object soimportant to be denoted with a proper name.

Attributes

ID Name Data Type Description

1000000 Name NLString[] The name of the entity, e.g., “Rome”.

1000001 Class Concept The class of the entity, e.g. “city”.

1000002 Description SString[] The entity description, e.g. “A sunnyplace in Italy”.

1000003 Part (of) 〈Entity〉 It connects the part to the whole, e.g.locations to their administrative divi-sion.

1000010 Start Moment The moment in time an entity started toexist (e.g. the date of birth of a Person).

1000011 End Moment The moment in time an entity ceased toexist (e.g. the date of death of a Per-son).

1000012 Duration Duration The duration of existence of an entity(e.g. the life length of a Person)

A.2 Agent

ID 102 EC Agent PT Physical Entity

Description An entity capable to act independently and to bring changes in theworld

Attributes


1020000 Skill Concept[] Any ability possessed by the agent, typ-ically acquired by trainning

1020001 Activity Concept[] The actions that the agent performs



A.3 Person

ID 103 EC Person PT Agent

Description A person is an individual human being

Attributes


1030001 Gender Concept The sex of the person (male, female)

1030002 Date ofbirth

Moment The date on which the person was born

1030003 Place ofbirth

〈Location〉 The place where the person was born

1030004 Date ofdeath

Moment The date on which the person died

1030005 Place ofdeath

〈Location〉 The place where the person died

1030006 Language Concept[] The language the person speaks and/orunderstands

1000010 Hometown 〈Location〉 The town where the person grew up

1000011 Home 〈Facility〉 Where the person currently lives in

1000012 Nationality Concept[ ] The country the person is citizen of

A.4 Software agent

ID 104 EC Softwareagent

PT Agent

Description A software agent is any individual computer program that acts onbehalf of a user or another program

Attributes


1040000 Producer 〈Agent〉[ ] The entity engaged in financing andmanufacturing the software

A.5 Collective

ID 105 EC Collective PT Agent

Description A collective is any set of entities acting collectively as a single agent

Attributes




1050000 Member 〈Agent〉[ ] The entities composing the collective

A.6 Facility

ID 106 EC Facility PT Collective

Description Anything providing a particular service or used for a particular indus-try. Examples of facilities include shops, restaurants, stadiums, the-aters, playgrounds and parks. A facility is primarily a service provider

Attributes


1060000 Date of es-tablishment

Moment The date on which the construction ofthe facility started. In case of buildingssuch as monuments this corresponds tothe date at which the first stone was laid

1060002 Openinghours

String The times when the facility is open forpeople to use it and services are offered

1060010 Address Address The postal address of the facility

1060020 Staff 〈Person〉[ ] The persons (e.g. employees) chargedwith carrying out the work

1060021 Administrator 〈Agent〈[ ] The person or organization that admin-isters the facility

A.7 Organization

ID 107 EC Organization PT Collective

Description An organization is a collective constituted by individuals with commongoals and formal rules. Organizations include corporations, companies,agencies, political parties and other groups of people defined by anestablished organizational structure

Attributes


1070001 Date of es-tablishment

Moment The starting date of the organization

1070002 Date ofdisestablish-ment

Moment The ending date of the organization



1070003 Seat 〈Facility〉[ ] The main seat of operations

1070004 Founder 〈Person〉[ ] The person who established or foundedthe organization

1070005 Leader 〈Person〉 The person having the leadership, thusoccupying the top position in the orga-nization

1070006 Affiliate 〈Agent〉[ ] The person or other organizations thatare affiliated with the organization

A.8 Location

ID 108 EC Location PT Physical Entity

Description It refers to spatial objects, i.e. entities occupying fixed regions of space(e.g., regions, cities, boundaries, parcels of land, water bodies, roads,buildings, bridges, etc.)

Attributes


1080000 Latitude Float The constant coordinate for the latitude(in WGS84 decimal format)

1080001 Longitude Float The constant coordinate for the longi-tude (in WGS84 decimal format)

1080002 Elevation Float The distance above a reference point(such as sea level)

A.9 Artifact

ID 120 EC Artifact PT Physical Entity

Description An artifact represents a physical entity created by a human

Attributes


1200000 Creator 〈Agent〉[ ] The entities (persons or organizations)that participated to the creation of theartifact



A.10 Mind Product

ID 109 EC Mind Prod-uct

PT Entity

Description A mind product is any abstract product of the human intellect

Attributes


1090000 Creator 〈Agent〉[ ] The persons or organizations that par-ticipated in the creation

1090001 Contributor 〈Agent〉[ ] The persons or organizations that con-tributed to the work with less impor-tance than the creator

1090002 Copyright SString A text containing a statement aboutvarious property rights associated withthe mind product

1090003 Audience Concept The target part of the general public towhom the product is directed

1090012 Identifier String[ ] A string or number that identifies it

A.11 Document

ID 110 EC Document PT Mind Product

Description A document is a conventionally text-based work that is used as thebasis, proof or support of something, or simply to transfer information.Instead of or in addition to text, a document may also contain mediaand other resources (e.g. pictures, videos). Examples of documentsinclude books, articles, emails, etc

Attributes


1100000 Title SString A short sentence describing the sub-ject of the document

1100001 Abstract SString A short text summarizing the docu-ment

1100002 Keyword SString[ ] A text encoding a set of words thatare related to the main topics of thepaper, used to index it

1100003 Coverage SString The spatial or temporal topic of theresource, the spatial applicability ofthe resource, or the jurisdiction underwhich the resource is relevant, e.g.



1100004 Reference 〈Document〉[ ] One or more related resources (but ex-ternal to the document) that are refer-enced, cited or pointed to by the doc-ument

1100005 Language Concept A language of the resource, e.g. En-glish, Italian

1100006 Page count Integer The number of pages of the document

A.12 File

ID 121 EC File PT Physical Entity

Description A computer file is a block of arbitrary information or resource forstoring information, which is available to a computer program and isusually based on some kind of durable storage. A file is durable in thesense that it remains available for programs to use after the currentprogram has finished

Attributes


1210000 Creator 〈Agent〉[ ] Creator of the file

1210001 URL String The URL pointing to the physical loca-tion where the file is stored

1210002 Format String The format of the file, denoting a par-ticular way to encode information

1210003 Size Long Measures the actual amount of diskspace consumed by the file (in bytes)

1210004 Tag SString[ ] Keywords or terms associated with orassigned to a file

1210005 Hyperlink 〈File〉[ ] A link from a file to another file

1210010 CreationTime

Moment The time at which the file was created

1210011 ModificationTime

Moment The time at which the file was changed

A.13 Event

ID 130 EC Event PT Entity

Description Something that happens at a given place and time



Attributes


1300000 Venue 〈Location〉[ ] The place where the event occurs (e.g.,city, city quarter, building, set of loca-tions, etc.)

1300001 Event Sta-tus

Concept The current status of the event (e.g. ex-pected, canceled, confirmed)

A.14 Task

ID 131 EC Task PT Event

Description Any piece of work that is undertaken or attempted

Attributes


1310000 Participant 〈Role〉[ ] The list of participants to the event

A.15 Role

ID 500 EC Role PT -

Description The specific frame of activities played by an agent that takes part toa specific event

Attributes


5000000 Agent 〈Agent〉 The agent playing the role

A.16 Address

ID 600 EC Address PT -

Description A collection of information used for describing the location of a build-ing, apartment, or other structure or a plot of land, generally usingpolitical boundaries and street names as references, along with otheridentifiers such as house or apartment numbers

Attributes




6000000 Address NLString The full specification of the address

6000001 Postcode String A code of letters and digits added to apostal address to aid in the sorting ofmail

6000002 Country 〈Location〉 The territory occupied by a nation

6000003 Administrativedivision

〈Location〉 A district defined for administrativepurposes

6000004 Place 〈Location〉 The locality within the administrativedivision (a city, town, village, or otheragglomeration of buildings where peo-ple live and work)

6000005 Way 〈Location〉 The road, the square or any thorough-fare of the locality where the facility islocated

6000006 House num-ber

String Unique number given to each buildingin a street area

6000007 Apartmentnumber

String Number for further sub-dwellings inter-nal to a building (e.g., door, floor, etc)



B Study on Personal Data

Personal information can be generally defined as “data authored by an individual, that de-

scribe an individual, or that can be mapped to an individual” [16]. The complexity of this

kind of data is proved by the plethora of different standards underlining various aspects

of a person, e.g., business domain standards (vCARD [17] and hCARD8), health care do-

main standards (NIH Organizational Person Schema9), and authority records (ISAAR10).

In the context of the Semantic Web, there have been attempts to capture personal data,

e.g., schema.org11 and the FOAF ontology,12 striving for a general enough representation.

Our work on defining personal data originates from a philosophical point of view

and divides them in essential and accidental properties. An essential property of an

entity is a property that it must have while an accidental property of an entity is one

that it happens to have but that it could lack. Note also that essential and accidental

properties, or attributes in the context of entity types, have an equivalent representation

in time. In fact, essential attributes tend to be static, whereas accidental properties

tend to be dynamic. Admittedly, static and dynamic allow for degrees of time variance

and several other differences. Intuitively, static data encompass all identifiers, e.g., IDs

and SSNs, but there are static data that do not serve identity purposes, e.g., biological

features such hair colour, or languages known, which require many years of practice. As for

dynamic data, while they usually rely on sensor inputs, not all of them represent aspects

of users directly quantifiable by sensors. For instance, clothing, interests and mental states

are clearly dynamic; however, they cannot be inferred from sensors. These issue cannot

be attributed to data per se, but rather show some technological limitations; however,

foreseeable technological advancements may change that in the near future.

These philosophical assumptions are combined with a review of the available standards

for representing the Person etype attributes, in addition to the core attributes already

present in MS8. By core attribute we mean the most essential attributes of a person that

we obtained by comparing all attributes of different standards showed in Table 17, and

keeping only those shared by the majority of them, e.g., name, gender, nationality, and so

on. Our approach is based on the assumption that if standards of different domain share

attributes, then these attributes are context independent. W3C has a standard with a

similar scope called Person Core Vocabulary that provides a minimum set of classes and

properties for describing a person, i.e., essential demographics. A complete comparison

8http://microformats.org/wiki/hcard9http://nedinfo.nih.gov/amgtech/docs/schema/current.html

10http://www.ica.org/10206/standards/standards-list.html11schema.org/Person12http://xmlns.com/foaf/spec/


http://microformats.org/wiki/hcard

http://nedinfo.nih.gov/amgtech/docs/schema/current.html

http://www.ica.org/10206/standards/standards-list.html

schema.org/Person

http://xmlns.com/foaf/spec/


of the standards and their representation of Person attributes can be found in Table 18.

Following our initial analysis reported in D4.1, we identify different dimensions of person

attributes by taking into account the assumptions described above and the review of

existing standards:

Essential attributes can be divided into:

1. Identifying attributes: these attributes are used to uniquely refer to an

entity. The strength of their reference depends on their scope, e.g., a name

could be used as an identifier in many contexts but it is not as strong as an ID

issued by a country.

2. Dates and Places of Birth and Death: these attributes define unchangeable

point in time and space and are always true.

3. Languages: languages are a particular kind of quality of a person that require

a long process to obtain, so, while not completely static, they tend to remain

the same throughout a persons life

Accidental attributes can be divided into:

1. Sensor based attributes: as the name suggests, these attributes are origi-

nated from sensors; they cover those quantifiable dimensions of a person, e.g.,

position and biometrics.

2. Descriptive attributes: these attributes are dynamic attributes that cannot

be defined through sensors but do not represent essential aspects of a person,

e.g., hair and eye colour.

3. Domain dependent attributes: these attributes are tied to a specific con-

text, which means they are often true within said context. Similarly to sensor-

based attributes, they show a high degree of time variance, but cannot be

understood via sensors. They are generally social contexts, therefore these

attributes cover dimensions such as:

(a) Skills, e.g., swimming

(b) Preferences and interests, e.g., hobbies

(c) Education and occupation, e.g., degrees

(d) Social relations, e.g., kinship

(e) Contacts, e.g., phone number(s)



Table 17: Personal data standards

Standard Reference Description

vCARD [17] A file format standard for electronic businesscards, and an IETF standards-track

hCARD http://

microformats.

org/wiki/hcard

A format for publishing people on the web,using a 1:1 representation of vCard

CIQ TC http://docs.

oasis-open.

org/ciq/v3.

0/cs/specs/

ciq-xprl-specs-cs.

pdf

A set of XML specifications for representingpersonal data independent of any culture, ge-ographical location, application or industry

ISAAR http://www.

ica.org/10206/

standards/

standards-list.

html

Provides guidance for preparing archival au-thority records for describing entities associ-ated with the creation and maintenance ofarchives

FOAF http://xmlns.

com/foaf/spec/

A computer language defining a dictionaryof people-related terms that can be used instructured data

NIH ORGA-NIZATIONALPERSONSCHEMA

http:

//nedinfo.nih.

gov/amgtech/

docs/schema/

current.html

A standard representing people of the healthcare domain

SCHEMA.ORG schema.org/

Person

A collection of schema used to mark up web-pages

THE PERSONCORE VO-CABULARY

http://www.w3.

org/ns/person

It provides a minimum set of classes andproperties for describing a natural person





http://docs.oasis-open.org/ciq/v3.0/cs/specs/ciq-xprl-specs-cs.pdf


















schema.org/Person

schema.org/Person

http://www.w3.org/ns/person

http://www.w3.org/ns/person

Deliverable D4.2 c© SmartSociety Consortium 2013-2017T

able

18:

Com

par

ison

ofst

and

ard

sfo

rp

erso

nal

data

CIQ

TC

ISA

AR

SC

HE

MA

.O

RG

FO

AF

TH

EP

ER

-S

ON

CO

RE

VO

CA

BU

-L

AR

Y

vC

AR

DN

IHO

R-

GA

NIZ

A-

TIO

NA

LP

ER

SO

NS

CH

EM

A

hC

AR

D

Nam

eN

ames

ad

dit

ion

alN

ame;

fam

-il

yN

ame;

giv

enN

am

e;h

onor

i-fi

cPre

fix;

hon

orifi

cSu

f-fi

x

fam

ilyN

ame;

last

Nam

e;fa

mil

yn

ame;

firs

tNam

e;su

rnam

e

pat

ronym

icN

ame;

bir

th-

Nam

e

Nam

e;F

or-

mat

ted

Nam

e;N

ick-

nam

e;T

itle

Com

mon

nam

e;p

er-

son

alT

itle

;giv

enN

am

e;m

idd

leN

ame;

Tit

le;

sn;

gen

erati

onQ

ual

ifier

;n

ihC

om

mon

-G

iven

Nam

e;n

ihC

om

-m

on

Mid

-d

leN

am

e;n

ihC

om

-m

on

Sn

;n

ihS

uf-

fixQ

uali

fier

;in

itia

ls

Fn

;fa

mil

y-

nam

e;giv

en-n

am

e;ad

dit

ion

al-

nam

e;h

on

ori

fic-

pre

fix;

hon

ori

fic-

suffi

x;

nic

k-

nam

e;


c© SmartSociety Consortium 2013-2017 Deliverable D4.2C

IQT

CIS

AA

RS

CH

EM

A.

OR

GF

OA

FT

HE

PE

R-

SO

NC

OR

EV

OC

AB

U-

LA

RY

vC

AR

DN

IHO

R-

GA

NIZ

A-

TIO

NA

LP

ER

SO

NS

CH

EM

A

hC

AR

D

Ad

dre

ssP

lace

san

d/o

rgeo

gra

ph

i-ca

lare

asof

resi

den

ce

Ad

dre

ss;

conta

ct-

Poi

nt;

resi

den

cyD

eliv

ery

Ad

-d

ress

;L

ab

elA

dd

ress

;

hom

ePost

al

Ad

dre

ss;

nih

Del

iver

yA

dd

ress

;p

ost

al-

Ad

dre

ss;

post

alC

ode;

post

-offi

ce-b

ox;

exte

nd

ed-

ad

dre

ss;

stre

et-

ad

dre

ss;

loca

lity

;re

gio

n;

post

al-

cod

e;co

untr

y-

nam

e;ty

pe;

valu

e;E

lect

ron

icad

dre

ssem

ail

Offi

cial

Web

-si

teE

mai

l;U

RL

;IM

conta

ct;

mail

;E

mail

forw

ard

ing

ad

dre

ss;

Em

ail

;u

rl;

Conta

ctnu

mb

ers

Tel

eph

on

eT

EL

hom

ePh

on

e;h

omeF

ax;

Per

son

alem

ail

ad

-d

ress

;

tel

Iden

tifi

cati

on

det

ails

;U

niq

ue

Iden

-ti

fier

;se

rial

Nu

m-

ber

;n

ihD

up

UID

;


Deliverable D4.2 c© SmartSociety Consortium 2013-2017C

IQT

CIS

AA

RS

CH

EM

A.

OR

GF

OA

FT

HE

PE

R-

SO

NC

OR

EV

OC

AB

U-

LA

RY

vC

AR

DN

IHO

R-

GA

NIZ

A-

TIO

NA

LP

ER

SO

NS

CH

EM

A

hC

AR

D

Bir

thD

ates

an

dp

lace

sof

exis

ten

ce

bir

thD

ate;

dea

thD

ate

;p

lace

OfB

irth

;p

lace

-O

fDea

th;

cou

ntr

y-

OfB

irth

;co

untr

y-

OfD

eath

;

BD

AY

;A

NN

IVE

R-

SA

RY

;

bd

ay

Qu

ali

fica

tion

Occ

up

ati

on;

sph

ere

of

act

ivit

y;

wor

kL

oca

tion

;w

orksF

or;

af-

fili

atio

n;

job

Tit

le;

mem

ber

Of

Wor

kin

fo;

Hom

epag

eP

ast

Pro

ject

;S

chool

Hom

epag

e;W

orkp

lace

-H

omep

age;

Occ

up

atio

nR

OL

E;

OR

G;

MA

N-

AG

ER

;A

S-

SIS

TA

NT

;

role

Rel

ati

onsh

ips

Rel

atio

nsh

ips

Sp

ouse

;S

ibli

ng;

re-

late

dT

o;p

ar-

ent;

kn

ows;

coll

eagu

e;ch

ild

ren

;alu

mn

iOf;

kn

ows

SP

OU

SE

Nati

onal

ity

Nat

ion

ali

tyN

atio

nali

tyci

tize

nsh

ip

Sta

tus

Lan

gu

age


c© SmartSociety Consortium 2013-2017 Deliverable D4.2C

IQT

CIS

AA

RS

CH

EM

A.

OR

GF

OA

FT

HE

PE

R-

SO

NC

OR

EV

OC

AB

U-

LA

RY

vC

AR

DN

IHO

R-

GA

NIZ

A-

TIO

NA

LP

ER

SO

NS

CH

EM

A

hC

AR

D

PH

OT

O;

Log

o;C

AR

DP

ICT

UR

E;

ph

oto



C Aligning WP1 and WP2 Formal Models

In this appendix we analyze the relation between the different models proposed as part of

the foundational notions during the first year of the SmartSociety project. In particular,

we focus the attention on the models of WP1 and WP2. We aim to clarify the scope of

these models and how they can be aligned in order to allow interoperability with other

components of the SmartSociety platform For instance, we are thinking on the integration

of the Peer Manager with the provenance service developed by WP2.

During the first year of the project WP1 and WP2 came up with their own models.

WP1 focused on the way hybridity and diversity can be captured via a semantic schema

and its instantiation for the representation of real world entities (e.g. persons, locations,

events) with an underlying ontology specifying the meaning of the terms used. WP2

focused on provenance as a fundamental tool to support traceability. In some sense WP1

models capture the present (the current properties of the entities) and WP2 the past (who

did what).

To clarify the relation between such models, we need to distinguish among the following

levels (Figure 11):

• Data schema level: D1.1 and D4.1 describe how to define data schemas that we call

entity types (also shortly summarized in subsection 2.1). Similarly to databases,

an entity type specifies constraints on attributes and values that entities of that kind

can instantiate. Differently from databases, this is done with explicit semantics (i.e.

we use ontologies to specify the meaning of the terms used). For instance, we can

define persons as entities having a name, a gender and a date of birth. The ontology

specifies that the term date of birth means “the date on which a person was born”.

Similarly to Object Oriented databases, entity types form a hierarchy where child

entity types specialize parent entity types. For instance, we can define the entity

type person as more specific than agent.

• Data level: Entity types are instantiated in terms of what we call entities. Each

entity instantiates exactly one entity type where its attributes and their values are

consistent with what is defined by the entity type. For instance, we can define the

person John Doe as having a gender attribute whose value is male.

• Metadata provenance schema level: the PROV ontology provides the prove-

nance schema in terms of Agents, Activities and Entities.

• Metadata provenance level: Provenance metadata instantiates the PROV on-

tology schema by labeling data (i.e. it is an instance of metadata and not of data).



For example, it can specify that the person John Doe published an offer of a ride in

the Ride Sharing application. Notice that both the description of John Doe and of

the offer, as entities, are at the data level and are referred to via URIs.

Person Name: string Gender: concept Date of birth: date

Offer Origin: location Destination: location Time: date

Date of birth: (81257) “the date on which a person was born”

Person Name: John Doe Gender: male Date of birth: 1970-01-05

Offer Origin: Trento Destination: Rome Time: 2015-02-25

Person #1

Offer #2 Publish

DATA SCHEMA

(entity types)

DATA

METADATA PROVENANCE

METADATA PROVENANCE

SCHEMA

ONTOLOGY

Figure 11: Alignment of WP1 and WP2 formal models



D Ethical and Privacy issues

In this appendix we explore how the Smart Society project pays attention to issues of

privacy, ethics and social values, and expands upon issues associated more generally with

‘big data’ and profiling driven approaches. In particular, we draw attention to the extensive

scope of the Smart Society vision and its extensive capacity to transform our lives to

highlight the importance of paying close attention to these issues. To do this we draw

on existing literature detailing the ethical challenge that now confront us from increasing

levels of digital mediation within our everyday lives.

The reference to ‘Society’ in the Smart Society name underlines the extensive ambition

of the project. Examples and scenarios generated within the project encompass Tourism,

Care, Health, Policing and span from grand aims of solving problems of sustainability to

assisting the mundane practicalities of finding somewhere to eat in an unfamiliar town.

This breadth and depth underlines the vast scope and everyday pervasiveness implied by

the ambition of a ‘Smart Society’ that aims to address ‘societal challenges’ and operate

at ‘internet scale’ whilst at the same time penetrating into the mundane aspects of many

of our everyday routines and activities. The aim is not to leave these activities unaltered,

but rather to supercharge them by linking individuals into collectives to access collec-

tives’ problem solving and self-organizing abilities, and to draw upon portable devices,

sensors, data and algorithms to assist in ‘orchestrating’ these newly collectivized activi-

ties. Part of the motivation for Smart Society stems from the perception that the existing

accumulations of digital mediation for everyday activities have until now been technically

untidy, due to a lack of appropriate engineering principles, and ethically haphazard, as

a consequence of being unplanned and undirected. Hence Smart Society’s twin foci on

engineering and ethics. Improved engineering is seen to address the problem of ethics by

providing a structured and therefore more considered process for creating such systems.

Ethics helps solve engineering problems by guiding the engineers towards solutions that

preserve certain important social values, such as privacy.

In the context of an increasingly digitally augmented lives, the performance of everyday

activities now involves numerous data streams leading to vast accumulations of data. This

data is viewed as a resource towards solving a wide array of social problems, but its misuse

is also seen as threatening our privacy and autonomy. Goodman analyzes ethical issues in

the era of personal ’big data’ draws attention to the following attributes that carry these

types of risk:[18]:

• “The sensor infused world”. The shear array of sensors, devices and increasingly

everyday objects interconnected via online infrastructures passively generating in-



creasing quantities of data from an ever wider range of activities.

• “Data as commodity”. As data has become valuable in its own right beyond the

services which generated leading to important questions as to who gets to realize

value from data and for what purposes? Nissenbaum’s concept of ‘data integrity’

maintains that use of data should be consistent with the values attached to the

activities producing the data[19].

• “Opacity of back-end information exchange”. The many ways by which data circu-

lates and are traded are hidden from view, as are the ultimate purposes to which

those data may be put. So the ways that such data are subsequently used to filter

or shape our experience of the world are often concealed.

• “Mass scale”. How this is happening on an unprecedented scale and in ways that do

not differentiate between diverse cultural expectations about privacy and data use.

Smart Society could be prone to the hazards described by Goodman for social plat-

forms if data is similarly centralized and its stewardship remains in the hands of platform

operators. Providing tools and policies that extend control of data to users and that

bind operators to principles of transparency are important challenges for Smart Society -

particularly where this creates technical and operational inconveniences.

In the era of personal ’big data’ it is common to use data to profile individuals and

stratify populations as a means to tailoring or individualizing experience, e.g. by target-

ing advertising, creating recommendations or tailoring services. Profiles are used within

Smart Society to involve peers in collectives, perhaps to solve problems, based upon their

experience, skills and reputation. We describe below the importance of profiles for Smart

Society but first we enumerate some of the hazards of profiling already identified in the

literature.

D.1 Social and Ethical Issues of Profiles

• Social sorting. Social Sorting refers to how profiling technologies sorts individuals

into categories in order to affect their experiences and opportunities. Examples in-

clude banks routing calls from wealthier customers deliver speedier service at the

expense of less well off customers or internet service providers giving priority to

certain traffic or favored customers. Negative effects of sorting include reinforc-

ing existing social divisions and creating new yet invisible hierarchies of access and

privilege[20].



• Autonomy and self-determination. Often profiles are created and used without our

knowledge or consent, and the ways that our experience of services is modified by

profiling is typically invisible. Where profiles are computed from data about us,

then we are subject the the values embedded in the algorithms used to sift that

information, but not given a voice in the creation of those algorithms. When we

create profiles (e.g. on Linkedin or Facebook) then we are still constrained by what

we can express and have little control over how much a flat partial identity may be

read by others as a literal depiction of who we are.

• Diminishing diversity. “With commercial personalization services, the myriad of

individual differences is reduced to one or a few consuming categories, on the basis

of which their preferences, character, life-style and so forth are determined for a

specific context. Because of its tendency to generalize, personalization may lead to

diminishing preferences, differences and values...” [21]. A question raised during the

Patras workshop underlines this point. The questioner characterized our experience

of city life as in turns vivid, serendipitous, frustrating and pleasurable and ques-

tioned how city life mediated through Smart Society ‘apps’ may lead to a dulling,

standardisation and impoverishment of these sorts of experience. It is important for

Smart Society to retain elements of fun, chance, discovery and provide an experi-

ence that is enriching to and complementary to existing beneficial forms of city life,

and avoid the tendency of computer science to frame problems narrowly in terms of

optimization.

Profiles are a crucial component within the Smart Society platform and it is the Peer

Profile which gives participants their identity within the system and thereby governs the

relationship between individuals and the collectives in which they may become involved.

The Smart Society Peer Profile codifies the participant’s reputation, interests, expertise

and actions. The system uses this information to work out if it can recruit the ‘peer’ to

contribute to solving a problem. In this way the peer profile plays a role in determining

participants’ opportunities within the system. Given the extent of Smart Society vision

then this could imply significant advantages or deficits in life-chances where profiles gov-

ern participants’ access to culture, education, healthcare and their ability to engage in

economic activity. In the context of Smart Society then peoples’ very participation in civil

society may be at stake.

Some risks of privacy profiling within Smart Society are being addressed in Smart

Society, as it was presented in the main part of this deliverable. In particular, risks to

autonomy are addressed by creating mechanisms that give the participant ownership of

their profile by hosting it on their device; allowing the user to edit or amend any aspect;



and in specifying policies describing in what circumstances the data may be shared across

the platform.

D.2 Privacy Issues of Profiles

Peer profiling may affect privacy in different respects. As the Council of Europe has

discussed in its recommendation cm/rec(2010)13 on profiling [22], the collection, linking,

calculation, comparison and statistical correction of data with the objective to create

profiles may have significant privacy impacts, as profiling enables a person’s personality,

behavior, interests and habits to be determined, analyzed and/or predicted. Often such

profiling is even happening without the knowledge of the individuals concerned. While

profiling may offer benefits for users and society at large, e.g. by providing users with

targeted and better services addressing personal and societal interests or by permitting an

analysis of risks and fraud, profiling techniques can also have the impact on the individuals

concerned by placing them in predetermined categories and may unjustifiably deprive them

from accessing certain services and by this discriminate individuals, a we also pointed out

above [22].

Moreover, profiling techniques do not only allow to analyze data that are actually

recorded, but also allows to statistically predict or implicitly derive information from such

records. For instance, sensitive data including about political opinions, religious beliefs,

intelligence or sexual orientation can be automatically predicted from Facebook Likes (see

e.g., [23]).

During the workshop at Patras, the following more specific privacy questions, mostly

related to peer profiling, were raised and discussed, but not finally answered, which implies

that they still largely remain challenges to be addressed within Smart Society:

• How can privacy interests of “collectives” (consisting of several individuals and/or

machines) be protected? How can collectives be formed in an anonymous manner,

i.e. in a way that it does not relate to any identified or identifiable person? Can

privacy policy languages be extended to define privacy preferences of Collectives and

negotiate privacy policies for Collectives? Is it a challenge to define/jointly agree on

privacy preferences for Collectives in regard to personal data that they have in com-

mon/share, or can group decisions and crowdsourcing on privacy preference settings

enable/motivate users to spend more efforts on privacy preference management?

• In hybrid systems, peer profiles of machines could include personal data of one or

even several data subjects. For instance, in the application of Smart Society to a

care scenario, sensors may capture data about when and for how long health care



professionals and patients have met. This implies that the sensor readings may reveal

both personal information about health care professionals and the patients. Under

which conditions can data subjects of data relating also to other data subjects can

exercise their data subject rights (if for example the data is only intended for the

health care professionals to organise their work, the patient (or their relatives) may

still have the right to access data items that relate to them (e.g., to check whether

the patient gets the right treatment)?).

• Are anonymous credentials suitable pets (privacy-enhancing technologies) for en-

hancing the privacy of passengers and drivers participating in a Smart Society en-

abled ‘ride sharing’ platform that is currently under implementation? Both drivers

and passengers could be pseudonymously be registered by the platform and prove

only certain properties (e.g., passion of driving license for more than five years, rep-

utation scores). Will the use of anonymous credentials in this context be practically

feasible and socially accepted?

Privacy-related questions concerning privacy on sensor data collection [9], trust and

reputation [10], and provenance [11] were also raised. These topics are being addressed by

Smart Society and are not discussed in this deliverable.



E Policy Example

In this appendix, we present a small example PPL policy. This example is been purposely

kept small due to presentation purposes and is only meant to give the reader an idea of

how such a policy might look. The policy is not meant to be read by people, but rather by

machines. In the Peer Manager such policies are meant to be used to regulate the access

and release of personal data based on the users preferences. The final version of PPL used

in Smart Society might be a reduced set of PPLs capabilities. The policy in this example

only cover the data items nickname, location and food preferences and describe how they

can be used in the smart food application.

The policy consists of tree rules one for each of the data items. Each rule consists of

two parts. The first part describes the data type and the access permissions to that data

part. The second part describes the data handling policy for the data item. The data

handling policy contains an authorization part that describes the purposes for which the

data item can be used and an obligation part that stipulates how the data item is to be

handled.

In the current example:

• nick name can be used for contact, food recommendation and search purposes,

• location for search and food recommendation purposes with the obligation that ac-

cess is logged when its used for search purposes,

• and food preferences can be used for search and food recommendation purposes.

In all of the cases the data value is only allowed to be read.

For a full description of the PPL language we refer the reader to ( S. Trabelsi, G Neven,

D. Raggett ed., D5.3.4 Report on design and implementation, Deliverable, PrimeLife,

2011.)

<?xml version=” 1 .0 ” encoding=”UTF−8”?>< !DOCTYPE p p l : P o l i c y S e t [<!ENTITY pplschemapath ”schema/”> ]><p p l : P o l i c y S e t xs i : s chemaLocat ion=” h t t p : //www. p r i m e l i f e . eu/ ppl

schema/PrimeLifeSchema . xsd h t t p : //www. p r i m e l i f e . eu/ ppl /c r e d e n t i a l schema/ Pr imeLi f eCredent ia l . xsd h t t p : //www.p r i m e l i f e . eu/ ppl / o b l i g a t i o n schema/ Pr imeLi f eObl igat ion . xsdu r n : o a s i s : n a m e s : t c : x a c m l : 2 . 0 : p o l i c y : s c h e m a : o s h t t p : // docs .oa s i s−open . org /xacml/ a c c e s s c o n t r o l−xacml−2.0−po l i cy−schema−os . xsd” Po l i cySe t Id=”#topLeve l ” PolicyCombiningAlgId=”



u r n : o a s i s : n a m e s : t c : x a c m l : 1 . 0 : p o l i c y−combining−a lgor i thm:permit−o v e r r i d e s ” xmlns :ppl=” h t t p : //www. p r i m e l i f e .eu/ ppl ” xmlns :x s i=” h t tp : //www. w3 . org /2001/XMLSchema−i n s t anc e ”

xmlns : c r=” h t t p : //www. p r i m e l i f e . eu/ ppl / c r e d e n t i a l ” xmlns:ob=”h t t p : //www. p r i m e l i f e . eu/ ppl / o b l i g a t i o n ” xmlns:xacml=”u r n : o a s i s : n a m e s : t c : x a c m l : 2 . 0 : p o l i c y : s c h e m a : o s ”>

<xacml:Target />



<xacml:Target /><ppl :Ru le E f f e c t=”Permit” RuleId=”SmartFood#Nickname”>

<xacml:Target><xacml :Resources>

<xacml:Resource><xacml:ResourceMatch MatchId=”

u r n : o a s i s : n a m e s : t c : x a c m l : 1 . 0: funct ion:anyURI−equal ”>

<xacml :Attr ibuteValue DataType=”h t t p : //www. w3 . org /2001/XMLSchema#anyURI”>h t t p : //www. w3 . org /2006/vcard /ns#nickname</xacml :Attr ibuteValue>

<xacml :ResourceAttr ibuteDes ignatorDataType=” h t t p : //www. w3 . org /2001/XMLSchema#anyURI” Att r ibute Id=”h t t p : //www. p r i m e l i f e . eu/ ppl /Uncer t i f i edAtt r ibuteType ”/>

</ xacml:ResourceMatch></ xacml:Resource>

</ xacml :Resources><xacml :Act ions>

<xacml:Act ion><xacml:ActionMatch MatchId=”

u r n : o a s i s : n a m e s : t c : x a c m l : 1 . 0: f u n c t i o n : s t r i n g −equal ”><xacml :Attr ibuteValue DataType=”

h t t p : //www. w3 . org /2001/XMLSchema#s t r i n g ”>read</xacml :Attr ibuteValue>



<xacml :Act ionAttr ibuteDes ignatorDataType=” h t t p : //www. w3 . org /2001/XMLSchema#s t r i n g ” Att r ibute Id=”u r n : o a s i s : n a m e s : t c : x a c m l : 1 . 0: a c t i o n : a c t i o n−id ”/>

</ xacml:ActionMatch></ xacml:Act ion>

</ xacml :Act ions></ xacml:Target><ppl :DataHandl ingPre fe rences>

<ppl:AuthzUseForPurpose>

<ppl :Purpose>h t t p ://www. w3 . org /2002/01/P3Pv1/ contact</ppl :Purpose> <ppl :Purpose>h t t p : //www. w3 . org /2006/01/P3Pv11/ search</ ppl :Purpose>

<ppl :Purpose>h t t p ://www. smartSoc ie ty . eu /2014/PPLv11/ food−recomendation</ ppl :Purpose>

</ ppl:AuthzUseForPurpose><ppl:AuthzDownstreamUsage al lowed=” f a l s e ”/>

<ob :Ob l i ga t i on sSe t />

</ pp l :DataHandl ingPre fe rences></ pp l :Ru le><ppl :Ru le E f f e c t=”Permit” RuleId=”SmartFood#Locat ion ”>

<xacml:Target><xacml :Resources>

<xacml:Resource><xacml:ResourceMatch MatchId=”

u r n : o a s i s : n a m e s : t c : x a c m l : 1 . 0: funct ion:anyURI−equal ”><xacml :Attr ibuteValue DataType=”

h t t p : //www. w3 . org /2001/XMLSchema#anyURI”>h t t p : //www. w3 . org /2006/vcard /ns#Locat ion</xacml :Attr ibuteValue>


</ xacml:ResourceMatch>



</ xacml:Resource></ xacml :Resources><xacml :Act ions>




<xacml :Act ionAttr ibuteDes ignatorDataType=” h t t p : //www. w3 . org /2001/XMLSchema#s t r i n g ” Att r ibute Id=”u r n : o a s i s : n a m e s : t c : x a c m l : 1 . 0: a c t i o n : a c t i o n−id ”/>




<ppl :Purpose>h t t p ://www. w3 . org /2006/01/P3Pv11/ search</ppl :Purpose> <ppl :Purpose>h t t p : //www. smartSoc ie ty . eu/2014/PPLv11/ food−recomendation</ppl :Purpose>


<ob :Ob l i ga t i on sSe t>

<ob :Ob l i ga t i on><ob :Tr i gge r sSe t>

<ob:TriggerPersonalDataAccessedForPurpose> <ppl :Purpose>h t t p : //www. w3 . org/2006/01/P3Pv11/ search</ppl :Purpose><ob:MaxDelay>



<ob:Durat ion>P0Y0M0DT0H2M0.000 S</ ob:Durat ion>

</ob:MaxDelay></

ob:TriggerPersonalDataAccessedForPurpose>

</ ob :Tr i gge r sSe t><ob:ActionLog />

</ ob :Ob l i ga t i on></ ob :Ob l i ga t i on sSe t>

</ pp l :DataHandl ingPre fe rences></ pp l :Ru le><ppl :Ru le E f f e c t=”Permit” RuleId=”SmartFood#Food

Pre f e r en c e s ”><xacml:Target>

<xacml :Resources><xacml:Resource>

<xacml:ResourceMatch MatchId=”u r n : o a s i s : n a m e s : t c : x a c m l : 1 . 0: funct ion:anyURI−equal ”><xacml :Attr ibuteValue DataType=”

h t t p : //www. w3 . org /2001/XMLSchema#anyURI”>h t t p : //www. smar t soc i e ty/2014/PPLv11/ns#food−p r e f e r e n s e s</ xacml :Attr ibuteValue>


</ xacml:ResourceMatch></ xacml:Resource>

</ xacml :Resources><xacml :Act ions>




<xacml :Act ionAttr ibuteDes ignatorDataType=” h t t p : //www. w3 . org /2001/



XMLSchema#s t r i n g ” Att r ibute Id=”u r n : o a s i s : n a m e s : t c : x a c m l : 1 . 0: a c t i o n : a c t i o n−id ”/>




<ppl :Purpose>h t t p ://www. w3 . org /2006/01/P3Pv11/ search</ppl :Purpose>

<ppl :Purpose>h t t p : //www. smartSoc ie ty . eu/2014/PPLv11/ food−recomendation</ppl :Purpose>


<ob :Ob l i ga t i on sSe t />

</ pp l :DataHandl ingPre fe rences></ pp l :Ru le>





F Implementation

The main focus of this year’s deliverable has been about establishing the Peer Manager’s

underlying theory/model and defining its architecture within the SmartSociety Platform.

Nevertheless, implementation work has also been started this year and simple Proof of

Concept was finished and integrated with similar results from other work packages (namely

WP6, WP7 and WP8). This appendix contains a very high-level explanation of the

current implemented version along with the details of the main API endpoints and JSON

structures that were used for interacting and integrating with the current SmartSociety

demo/pilot.

F.1 Implementation Details and Choices

As shown in Section 5 (more specifically in Fig. 8) the Peer Manager implementation is

separated in two broad groups:

• The Peer Base Back-end is written in Java and it requires commonly-used frame-

works like Hibernate13 and Spring 14. From Fig. 8, everything inside the Peer Base

(including the management of Knowledge Bases, Entity Bases, Users and Peers) is

implemented in the Peer Base Back-end.

• Peer Manager Front-end is also written in Java and implements the two web APIs

from Fig. 8 (namely the Peer Base Web API and the Peer Manager Web API).

These APIs, along with some minimal data processing, mainly de-serialize the JSON-

based http calls they receive and call the methods from the Peer Base Back-end; the

responses received from the Peer Base Back-end are then serialized back in these

API and sent back to the caller.

Due to the early nature of the code in this year’s Proof of Concept, no Peer Manager

related has yet been released. Nevertheless, we expect to release the much more complete

and integrated version of the Peer Manager Front-End (due in M30 with D4.3) as open

source.

F.2 Year Two Peer Manager Integrated Proof-of-Concept

The implemented functionalities were heavily aimed to this year’s (M24) integrated demo

and as such many important features of the Peer Manager (e.g. like privacy protection)

were not yet focused on. The following is a quick list of the functionalities currently

supported by the Proof of Concept version of the Peer Manager.

13http://projects.spring.io/spring-framework/14http://hibernate.org/



• Knowledge Base Object Management : includes CRUD operation on all KB objects

(e.g. Concepts and Etypes15)

• Entity Base Object Management : includes CRUD operation on all EB objects (e.g.

attribute values, Entity Instances).

• Peer, User, Collective and Profile Management : includes the creation of Peers (and

the generation of all of their internal structures), Users and Profiles16 based on

existing Entities. An early version of Collective creation is also present in this

version due to partner requests.

• Search and Peer Matching : the general search17 functionality used to match tasks(represented

as query parameters) to a list of peers (represented as the result of the search oper-

ation).

It is also worth noting that the implementation of the previous functionalities is not

final so their details may change according to feedback from partners and other factors.

F.3 Proof-of-Concept Integration Calls Specification

The following section specifies examples of the calls that the Proof of Concept version

of the Peer Manager accepts and the replies (example+format) that it produces. These

calls were used as the basis for integration for the production of this year’s SmartSociety

integrated demo.

15Please refer to Section 2 for a more detailed information of structures from the Knowledge Base andthe Entity Base

16Please refer to Section 3 for more information about these structures17Please refer to Section 4 for general information on Search and Ranking



Figure 12: Call and response for searching all available peers for a generic task. Thiscall is used by WP6 (Orchestration) to obtain a list of users (that represent peers) thatmatches their set requirement.



Figure 13: Call and response for creating a new collective from a set of passed users. Thiscall is used by the WP8 developed client to convert the list of users given by WP6 into asingle Collective.



Figure 14: Call and response for reading all the users from a given collective. WP7(Middleware) uses this call to get the individual Users from a Collective with the intentionof later contacting them.



Figure 15: Call and response for reading the contact information of a given peer. WP7uses this call to get the specific contact preferences of a user in order to follow them whencontacting that user.

Documents

D4.2 - Peer Search in Smart Societies