D9.2 - Design of Serious Game-based Simulation Platform

SmartSociety Hybrid and Diversity-Aware Collective Adaptive Systems When People Meet Machines to Build a Smarter Society Grant Agreement No. 600854

Deliverable D9.2 Work package WP9

Design of Serious Game-based Simulation Platform

Dissemination level (Confidentiality)1:

PU

Delivery date in Annex I:

31/06/2014

Actual delivery date:

17/07/2014

2

Status :

Final

Total number of pages:

40

Keywords:

Virtual gamified environment, smart tourism serious games, platform, design.

1

PU: Public; RE: Restricted to Group; PP: Restricted to Programme; CO: Consortium Confidential as specified in the Grant Agreement 2 F: Final; D: Draft; RD: Revised Draft

Š SmartSociety Consortium 2013 - 2017

Page 2 of (40)

Deliverable D9.2

http://www.smart-society-project.eu/

Deliverable D9.2

© 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 SmartSociety 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 Collective Adaptive Systems: When People Meet Machines to Build a Smarter Society

Project Acronym:

SmartSociety

Grant Agreement Number:

600854

Number and title of work package:

WP9, Proof of Concept and Validation

Document title:

Design of Serious Game-based Simulation Platform

Work-package leader:

Imaginary SRL, IMA

Deliverable owner:

U-Hopper SRL, UH

Quality Assessor:

Alethia Hume, UNITN

© SmartSociety Consortium 2013 - 2017

Page 3 of (40)

Deliverable D9.2

Š SmartSociety Consortium 2013 - 2017

List of contributors

Partner Acronym IMAGINARY UH UOXF

Page 4 of (40)

Contributor Marco Pompa, Lucia Pannese, Luca Rioli Iacopo Carreras, Daniele Miorandi, Tommaso Schiavinotto Mark Hartswood, Marina Jirotka

http://www.smart-society-project.eu/

Deliverable D9.2

Š SmartSociety Consortium 2013 - 2017

Executive summary Deliverable 9.2 (Design of Serious Game-based Simulation Platform) describes the initial design of the gamified environment that will be used to validate the SmartSociety concept. A virtual gamified environment is a user-oriented framework exploiting game elements and game design techniques to allow users to access the features and functionalities developed in the SmartSociety system by the technical WPs. In this deliverable we present the methodology utilized to involve end-users in the participatory design of the virtual gamified environment. In particular, we will participate to 3 events, where various interactive contents will be used to provide an immersive experience to various stakeholders in the tourism domain. Through these events, we will gather the necessary feedback to validate the initial design of the virtual gamified environment before moving into the implementation phase.

Finally, the integration of the virtual gamified environment and the SmartSociety platform developed by WP8 is discussed. We review the initial design, provide a high level view of the APIs that will be provided by the SmartSociety platform, and illustrate how a computation task issued by the virtual gamified environment is processed until a result is returned. A specific use case is used to explain the overall process, and how it is mapped into SmartSociety.

Š SmartSociety Consortium 2013 - 2017

Page 5 of (40)

© SmartSociety Consortium 2013 - 2017

Deliverable D9.2

Table of Contents Table of Contents ................................................................................................................................................ 6 1 Introduction .................................................................................................................................................. 7 2 Participatory design and existing components ............................................................................................. 8 2.1 User engagement exercise ..................................................................................................................... 8 2.1.1 Aims ................................................................................................................................................ 8 2.1.2 Approach ......................................................................................................................................... 9 2.2 Non-integrated collection of available resources ................................................................................ 10 2.2.1 Applications .................................................................................................................................. 10 2.2.2 Graphical Mini-scenario examples from other WPs ..................................................................... 13 2.3 User engagement events ...................................................................................................................... 18 3 Design of the virtual gamified environment .............................................................................................. 19 3.1 Game Environment Prototype design .................................................................................................. 19 3.1.1 Ego, SmartAdvisor, Alterego ........................................................................................................ 19 3.1.2 User Profile structure .................................................................................................................... 21 3.1.3 Technologies ................................................................................................................................. 22 3.2 Tourism scenario implementation ....................................................................................................... 22 3.2.1 UC1: Touristic Attractions Recommender ................................................................................... 23 3.2.2 UC2: Recruit voluntary tourist guides .......................................................................................... 23 3.2.3 UC3: SmartSociety answers.......................................................................................................... 24 4 Integration with the SmartSociety platform ............................................................................................... 25 4.1 SmartSociety platform design review .................................................................................................. 25 4.1.1 SmartSociety Programming Framework and APIs ....................................................................... 28 4.2 Illustrative Example ............................................................................................................................. 30 5 Next Steps .................................................................................................................................................. 34 References ........................................................................................................................................................ 36 6 Appendixes ................................................................................................................................................. 37 6.1 Messages Exchange example in the Game environment platform ...................................................... 37

Page 6 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

1

© SmartSociety Consortium 2013 - 2017

Introduction

WP9's main role in the SmartSociety project is to design and implement the prototype of a virtual gamified environment as the validation of the whole SmartSociety concept. A virtual gamified environment is a user-oriented framework exploiting game elements and game design techniques to allow users to access the features and functionalities developed in the SmartSociety system by the technical WPs. In a nutshell, WP9 will enable users to actively benefit from computations performed by humans, machines and a combination thereof, through the functionalities made available by the SmartSociety platform developed in WP8. The gamified environment will exploit a mix of social dynamics, apps, serious games and gamification elements and a unique central graphical interface to implement the final application scenario, namely tourism, that will be used to validate the overall SmartSociety concept and the technical work being performed by the various technical Workpackages.

During the first year, WP9 set the foundation of the virtual gamified environment, by defining four visionary scenarios and identifying a preliminary collection of high-level requirements from one of them, namely tourism. This work is described in detail in D9.1.

Particular focus was therefore put on the tourism domain and the corresponding scenario was validated with relevant stakeholders. This scenario provided the first setting for the design of the gamified environment, representing the starting point to derive functionalities for the implementation of a wider and more generic gamified environment to come.

Building on these preliminary results, Y2 work until M18 was dedicated to several activities aimed at coming up with a high-level specification of the virtual gamified environment system architecture. The activities can be summarized as follows: 1. Planning and organization of a series of public engagement activities necessary for the definition and design of the virtual gamified environment. The reference scenario was the Tourism domain. Such events will involve various stakeholders in this field, and will allow us to understand which constraints and motivations would be required to create a successful gamified environment prototype. During the organization of such events, the following activities have been performed: • WP9 identified a collection of resources, including mobile applications and serious games, mapping aspects of the tourism scenario’s functionalities elicited in Y1. Such resources will be used during such events in order to stimulate interaction with users and collect feedback on (i) the tourism scenario initially defined in Y1 and documented in D9.1 (ii) validate the design of the game environment which will be presented in this deliverable.

• As the virtual gamified environment prototype will allow validating the overall project concepts and will operate on top of the SmartSociety platform, inputs on the tourism scenario were collected in parallel from the other technical WPs. • Building on the empirical work undertaken in WP1 relating to social values, a methodological approach for user-engagement for WP9 has been defined. By exposing end-users and other stakeholders to SmartSociety concepts, WP9 aims to understand better how to build SmartSociety technologies in a socially acceptable way.

2. A technical high-level specification of the virtual gamified environment exploiting WP8 features: • The design of the structure and the technologies at the base of the virtual gamified environment has been defined at a high-level. This includes the key components that will be part of the environment, and how they will be utilized by applications (e.g., smart tourism) running on top of the environment.

• In terms of integration with the technological infrastructure being developed within WP8, an extensive dialogue was established. This played an important role in the revision of the platform-level APIs that will be released officially at M24 as part of © SmartSociety Consortium 2013 - 2017

Page 7 of (40)

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

D8.2. Further, it allowed us to better understand how the computing facilities offered by SmartSociety can be delivered to developers willing to create applications based on this.

The main objective of this deliverable is to describe the preliminary design of the virtual gamified environment and its technical high-level specification. This will set the basis for the next development phases. According to the DoW, this document will be regularly updated throughout the entire lifetime of the project, incorporating the feedback that we will receive from (i) the technical Workpackages and (ii) the stakeholders that will be involved both in the design of the virtual gamified environment and in the validation of the application scenario and related use cases.

The remaining parts of this deliverable are organized as follows: • Section 2 explains the user engagement process, in terms of methodology and available resources, to start involving users. This represented the starting point for the organization of 3 events that will be used to gather feedback on the gamified environment and tourism application scenario; • Section 3 describes the overall structure of the system that will support the virtual gamified environment prototype. This includes also an example of how some specific use cases identified in the tourism scenario can be mapped on top of it.

• Section 4 illustrates how the gamified environment prototype can be integrated with the SmartSociety platform developed in WP8; • Section 5 concludes the document describing the work planned for the next phase of the project.

2 Participatory design and existing components This section describes the process by which user engagement activities have been carried out by WP9 in collaboration with WP1. Users involvement is necessary in this phase for understanding the requirements for the virtual gamified environment and achieving an effective design able to engage users in its utilization. Stakeholders’ perspective is therefore fundamental to realize a successful and suitable prototype, since they are potential future users of the applications build on top of the SmartSociety platform.

We will first describe the chosen methodology, in terms of objectives and strategy at the base of user involvement and engagement. This is based on a list of resources that were considered appropriate to cover some functionalities derived from the tourism scenario and suitable to stimulate the participation of the involved users. In particular: two serious games, including one pre-existing mobile app and one mock-up created ad-hoc starting from the tourist scenario; some graphic scenarios created by WP9 after collecting contribution from other technical WPs, illustrating examples of application of the tourism scenario from their WP's perspective.

The process described will be utilized in three meetings, in which WP9 representatives will interact with stakeholders in order to gather requirements and feedback on the platform design. We will the conclude this section by describing the different approaches and modes of interaction chosen for the 3 user-engagement events that are currently planned.

2.1 User engagement exercise 2.1.1 Aims There is a two-fold aim of the current public engagement strategy being prepared by WP9 and WP1. Firstly it intends to gather impressions of the ways that SmartSociety might be used in tourism to validate our existing scenarios and deepen requirements. Secondly it aims to expose stakeholders to the intentions and ambitions of SmartSociety to provide an opportunity for those stakeholders to respond to and influence the directions taken by the SmartSociety project. On this approach we propose a convergence between conventional 'user-studies' to inform system design Page 8 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

and methods of civic participation more usually employed to draw wider publics into processes of research and innovation. We believe that this convergence is more than a matter of convenience and is actually increasingly warranted as social ICTs, and particular those systems envisaged by SmartSociety, may rapidly have profound economic and cultural impacts that depend upon how they are configured and regulated3.

2.1.2 Approach Initially public engagement will centre on the tourism scenario as this has the greatest maturity.

Literatures on public engagement reveal this to be a process fraught with pitfalls for the unwary (Cornwall, 2008; Felt & Fochler, 2010). Dangers include • Tokenism: The exercise ticks the participation box, but has no real impact on the direction or shape of the project.

• Self justification: The exercised aims to justify decisions that have already been taken and is used to pacify rather than to engage and listen to publics.

• Pre-formulation: The materials used for engagement narrowly frame the issues and preconfigure certain types of response.

• Selection: Means of engagement (advertising, venues etc.) select certain publics and exclude others.

Although no participation exercise will be perfect, and all involve trade-offs, it is important to be aware of the above risks and minimise their effects as far as possible given the resources available.

Below we explain how our approach attempts to address these issues: 1. Creating materials.

To ensure representation of the broadest range of issues we have solicited materials from each WP to ensure that concepts from each workpackage will be visible within the engagement materials. In addition, though reflection and iteration we identified the need to represent scenarios from different perspectives including operational perspectives (how the goals driving a CAS influence the users' experience), collective perspectives (what use of a CAS may mean for a collective as opposed to individuals) and how use of CAS may be problematic as well as beneficial.

2. Selecting publics.

To date we have been opportunistic in our engagement of publics and stakeholders by engaging those attending events at which we have a presence. This will inevitably limit the population we are able to reach to the demographic usually associated with this type of event. These points of contact are useful nonetheless as they provide some information, and help us refine the materials and approach. To gain a better coverage across publics we need to undertake a 'stakeholder analysis' (e.g. Brugha and Varvasovszky, 2000) to be more systematic and targeted in identifying stakeholders and publics we would like to reach. One innovation to assist this is that we are creating a virtual version of the engagement materials that will be more broadly accessible.

3. Engagement strategies.

To date we have been involved in creating a set of materials that present simple storylines in cartoon form. They are easy to follow and convey key concepts well. We have been presenting these materials to members of the public and soliciting responses by asking what they like or dislike about the scenarios. We will think about how we can extend how we use this basic template to reduce its framing effect in a number of ways. These include: reaching out to broader publics using online materials; creating some exercises that are more focus-group like in their constitution to allow longer deliberation; asking participants to help us find problems or drawbacks with the scenarios, and then to help think about solutions; for a small group of participants to go to actual 3

For recent controversy see http://www.bbc.co.uk/news/technology-27783218 © SmartSociety Consortium 2013 - 2017

Page 9 of (40)

© SmartSociety Consortium 2013 - 2017

Deliverable D9.2

tourist locations and use the experience of 'being there' as a means of interrogating the scenario; to have a session where we make visible some of the values embedded in the scenario and ask what scenarios based on alternative values might look like.

4. Incorporation within the project.

An important aspect of user-engagement activities is the process of incorporating the feedback into the project. It can be demotivating for participants if they believe that their engagement is unlikely to be influential. Some argue too that a sign of effectiveness for a public engagement exercise is to be able to demonstrate how it influenced the project (e.g. Rowe et al, 2008). We would seek to bring information from engagement exercises to the project in a number of ways. Firstly we would create a connections back to the WPs that provided material for the exercise by giving them a report or summary of findings relevant to their WP. We would also use existing communication channels of project meetings and workshops to feedback more general findings. For each WP we would ask them in return how useful they found the feedback, how they interpreted the findings and the effect the findings had on their work activities.

2.2 Non-integrated collection of available resources As above-mentioned, in the following we present various resources covering a set of functionalities derived from the tourism scenario, that have been collected to involve users in understanding SmartSociety project aspects through the lens of the tourism scenario. We have distinguished between specific applications that we have utilized in an interactive way and Graphical scenarios that will be used to easily explain certain functionalities that will be offered by through the virtual gamified environment and SmartSociety platform. Both type of resources were used to immerse stakeholders in the target application scenario (tourism) and gather a more focused and participatory feedback 2.2.1 Applications 2.2.1.1 EcoHunters game This is an already existing mobile game for Android that was developed by Imaginary in the context of tourism and smart mobility, Description This app aims to motivate tourists to visit a city traveling through several points of interest recommended by the system on the basis of the preferences specified in the user profile. In order to achieve this goal, tourists are asked to take part of a real treasure hunt within the city.

Users must access the game through their credentials and press the “treasure hunt” button. Once they have selected a start point and an end point (that can coincide) and the difficulty level (in other words the number of POIs they want to visit), the app will return a new treasure hunt consisting of the best recommended path formed by a list of POIs that match with the users’ preferences.

How to play Each POI will represent a hint for the treasure hunt, thus users must physically move to each of them (by walk or using public transport suggested by the route planner) and press the check-in button in order to complete the mission.

Each treasure hunt includes also a hidden mosaic, whose tiles will be unveiled every time a checkin is done in correspondence of a POI included in the list.

Page 10 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

Rewards When the whole mosaic is finally completed, players will be rewarded with a special badge and a certain amount of smartmoney.

If they are not able or don’t want to go to one or more POIs, they can decide to “buy” the corresponding tile, whose value (given in smartmoney) will be deducted from the final reward of the mission.

Market The special badges are very important because they allow users to get real vouchers (e.g. discounts or tickets) that organizations such as museums, restaurants, public transport, etc. have made available in the virtual market. Usually a voucher will be obtained with a combination of different © SmartSociety Consortium 2013 - 2017

Page 11 of (40)

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

special badges. For this reason, players can offer their special badges on sale in exchange of smartmoney. Similarly they can buy from other users the special badges that they need.

SmartSociety features • Incentives (WP5): virtual currency, badges and real coupons.

• Social cooperation (WP5/WP6): virtual market.

• Gamified guide (WP5): incentives.

• Matching user preferences (WP4): user profiling.

2.2.1.2 Questions&Answers Game This mock-up was ad hoc designed as an example of game app in tourism context, exploiting functionalities derived from the validated tourism scenario.

Description The game is based on the tight cooperation between tourists and local citizens: tourists can post their questions, while everyone, especially local people can share their up-to-date local knowledge, answer questions, and help tourists out. The involvement of local people who have the pleasure to offer their knowledge and passion will allow visitors to receive real-time advices on cultural heritage and tourist information. In this way, regardless of where they are located, citizens can act as virtual guides and feel helpful and socially included through the use of technology and without moving physically. This will permit even to elderly and disabled people to be active participants.

The game was initially designed for helping tourists out, but this crowdsourcing format can be applied to other domains.

In summary, the app has two main objectives: • Utilize crowd knowledge in order to build a new knowledge base for tourists, which can potentially be used to create more and better services.

• Harness local citizens knowledge to help tourists having a pleasant trip, or to solve problems occurring during their trip or in their daily life.

ASK A QUESTION

MY QUESTIONS

BADGES & POINTS

12

UPDATES

OPEN QUIZZES

SETTINGS

HELP

How to play Questions can be gathered from many different tourism related sites and can be re-asked as quizzes.

Questions are chosen and proposed based on individual users' skills and preferences and they are proposed with a frequency related to the engagement rate of the individual user.

Page 12 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

Answers have a characters limit, as it both lowers the threshold of participation and forces players to answer questions quickly and in a concise manner. Since the answers are short, one can easily play during a coffee break or on the bus.

Finally, a tourist who has posted the question could vote whether the answer is relevant and if it helps.

ASK A QUESTION

55

Quizzes

Milan

What are the nice places one should visit around Milan Cathedral?

DAVID Chu

28 Sept 2013

What is the fastest way to go to the Milan train station from Holiday Western?

ALICE BIANCHI

27 Sept 2013

How can I get to Bologna from Milan Lambrate?

MARGARET WEISS

25 Sept 2013

What are the most popular dining places one could go around Milan Duomo?

Yang Jong

25 Sept 2013

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Milan vel lorem eros. Suspendisse pulvinar pretium urna, nec volutpat mi tempus sed. Aenean non sem odio. Mauris ultrices sit amet dui ac luctus?

Kitty Walker

24 Sept 2013

Consectetur adipiscing elit. Milan vel lorem eros.

Suspendisse pulvinar pretium urna, nec volutpat mi tempus sed. Aenean non sem odio.

Rewards The right answers - or the mostly voted answers - will be rewarded with smartmoney.

The reward mechanism is related to both peer and tourist feedback and it provides a quantity of smartmoney related to the peer-judged quality of the input. Badges can also be rewarded for each milestone. Smartmoney can be spent in tourism attractions, such as restaurants, shops and other relevant services, which further vitalize the local economy and bring more positive effect.

SmartSociety features • Sharing knowledge (WP1) • Incentives (WP5): virtual currency, badges and real coupons 2.2.2 Graphical Mini-scenario examples from other WPs In order to include and emphasise aspects of SmartSociety from the perspective of each Workpackage, WP9 asked other partners to examine the validated tourism scenario and to extract some concrete situations that exemplify their WP's concepts, in a way that is easily understandable by laypeople.

Each WP has been left free to provide material in any format, possibly including a description of the concept and some short narrative examples, highlighting constraints and motivations for each situation. After collecting the contribution, WP9 made them graphically attractive for the purpose of involving users.

2.2.2.1 Scenario 1: Smart Tour Guide Imagine to be a tourist and to have an innovative application for your smartphone that allows you to quickly find a real tour guide that suits you, in other words an expert who offers you a customized tour in the city where you are and together with other like-minded people, according to your profile and your interests... © SmartSociety Consortium 2013 - 2017

Page 13 of (40)

© SmartSociety Consortium 2013 - 2017

Deliverable D9.2

Smart Society Features: • Real-time positioning (WP3): Real time information can help business (e.g. restaurants) to coordinate with the tour guide, knowing if the current tour is in time and the tour guide as well can use real time information, such as weather conditions, congestion, etc., to skip or add point of interests to the itinerary and to catch the right moment.

• Peer profiling (WP4): the information provided by the users in their profiles is important to provide them good quality services by producing good matches and find good candidate peers to perform a task. Users specified such information in their “tourist profile” in order to receive personalized offers for tours.

• Incentives (WP5): tour guides are motivated by the ability to enjoy the tours they conduct, by money, meeting interesting people, getting positive feedback for their tours and learning from the people they meet.

2.2.2.2 Scenario 2: Smart Treasure Hunt Imagine to be a tourist and to have an innovative application for your smartphone that allows you to take part in a treasure hunt within the city, by suggesting the best places to visit according to your profile and your personal interests, and to win real prizes such as discount coupons for museums, exhibitions, restaurants, hotels, etc.

Page 14 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

SmartSociety Features: • Real-time positioning (WP3): Real time information, such as weather conditions, congestion, etc., are used by the Treasure Hunt app to skip or include point of interests to the game.

• Peer profiling (WP4): the information provided by the users in their tourist profiles is important to receive personalized suggestions from tourism apps about the points of interest to visit.

• Incentives (WP5): The opportunity to win real rewards, such as discounts coupons, motivates people to join tourism apps.

2.2.2.3 Scenario 3: Smart Q&A Game Imagine to be a tourist and to have an innovative application for your smartphone that allows you to quickly request and obtain information in real time with the help of local citizens who, through their experience, make their time and their knowledge available to the visitors during their tours...

© SmartSociety Consortium 2013 - 2017

Page 15 of (40)

© SmartSociety Consortium 2013 - 2017

Deliverable D9.2

SmartSociety Features: • Real-time positioning (WP3): Real time information are used by tourists to follow virtual guides suggestions, such as schedules, itineraries, At the same time, once users reach a specific point of interest, virtual guides can communicate with them providing the appropriate service, like useful information on the location or translation services.

• Peer profiling (WP4): Tourists profile information are used to connect with virtual guides with similar interests and suitable knowledge to provide needed information, in order to create a completely personalized experience • Incentives (WP5): virtual tour guides are motivated by the opportunity to be helpful to other people and by getting positive feedback for their knowledge.

2.2.2.4 Scenario 4: Smart Mobility Imagine to be a tourist and to have an innovative application for your smartphone, that recommends you the best itinerary from your current position to a point of interest, that cleverly combines public transport, car sharing, bike sharing and other services, and makes you reach also peripheral places, taking into account your user profile and preferences…

Page 16 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

SmartSociety Features: • Incentives (WP5): ridesharing drivers are motivated by getting positive feedback and badges. Passengers are motivated by reputation and environmental impact.

• Recommendation, planning and scheduling (WP6): intelligent recommender systems can identify ridesharing groups, combine this with public transport and a system of free city bikes to improve traveller mobility, avoid congestion, improve road and resource use.

2.2.2.5 Scenario 5: Optimizing transfers Imagine you have an application that helps you find local citizens who provide their private vehicle to take you to a place that you wish to visit and automatically coordinates the needs of different groups of tourists, in order to optimize time and travel expenses...

© SmartSociety Consortium 2013 - 2017

Page 17 of (40)

© SmartSociety Consortium 2013 - 2017

Deliverable D9.2

SmartSociety Features: • Recommendation, planning, scheduling, coordination, social orchestration (WP6): normal citizens and commercial guides with local knowledge can offer their services as private tour operators, opportunistically suggest tours for like-minded people (e.g. culture, nightlife, etc.).

2.3 User engagement events In order to validate the game environment design and receive feedback from different stakeholders involved in the tourism domain, we will participate in three events: • Games for a SmartSociety: this event will take place in Turin on 2nd of June, and is organized within the Smart City Weeks 2014 • OCOVA: the second event is organized in Genoa on the 5th of June, with the topic "Gamification for eHealth and SmartSociety".

• FoCAS SummerSchool: this event is organized in Heraklion (Crete), during the last week of June.

Two different approaches will be undertaken to carry out different user engagement activities, depending on the kind of event we will participate to. In particular, the first approach is suitable to public events, where stakeholders represent a generic and occasional audience. In such situation, the graphical scenarios (section 2.2.2) will be exposed and shown to raise people's curiosity. Interested people will be invited to throw a dice, whose faces represent symbols that remind to the graphical scenarios. Once they have matched the symbol with the corresponding scenario, they will receive a page describing the scenario situation and will be asked to write their opinion, in terms of what they would like and would not like about the described example of application on tourism.

Feedback will be then collected in a box.

In addition to the above-mentioned activity, there will be a desk where some mobile devices showing other material will be exposed, including the applications described in section 2.2.1.

The second approach will be chosen to carry out more focused activities, such as a workgroup with students. In this case, all the prepared material, described in the previous section, will be presented by a mentor and will be used to explain the tourism scenario more in depth, with the aim of doing Page 18 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

Š SmartSociety Consortium 2013 - 2017

an active work on WP9 prototype, such as introducing gamification aspects, producing new mockups, giving insights for the user interface, etc.

The first method was used in two events: the first one in Turin on 2nd of June, called "Games for a SmartSociety" and organized within the Smart City Weeks 2014, the second one in Genoa, called OCOVA with the topic "Gamification for eHealth and SmartSociety".

The second approach was exploited at the FoCAS SummerSchool in Heraklion, Crete, during the last week of June.

The results of the studies carried out during these events will be included in a future deliverable of WP9 and will affect the implementation of the virtual gamified environment, as well as of the tourism scenario and related use cases.

3 Design of the virtual gamified environment The virtual gamified environment will be a user-oriented application, the main aims of which are aggregating the functionalities developed by the technical WPs, allowing users of applications based on SmartSociety to easily interact with them and enhancing users’ motivation to participate through game elements.

The "gaming" aspect of the environment is represented by two main components: (i) a nonintegrated set of serious games accessible as services of the system, suitable to emphasize the intrinsic motivation, that is constituted by primary factors like enjoyment, challenge, curiosity, fantasy and sense of control; (ii) gamification elements, such as competition, rewards, etc., aimed at enhancing the extrinsic motivation, namely the achievement of external outcomes by the users.

The prototype of the virtual gamified environment will be developed for mobile devices as well as web application and through a graphical interface will allow users to access services in a customized way by exploiting the user profile information captured by WP4 and to enjoy this experience in a more intuitive and user friendly way, by leveraging on a mix of social dynamics, apps, serious games and game elements. Further, such gamification aspects will be a key component to be leveraged by WP5 in the design of specific incentive schemes that will be used to engage users.

The entry point to the gamified environment will be a graphical interface based on a front-end engine able to receive and sort user requests. This will then rely on a middleware platform, which will facilitate the interaction and consumption of the functionalities provided by the SmartSociety platform developed in WP8, and integrating the features provided by the various technical Workpackages.

In this chapter, the technical work around the virtual gamified environment prototype will be described. We will then elaborate how the virtual gamified environment can be applied to the tourism scenario, which is currently the being considered as the reference application for the validation of SmartSociety.

3.1 Game Environment Prototype design 3.1.1 Ego, SmartAdvisor, Alterego

Š SmartSociety Consortium 2013 - 2017

Page 19 of (40)

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

Figure1: Game environment architecture high-level view

Ego is the first component on top of the virtual gamified environment. Upon receiving a user request, Ego will select a specific SmartAdvisor to which sort the request, basing on the user profile currently in use (see section 3.1.2).

A SmartAdvisor (Ak in Figure1) is a component laying in the WP9 middleware, which has the function to process the user request, using the information of the current profile, and to call one or more peer services exposed by the SmartSociety platform.

The SmartAdvisor, once received a response by the peer services, will return the information to Ego, that in turn are sent to the user.

There is a unique relationship between a SmartAdvisor and a specific profile of a user.

As shown in Figure3, each SmartAdvisor may call N peer services and, in turn, a service can be associated with one or more SmartAdvisor. k

User requests to Ego can occur in two ways: • The user him/herself directly sends a request through a dedicated user interface of the virtual gamified environment • A user's "twin", called Alterego, basing on the current user profile and the history of the previous user's choices, simulates a request to Ego in place of the user.

Alterego is a user-simulator that operates as a “prompter” of user requests to Ego. When a circumstance or set some circumstances take place (such as a geographic position, a specific time, the proximity to a point of interest, etc.), namely an event occurs, a new simulated-user request is sent to Ego. The conditions triggering an event may change depending on user preferences and user previous choices. Hence Alterego will be constantly evolving as the user profile and the user history change.

Page 20 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

3.1.2 User Profile structure Each user can have a multi-profile structure; a main profile, called base profile, containing data that do not change (e.g. demographic data, psychological personality data, etc.) and of one or more extension-profiles (e-profiles) of the base profile that represent other user’s “faces”.

For example, local citizens automatically become tourists at the moment when they are going to visit another city. At the same time, they can offer professional services or belong to a group of people such as associations, companies, etc.

More concretely, consider the case of a 27-year-old guy living in London, as shown in the base profile in Figure 1. He also has two profiles that extend the base: one as tourist (Figure 2) and one as musician (Figure 3). He often uses different services when he moves from his city, basing his choice on the reason of his journey.

Since each of these user’s “faces” may have different needs and/or preferences, the e-profiles may include: • Additional fields (e.g. accommodation preferences for a tourist) [A in figure 2, 3, 4] • Overriding fields (e.g. transport preferences can change depending on his needs: in his city he prefer to move by his bike, but as tourist he prefers to use public transport, while as musician he needs a car to carry musical instruments…) [O in figure 2, 3, 4] • Variable fields (e.g. the current city) [V in figure 2, 3, 4] An e-profile can inherit or override base profile data, but it cannot in any way exploit data from another extension.

Base Field

Value

Type

Name

John Smith

Base

Age

27

Base

City

London

Base

Transport preferences

Bike

Base

Food preferences

Pizza, Rice, Mozzarella, Beef

Base

Food intolerances

Shellfish

Base

Interests

Theatre, Sport

Base

Figure 2: Example of Base profile Tourist Field

Value

Type

City

Berlin

V

Transport preferences

Car, Bike

O

Accommodation preferences

Hostel, Camping

A

Interests

Modern art, Nature

A

Figure 3: Example of e-profile - Tourist profile Musician Field © SmartSociety Consortium 2013 - 2017

Value

Type Page 21 of (40)

Deliverable D9.2

Š SmartSociety Consortium 2013 - 2017

City

Bristol

V

Transport preferences

Car

O

Accommodation preferences

Hotels, Apartments

A

Service category

Live Music

A

Figure 4: Example of e-profile - Musician profile

Figure 5: Schema illustrating the flow of a request by the user or by Alterego 3.1.3 Technologies The system architecture is designed following a RESTful approach, in which every actor exposes several public or protected web services which the EGO system can call in order to interact with Advisors and Services.

A generic message communication protocol is used to standardize the communications between the different parts of the system: the structure of the protocol is Actor - Verb - Object, in which Actor defines which part of the system is performing a request, Verb defines the type of request and is chosen from a limited list of options, and Object defines the details of the operation to be performed.

For example: EGO - SEARCH - HOTELS IN MILAN (Profile Tourism) In this example EGO asks to an Advisor to collect the hotels in Milan following the preferences specified in the Profile Tourism.

Message exchanges inside the game environment will be based on JSON and follow the Actor Verb - Object pattern. Appendix 6.1 reports an example of message exchange inside the game environment.

3.2 Tourism scenario implementation In order to come up with the design of an integrated gamified environment demonstrating the whole suite of technologies developed throughout the whole project, WP9 started from the requirements derived from the tourism scenario defined during Y1 and detailed in deliverable D9.1.

During the project, new functionalities for the system will be constantly identified, by carrying out different activities such as: • user studies Page 22 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2 • • •

© SmartSociety Consortium 2013 - 2017

intersection between tourism and other relevant domains validation of other scenarios WPs results collection

In the following, we will describe examples of use cases, with the purpose of concretely illustrating how they can be mapped to the game environment. We will extract the specific computation tasks that will be delivered to the SmartSociety platform. For the computation tasks, we distinguish between Human Computations (HC), which are computations to be performed by human peers, and Machine Computations (MC), which are computations to be performed by machines.

3.2.1 UC1: Touristic Attractions Recommender Description: this use case will provide a service to recommend Points Of Interests (POIs) to tourists visiting a given location. A POI can be any resource relevant for a tourist. Examples of POIs include restaurants, museums, wineries, etc. The recommendation will account for, e.g., user profile, user preferences, context such as weather conditions. User profile will be build over time based on historical actions of the users, as well as other information collected over time (e.g, social network activities).

Stakeholders: tourists, POIs managers, public transportation authorities, public administration User story: Amy, a young girl, has to meet a friend that lives in CAS city. Since she has to wait for his friend until evening and she hasn't been there before, she would like to spend her day visiting the city. She provides some information and general interests during the creation of her “tourist profile”. She also allows the SmartSociety platform to extract information from her social network activities to fill her profile. From her social network activities it is clear that she has an interest on music and culture, she also seems to be interested in some sports but not football in particular.

When she starts to plan her visit to CAS city, she excludes her interest on sports because as a tourist of CAS city she is not interested on sports related activities. She specifies that such information should be used with the purpose of suggesting personalized visits, itineraries and tours. This is useful to the system because it allows it to avoid places that are near the main square around the time of an important football match. Furthermore, she likes to travel alone and take information by herself about the places to visit, without the help of a tour guide.

Virtual gamified environment solution: Even if Amy did not specify in her profile to be a game player, in previous travels she often played gamified apps that allowed her to get discounts or free entries for museums and other attractions. Given these circumstances, Alterego automatically sends a new request to Ego, asking to find a game, available for CAS city, that gives the chance to win real rewards. Ego calls the "Tourism" SmartAdvisor, transmitting Amy's preferences from her tourism profile. After processing this request, the SmartAdvisor returns the best recommended app to Amy: the "treasure hunt game". This game allows her to play a real treasure hunt within the city, through which she can visit points of interest matching her profile and get real discount coupons.

Examples of computation tasks: • Get weather conditions in a given location [HC] • Get general info on resources (e.g., traffic congestion, queues at museums, etc.) info [MC+HC] • Get best attractions in a given location [HC] • Group buying for restaurant bookings [HC] 3.2.2 UC2: Recruit voluntary tourist guides Description: this use case will provide a service to find opportunities for (joint) activities, mobilise people, and balance resource usage assist people where manual computation would be infeasible. In © SmartSociety Consortium 2013 - 2017

Page 23 of (40)

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

each location there can be “local experts” on various touristic attractions, not necessarily conventional ones. Local experts with different interests can be identified on the fly when crowdsourcing real-time information or long-term knowledge about the city.

The users specified such information in their “tourist profile” in order to receive personalized offers for tours, the platform has guaranteed them that such information will be accessed only with that purpose. The information provided by the users to fill their profiles is important to provide them good quality services by producing good matches and find good candidate peers to perform a task.

As an example, normal citizens and commercial guides with local knowledge can offer their services as “private tour operators”, opportunistically suggest tours for like-minded people (e.g. culture, nightlife, sports, etc.) – system would help match supply and demand in real-time.

Stakeholders: citizens, tourists, restaurateur, food supplier, tour guides User story: Since tonight the final world cup football match will take place, Franco, a young tour guide, wants to organize a tour that includes visiting different points of interest in the city and ended with a dinner watching the football match. He therefore needs to find a group of people that are interested in football and are also like-minded, in order to give them the opportunity for socializing.

Fro this purpose, it would be nice also to collect people that are native from the nations involved in the match.

In the meanwhile, Miguel, a restaurant owner is planning to show the football match on widescreen television, in order to attract more people to his restaurant. He knows there will be a lot of business opportunity tonight and would like SmartSociety to help not only to manage bookings but also plan the menus, food supplies and cooking rotas to serve people quickly and efficiently with as near as full a restaurant as possible throughout the day. He is looking to SmartSociety to match tourist schedules and meal preferences to his restaurant.

Virtual gamified environment solution: Chris is an occasional visitor of CAS city, who has arrived one day before the work meeting. Since he has many hours to spend in the city, he wants to visit some attractions during the day. He did not specify any particular cultural interest, but in the base profile is clear that he loves football, meeting new friends and trying typical cuisine. Through the virtual gamified environment interface, he looks for a guided tour, preferably not expensive and not too much demanding, as he would like to watch the football match during the dinner. Ego calls the "Tourism" SmartAdvisor, transmitting his personal data and preferences, and it returns a list of guided tours. On top of the list, the best recommended tour is Franco's one. Chris is very happy with the tour because he meets other people traveling alone or in small groups; he enjoys the opportunity for eating local food in Miguel’s restaurant, watching the football match and socializing with other tourists that have similar interests. These information were specified in their profiles and were used to distinguish them as appropriate candidates to participate in the tour proposed by Franco.

Examples of computation tasks: • Recruit “local experts” on a given local resource [HC] • Find relevant events in a given location [MC + HC] • Get weather conditions in a given location [HC + MC] • Get general info on resources (e.g., traffic, queues at museums...) info [MC + HC] 3.2.3 UC3: SmartSociety answers Description: this use case will provide a Question & Answers service, which will support in realtime tourists visiting a given city. Tourists will have the possibility to create questions that will be dispatched to the most appropriate citizens to answer. Such questions will be answered in real-time, when human computations resources are available. Such service will augment a local knowledge Page 24 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

base that will be used to refine the overall touristic service and offering. In particular, it will be possible to map and analyse the most recurrent questions by tourists, and pro-actively create adequate services and personalized support.

Stakeholders: citizens, tourists, territorial marketing agencies User story: Maria, a native citizen of CAS city, has a lot of time available because she is retired, but she cannot be a tour guide (like Franco) because she has some mobility limitations. She creates her profile in the SmartSociety system as a virtual guide or tourist advisor. In her profile she specifies: (i) that she was born in CAS city and that she lives there (i.e., she is a local citizen of CAS city); (ii) her interests as a guide, which in this case are local music, dances, history and cuisine, and that represent the topics about which she can offer advice; (iii) she also specifies the method of communication to provide tourists with information (e.g., Q&A game, instant messaging, chat, etc.); and (iv) the languages in which she can communicate with tourists (i.e., languages she speaks and writes).

Virtual gamified environment solution: Peter and Rosalind are visiting the city without a tour guide. They want to use the Q&A service to get some information regarding specific attractions.

Through the central interface of the virtual gamified environment of Peter's device, they send a request to Ego using the TouristCouple profile, where Peter previously inserted a mix of his preferences and Rosalinda's preferences. Ego calls the service through the TourismCouple SmartAdvisor. These information allow the system to connect Maria with Peter and Rosalind, instead of connecting her with other tourists that require a guide that can physically accompany them during their visit.

Examples of computation tasks: • Question on touristic resource or attraction [HC]

4 Integration with the SmartSociety platform This section details how Ego and SmartAdvisors, as described in the previous section, interact and integrate with the SmartSociety platform currently being developed in WP8.

We start the section by presenting a brief update on the initial design of the SmartSociety platform described in D8.1. This includes a high level overview of how the platform will be utilized by developers willing to create applications based on SmartSociety, including a revised description of the APIs that the programming framework will offer to developer to run human computations tasks.

Further, we will provide a description of the steps that developers will need to undergo when developing a new application on top of the SmartSociety platform.

We will then move into an illustrative use case taken from the tourism scenario that will be used to describe the process underpinning a computation task that a SmartAdvisor can issue to the SmartSociety platform. This will include a description oh how such request will be mapped into some internal components offered by the platform.

4.1 SmartSociety platform design review The SmartSociety platform will be seen as a service to be used by developers for creating applications involving human computations tasks, machine computation ones and a combination thereof.

In terms of the system-level functionalities offered by the platform, the most relevant ones from the point of view of integration of Ego and SmartAdvisors will be the following ones: • Model computations tasks: a computation task can fully described according to the models developed in WP1. This will include human, machine and hybrid computations tasks. A model will include all the necessary meta-information for letting the SmartSociety platform execute such task. © SmartSociety Consortium 2013 - 2017

Page 25 of (40)

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

•

•

Register or unregister peers: in order to let the SmartSociety platform interact with specific peers, they need to be registered into the platform. The peers will provide what is called in Fig. a peer service – a specific functionality that applications can rely on to carry out specific computation tasks. A peer can be: o Human: In this case, when registering a peer, the necessary privacy information will be requested and will specify how to deal with personal data. o Machine: in this case, the peer provides a given service or computation facility. The peer profile includes an end-point for calling it. Examples of machine peers include servers accessible through a SmartSociety wrapper, as well as services modelled as a SmartSociety peer.

Register additional components: through specific APIs it will be possible for programmers to register additional components or information, which will then be needed to properly execute the program. Examples include: o Incentive schemes: specific incentive schemes can be dynamically registered to the platform. This will include the necessary resources, messaging support and UIs required for making them actionable. o Interaction models: specific interaction models for forming collectives, or for interacting with existing ones can be introduced by developers. Such models will provide the necessary messaging support and interaction models for running them. o Knowledge: specific knowledge for certain application domains can be introduced by developers. The newly introduced knowledge can be confined to the application itself of shared across different applications and services. o User applications, etc.

SmartSociety Components!

Developers!

Developers Application!

SmartSociety!

Program!

User Application!

Smart Society !

Platform!

Peer Application!

Sw Lib!

Collective!

Application!

Collective!

Application!

Figure 1: SmartSociety platform: high-level view.

In Figure 1 we report the (generic) high level view of how the SmartSociety platform will be utilized by a developer for creating and executing an application. In the case of the virtual gamified environment subject of the deliverable at hand the relevant components are highlighted in blue. The Page 26 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

components coloured in grey will be provided by the platform or, simplifying, will be provided by WP8.

In general terms, a SmartSociety application will be based on the following components: • SmartSociety Program: a program that models the computational tasks (and their interactions) to be executed by the SmartSociety platform. A SmartSociety program includes the appropriate meta-information for modelling a task, delivering it to SmartSociety through the APIs exposed by the platform and monitoring its execution status. Eventually, it will receive the final outcomes of the computation that will be sent to the application build on top of SmartSociety. The computational tasks foreseen by the program are modelled according to the models devised in WP1, and will be based on specific description language used by the Programming Framework developed in WP7.

• User Application: this application can be used to facilitate specific interactions between peers and the SmartSociety platform, offering, e.g., human-friendly UIs to interact with. As an example, a human computation task can be delivered via a mobile application provided by the developer and that is in charge of the actual integration with SmartSociety. Through the mobile application the human peer receives a task (e.g., a questionnaire or the request for a rideshare) and can participate. The same application can also be used to register or unregister peers to SmartSociety. In particular, the peer application provides the necessary UIs for interacting with peers, and can leverage specific SmartSociety software libraries (e.g., for handling personal data according to specific privacy policies, etc.) for interacting with the platform. During the initialization phase, such application gets registered into SmartSociety and is then able to interact with the SmartSociety platform for letting users receive and compute specific tasks. Applications can be mobile, social, web.

Conversely, the SmartSociety platform will provide the following components: • Platform: this represents the core of the SmartSociety platform and will implement all the main functionalities developed in the project. This includes the orchestration and execution of a given task, the management of peers, the creation and maintenance of a knowledge base, the specification and enforcement of specific privacy policies and incentive schemes. etc. All such functionalities will be exposed to developers through a set of open APIs that they can invoke for issuing, monitoring and obtaining results from a computational task. In addition, the platform will feature APIs for accessing content and information stored within the platform itself. As an example, developers might need to query the knowledge base for verifying the presence of a given entity, and in case downloading the corresponding description.

• Software libraries: these libraries will facilitate the development of applications based on SmartSociety. In particular, they will allow developers to easily integrate mobile applications, sensors or any other device into SmartSociety. When integrated such device will become a SmartSociety peer (or collective), taking part to computations, notifying specific status and surrounding context. Such libraries could support the visualization of specific SmartSociety widgets, as an example in the case of a given incentive schemes.

• Peer Applications: one or more optional applications meant to provide an environment for the workers (human peers)/external services to interact with the SmartSociety platform.

Their usage is not mandatory; the platform will be able to interact with individual peers and collectives also through existing, well-known, third party communication and collaboration tools (e.g., twitter, email, Dropbox etc.).

The virtual gamified environment will rely on these functionalities in order to both integrate peers computations into SmartSociety, as well as to consume the various services provided by SmartSociety. From an abstract viewpoint, to the platform the Ego and the SmartAdvisors will appear as some of the many potential programs running on top of the SmartSociety platform. © SmartSociety Consortium 2013 - 2017

Page 27 of (40)

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

4.1.1 SmartSociety Programming Framework and APIs The SmartSociety platform will provide a set of public APIs that will be used by WP9 for deploying and running the virtual gamified environment (or more in general any third-party application) on top of SmartSociety platform. Some of them will be used at run-time, while others will be used during the deployment phase of the application.

As an example, the deployment over SmartSociety of specific incentive mechanisms or privacy policies required by the Ego and SmartAdvisor applications, will occur during the initial set-up phase. Similarly, the registration and integration of a mobile application for interacting with peers will be implemented during the initialization phase of the platform. Conversely, at run-time the virtual gamified environment (and related components such as, e.g., a mobile application) will be using the SmartSociety APIs for delivering computation tasks and gathering the results from peers.

Peers are also used to wrap the APIs of an external, third party service APIs. In this case, the peer can be used to retrieve information on, e.g., weather conditions in Trento.

4.1.1.1 Initialization During the initialization phase of the program, the virtual gamified environment will perform the following operations: • Peers Registration. In this optional step, peers can get registered into the platform. Peers can be humans, as well as machines. In the case of humans, peers can be registered into the platform in bulk mode, e.g., when originating from a pre-existing user base. As an example, in the case of an application already managing a user base, such user base can be pushed to SmartSociety, clearly only if the specific requirements in terms of users privacy are met. In this case, each user gets registered into the platform with a variable set of information, which varies depending on the privacy preferences expressed by the user when registering in the application. Additional human peers can be then added at runtime.

Init.!

• • • • •

Privacy policies registration!

Incentive schemes registration!

Mobile application integration!

Peers profile model loading!

[Peers registration]!

Run-time!

• Task computations!

• Monitoring!

Figure 2: Consecutive phases traversed by a SmartSociety application.

In the case of machines, peers will be loaded together with the specification of the endpoint to interact with them. This could include, as an example, the case of a specific service being called then at run-time by the program. Such service could provide the access to certain APIs or functionalities such as, e.g., TripAdvisor recommendations or weather information service.

Page 28 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

•

•

© SmartSociety Consortium 2013 - 2017

Incentive Scheme Registration. In this case, specific incentive schemes can be loaded into the system. An incentive scheme will include all the necessary information for (i) running an incentive scheme, including the necessary UX components (e.g., in the case of a persuasivebased incentive scheme) (ii) storing the necessary information for modelling the peers running such incentive schemes (iii) specific messaging to be handled at run-time (iv) any additional information that might be required.

Models registration. Specific models which are not yet present in the Knowledge Base can be registered during this initial set-up phase. Such models could potentially be made available also to other applications working in a similar domain. As example, if a model of the tourism domain is not present in SmartSociety, an application could register it and make it available in the future to other developers willing to develop tourism-based applications based on top of SmartSociety.

The following APIs are provided in order to support such functionalities4: public registerPeer(PeerProfile) This API will be used in order to register new peers into the SmartSociety platform. The PeerProfile will contain all the necessary information for registering the peer into the platform and let the platform interact with it at run time. This includes privacy settings, as well as an endpoint, including the specific communication tools, to be used to deliver a computation task to the peer. public registerIncentiveScheme(IncentiveModel) This API will be used to register an incentive scheme into the platform. The IncentiveModel will contain a model of all the necessary resources for executing such incentive scheme at runtime. public registerPrivacyPolicy(PrivacyPolicyModel) This API will be used to register a privacy policy scheme into the platform. The PrivacyPolicyModel will contain all a model of all the necessary resources for enforcing such privacy policy at runtime.

4.1.1.2 Runtime The following APIs are expected to be used by the virtual gamified environment for implementing SmartSociety application scenario: TaskHandler public doTask(taskModel, callBackModel) This API will provide the main interface for running SmartSociety computations. In particular, it will receive • taskModel, which includes all the necessary meta-information for modelling a task, including functional and non non-functional properties. A TaskHandler object will be returned by the API and will contain all the necessary information for (i) monitoring the progress of the task, (ii) receive the final outcomes of the computation.

• callBackModel: this is an optional parameter, which will specify the desired call back model for receiving notification updates from SmartSociety during the execution of a given 4

This is an initial set of APIs. The final definition is currently under definition together of the respective WPs and will be included in Deliverable D8.2 at M24. © SmartSociety Consortium 2013 - 2017 Page 29 of (40)

© SmartSociety Consortium 2013 - 2017

Deliverable D9.2

computation task. Callbacks can occur, e.g., at the completion of a given step in the task, as well as when there is an update on its progress. Examples of call back technologies include a REST, Websockets, MQTT, etc. public getTaskStatus(taskHandler) This API will be used by applications to monitor at run-time the status of running tasks. This method will receive as input a taskHandler, which will be used to access any information related to a certain task. This status information includes: • the outcome of the task execution; • the specific status of the Task (e.g., RUNNING, COMPLETED, etc.); • status messages.

4.2 Illustrative Example In the following section, we will elaborate a specific use case that will be implemented within the Tourism scenario. The use case will run inside the virtual gamified environment developed in WP9, and utilize the SmartSociety platform for executing specific computation tasks and/or programs.

This integrates in a single picture some of the use cases presented above in Sec. 3.2 and in particular UC1 and UC3.

The example is intentionally very simple, and it is intended: • To illustrate the interactions between the SmartSociety platform and a third-party application running on top of it; • To show how a simple problem can be resolved in many different ways by SmartSociety, with potentially very different results.

Use Case Description: Alice will be in Milano next week. It is her first time in Milan, and she is looking for a good restaurant in the city centre. Since it is spring time, she would love to eat outside, and therefore find a restaurant with a garden. Alice is also celiac, and she needs to find restaurants, which offer gluten-free menus. She relies on the SmartTourism application for retrieving advice on the best places to dine out in Milano, based on her preferences and constraints.

As she is an adventurous traveller, she also would like to go for something off the beaten track.

The SmartTourism Application (SMA) runs on top of SmartSociety, and relies on its functionalities for interacting with peers in order to accomplish specific tasks. During the initialization phase, the SMA registers some of the peers that it will be using at runtime. As an example, it registers a peer which provides a wrapper to TripAdvisor, and one which integrates Yelp info service. Similarly, it specifies the privacy policy that will be applied to all the data which is provided by human peers when interacting with the application for, e.g., providing recommendations. The privileged interface for accessing the service is a mobile application, which provides all the SMA functionalities, including some gamification elements which are used to engage users and ensure an interactive participation not necessarily related to the provided services only. As an example, by providing feedback or recommendations, users will receive credits that can be used to redeem vouchers in bars or restaurants partners of the SMA. In particular, Alice is running the SMA iPhone mobile app. The mobile app features a section for locating restaurants, bars, boutiques, means of transport, touristic sites, etc. She selects the section on restaurants, and the GUI allows her to compose her query in a way that later the SmartSociety program (to which the user app will pass the task) will know how to interpret. In this particular case, the task description should have a geographical constraint (e.g., ‘Milano city center’), a timing constraint (‘next week’), the query variable is a restaurant, and its attributes are gluten-free and garden.

Page 30 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

Š SmartSociety Consortium 2013 - 2017

The request is translated by the SMA into the following description: Task Request: Find restaurants in Milan for next week, which are gluten-free and with a garden.

The task is delivered to SmartSociety through the doTask() API. In particular, the task will be translated into an appropriate taskModel, which specifies the associated meta-description necessary for the SmartSociety platform to transform it into an executable program. SMA will then wait for a call-back after the completion of the task execution, and it can also monitor the progress of the task through the getTaskStatus().

5

The task is then translated into a Workflow by the Task Execution Engine (WP7). The workflow is then delivered to the Coordination and Orchestration (WP6) in order to retrieve possible execution plans. Such plans account for constraints such as, e.g., availability of resources, non-functional properties (e.g., time to receive an answer), quality-of-service etc.

An example of the workflow is reported in the following figure. The Workflow models the functional execution of the specified computation task. In particular, it is based on the following steps: 1. Find the restaurants in Milan: this step retrieves a list of restaurants in the centre of Milan.

This can be based on some external service such as a registry of existing restaurants provided a machine peer (e.g., TripAdvisor or other yellow pages services) or human peers (e.g., crowdsourcing such information by asking people living in Milan to indicate a series of restaurants nearby).

2. Retrieve additional info on each one of the restaurants found from step 1. Such information includes, e.g., a general description of the restaurant, the availability of outdoor tables, whether they also have gluten-free dishes, the address and phone number, etc.

3. Filter gluten-free: this is an operation, which is executed on the result-set of the previous step of the workflow. In particular, starting from the list of restaurants, it filters out those that do not have gluten-free menus. As it does not require interaction with external peers, this step is executed directly by the Coordination and Orchestration.

4. Weather info: this task is in charge of retrieving the weather information for Milan during the next week. This is relevant for evaluating whether the availability of garden is to be considered a hard constraint when ranking the restaurants. This step can also be executed via machine peers (e.g., weather service) or through human peers when in real-time (crowdsourcing such information).

5. Filter garden: this is an operation, which is executed on the result-set of the step1 and the information retrieved from step 2. Further, this step consumes the weather information for the next week. In particular, in case of good weather, it filters out those restaurants that do not have a garden. As it does not require interaction with external peers, also this step is executed directly by the Coordination and Orchestration.

6. Recommend: this task will ask to human peers for a recommendation for those restaurants resulting form the previous execution step of the workflow. Though some form of interaction with peers (e.g., mobile application, social application, email, etc.) human peers are asked to provide their opinion for each one the restaurants identified in the previous step.

Ratings provided may be weighted e.g., on the basis of the peer reputation or on the similarity between the profile or Alice and that of the peer providing a recommendation.

5

Currently it is under discussion by WP6/7/8 whether a workflow is the most appropriate representation of the computing Task. For simplicity, we will utilize the notion of workflow, although this might be refined in the M24 release of the architecture (D8.2). Š SmartSociety Consortium 2013 - 2017 Page 31 of (40)

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

Workflow!

1. Find Restaurants! in Milan!

4. Weather! next week!

2. Find Restaurants! information!

• • • •

5. Filter:!

With garden!

3. Filter:!

Glutin-Free!

Restaurant 1!

Restaurant 2!

Restaurant 3! …….!

6. Recomm.!

Figure 3: Workflow representation of the Task Request.

As it is possible to observe, such workflow can be executed through different execution plans, in which each step can choose to use different resources and peers. Starting from such workflow, the Orchestration and Coordination Manager will devise different execution plans, which represent possible instances of such workflow. When devising such execution plans, the Coordination and Orchestration manager will interact with the Peer Manager in order to retrieve the details of the peers to be involved in the execution. Each peer will be searched based on the specification of the various steps of the workflow. At the end of this phase, different possible executions will be returned to the Task Execution Engine.

An example of two possible execution plans is reported in the following figures:

Page 32 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

Execution Plan 1!

4. PEER:!

IlMeteo.it!

1. PEER:!

Trip!

Advisor!

2. PEER:!

Restaurant!

Info!

• • • •

3. FILTER:!

5. FILTER:!

Gluten-Free! !

With garden! !

Restaurant 1!

Restaurant 2!

Restaurant 3! …….!

6. PEERS:!

Recomm.!

Figure 4: Execution plan 1

In the first execution plan, the TripAdvisor 6 peer is used to retrieve the initial list of restaurants in Milan. For each restaurant, the complete information is retrieved in step 2 by accessing an open repository of restaurant information. This information includes also the availability of a gluten-free menu, and a garden.

This initial list is filtered for retrieving gluten-free only restaurants.

In order to find the weather conditions in Milan next week, the Meteo.it 7 peer is utilized. This provides the weather forecasts for the coming 7 days. If weather is good, the Filter with garden operation will return only those restaurants with a garden.

Finally, the obtained list is delivered to human peers for receiving a recommendation on such restaurants.

Execution Plan 2!

4. PEER:! metwit!

1. PEER:!

Trip!

Advisor!

2. PEER:!

Restaurant!

Info!

• • • •

3. FILTER:!

5. FILTER:!

Gluten-Free! !

With garden! !

Restaurant 1!

Restaurant 2!

Restaurant 3! …….!

6. PEERS:!

Recomm.!

Figure 5: Execution plan 2.

6

http://www.tripadvisor.com http://www.meteo.it © SmartSociety Consortium 2013 - 2017 7

Page 33 of (40)

© SmartSociety Consortium 2013 - 2017

Deliverable D9.2

A second execution plan foresees (i) the utilization of a different restaurant registry (Yelp), (ii) to crowd-source from human peers the information about specific restaurants which are not yet present in Yelp and (iii) the utilization of a crowd-source weather info service (metwit).

It is worth noticing that both execution plans will lead to the execution of the initial task - Find restaurants in Milan for next week, which are gluten-free and with a garden. However, depending on specific constraints (e.g., the costs associated to the use of the TripAdvisor or Yelp Peer service), the coordination & orchestration may decide to privilege one with respect to the other.

Once such execution plans are ranked by WP6 according to a criteria specified by the developer (e.g., budget), the Task Coordination and Execution manager will start executing them. In doing this, it will utilize the communication framework for interacting with peers. In particular, delivering messages through various communication channels, and progressing on the execution of the plan until the execution is completed or a stop condition is encountered. A possible end of a given plan is also deadlock situation, which requires a possible re-planning. As an example, if it is not possible to crowd-source certain information from peers, the Task Coordination and Execution manager can decide to stop the current execution of a plan, use another one instead or go back to the Coordination and Orchestration for a complete re-planning of the computation task.

To summarize, in this section we have reviewed some of the SmartSociety platform components initially presented in D8.1. In particular, we have illustrated how the game environment that will be developed in WP9 for validating the SmartSociety concept, will be running on top of the SmartSociety platform. We have elaborated in detail how the specific request for a restaurant search is handled by the platform, before returning the final results to the requesting SmartAdvisor. In particular, the explanatory use case showcase the ability of the SmartSociety platform to dynamically compose hybrid computation tasks which are able to: • Involve both human and machine computations • Identify multiple possible execution plans able to carry out the specified computation • Take into account the specific constraints imposed by the requesting SmartAdvisor The revised architectural view will be consolidated and presented in D8.2, together with the initial implementation of the SmartSociety platform.

5 Next Steps This deliverable is intended to give an high-level view of the virtual gamified environment, both in terms of activities undertaken with WP1 to shape its concept and its functionalities and in terms of technical specification and integration with the WP8 platform. Therefore the current document will be constantly evolved as new project results will be reached and other WP9 tasks will be carried out. The first version of the prototype of the virtual gamified environment will be released in M30 together with D9.3, whereas the final version will be released in M48 with D9.4.

The previous activities were based on the tourism scenario, since currently it is the one to be validated with stakeholders. In the next project phase, a scenario on care domain, namely the CareCAS scenario, will be similarly validated. A new collection of requirements will be derived from this second scenario and merged with the already existing one. This process will allow WP9 to identify and add new functionalities to the prototype and then to evolve the virtual gamified environment.

Furthermore WP9 is analysing feedback and insights collected from stakeholders during the events mentioned in section 2.3. These results will be used to add new elements and to come up with a valid prototype.

Page 34 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

Š SmartSociety Consortium 2013 - 2017

We also introduced an initial integration of the virtual gamified environment with the SmartSociety platform that will be developed by WP8. In the coming months, the APIs and related components will be revised according to the output of the WP7 and WP6. A first prototype of the SmartSociety platform will be released at M24.

Š SmartSociety Consortium 2013 - 2017

Page 35 of (40)

© SmartSociety Consortium 2013 - 2017

Deliverable D9.2

References • • • •

Ruairí Brugha and Zsuzsa Varvasovszky. Stakeholder analysis: a review Health Policy Plan.

(2000) 15 (3): 239-246 doi:10.1093/heapol/15.3.239 Andrea Cornwall. Unpacking ‘Participation’: models, meanings and practices Community Dev J (2008) 43 (3): 269-283 first published online June 5, 2008 doi:10.1093/cdj/bsn010 Ulrike Felt and Maximilian Fochler. Machineries for Making Publics: Inscribing and Describing Publics in Public Engagement, Minerva (2010) 48 (3): 219-238 Gene Rowe, Tom Horlick-Jones, John Walls, Wouter Poortinga and Nick F. Pidgeon. Analysis of a normative framework for evaluating public engagement exercises: reliability, validity and limitations. Public Understand. Sci. (2008) 17 (4) 419–441

Page 36 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

© SmartSociety Consortium 2013 - 2017

6 Appendixes 6.1 Messages Exchange example in the Game environment platform Message exchanges in the game environment will be based on JSON and follow an Actor - Verb Object pattern. Some examples of a massage exchange in the context of a tourism application scenario are reported in the following:

//USER->EGO { "actor":{ "who":"User", "id":"123" }, "verb":"search", "object":{ "what":"Trip in Milan", "when":"Now", "profile":"Tourist" } } //EGO->TOURISM_ADVISOR { "actor":{ "name":"Ego" }, "verb":"search", "object":{ "what":"Trip", "where":"Milan", "when":"Now", "who":{ "profile":{ "id":"123"... } } } } //TOURISM_ADVISOR->ACCOMODATION_SERVICE { "actor":{ "name":"Tourism_Advisor" }, "verb":"search", "object":{ "what":"Bed&Breakfast+Hostels", "where":"Milan", "when":"Now" } } //TOURISM_ADVISOR->CARRENTAL_SERVICE { "actor":{ "name":"Tourism_Advisor" }, "verb":"search", "object":{ "what":"Small cars", "where":"Milan", "when":"Now" } } //TOURISM_ADVISOR->RESTAURANT_SERVICE { "actor":{ "name":"Tourism_Advisor"

© SmartSociety Consortium 2013 - 2017

Page 37 of (40)

Š SmartSociety Consortium 2013 - 2017

Deliverable D9.2

}, "verb":"search", "object":{ "what":"Kebab restaurant", "where":"Milan", "when":"Now" } } //RESTAURANT_SERVICE->TOURISM_ADVISOR { "actor":{ "name":"Restaurant_Service" }, "verb":"prompt", "object":{ "result":{ [ { "id":"456", "name":"Meydan Kebab", "address":"Via Pergolesi 45", "opening_time":"24h/7" } ] }, "open_with":{ "mobile":"RestaurantApp", "mobile_web":"m.restaurantapp.com", "web":"www.restaurantapp.com" } } } //CARRENTAL_SERVICE->TOURISM_ADVISOR { "actor":{ "name":"CarRental_Service" }, "verb":"prompt", "object":{ "result":{ [ { "id":"789", "name":"Fiat Panda", "address":"Via Macchi 50", "opening_time":"24h/7", "provider":"Hertz" } ] }, "open_with":{ "mobile":"HertzApp", "mobile_web":"m.hertz.com", "web":"www.hertz.com" } } } //ACCOMODATION_SERVICE->TOURISM_ADVISOR { "actor":{ "name":"Accomodation_Service" }, "verb":"prompt", "object":{ "result":{

Page 38 of (40)

http://www.smart-society-project.eu/

Deliverable D9.2

Š SmartSociety Consortium 2013 - 2017 [ { "id":"345", "name":"B&B Splendor", "address":"Via Macchi 52", "opening_time":"24h/7", "room_type":"single" } ]

}, "open_with":{ "mobile":"BookingApp", "mobile_web":"m.booking.com", "web":"www.booking.com" } } } //TOURISM_ADVISOR->EGO { "actor":{ "name":"Tourism_Advisor" }, "verb":"prompt", "object":{ "result":[ { "booking":[ { "id":"345", "name":"B&B Splendor", "address":"Via Macchi 52", "opening_time":"24h/7", "room_type":"single" } ], "open_with":{ "mobile":"BookingApp", "mobile_web":"m.booking.com", "web":"www.booking.com" } }, { "hertz":[ { "id":"789", "name":"Fiat Panda", "address":"Via Macchi 50", "opening_time":"24h/7", "provider":"Hertz" } ], "open_with":{ "mobile":"HertzApp", "mobile_web":"m.hertz.com", "web":"www.hertz.com" } }, { "restaurant":[ { "id":"456", "name":"Meydan Kebab", "address":"Via Pergolesi 45", "opening_time":"24h/7"

Š SmartSociety Consortium 2013 - 2017

Page 39 of (40)

Deliverable D9.2

Š SmartSociety Consortium 2013 - 2017 } ], "open_with":{ "mobile":"RestaurantApp", "mobile_web":"m.restaurantapp.com", "web":"www.restaurantapp.com" } } ] } }

Page 40 of (40)

http://www.smart-society-project.eu/