Context and Objective

The aim of the project is to design and develop a mulit-agent based virtual community management platform for sharing of information within a smart city. The city is equipped with community servers situated in places or buildings of the city.

Inhabitants of such smart cities are provided with a smart device that contains a community assistant that acts under his/her control. They delegate to this community assistant the management of the sharing of information according to the topics that he/she is interested in and to the information he/she is ready to share with other users.

Community

A community is a a ephemera, short term or long term grouping of members who wants to share information or participate to a decision. It is created by inhabitants of the city or by any city service and can propose one of the following services:

  • a sharing information service, with a storage limit fixed by the owner (i.e. max number of messages), with a duration time fixed also by the owner, period after which messages are forgotten, with a sharing information mechanism:

    • Mailbox Community type : each member of the community has the possibility to post a message for an other member of the community one has to be registered in this community in order to send a message as long as one is member of the community, he will automatically receive message that are sent to him

    • Forum: each member of the community can post or read news

    • Moderated Forum: each member of the community can post or read news. News are sent only after being moderated by the owner of this community (the owner is the one who created this community)

    • Twitter Like: only the owner of the community (i.e. the one who created it) can send news. The community members receive news that are posted by the owner.

  • a direct democracy service, with a "Voting" procedure on a given topic (see: http://www.doc.ic.ac.uk/~mjs/publications/aamas05pitt.pdf, or http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.96.1893&rep=rep1&type=pdf)

Community server

A community server may host several communities. It runs on dedicated computing resources and manages several communities. It is associated to a physical area defined by geographical coordinates (for instance a circle around the server). For instance, it can be situated:

  • In a museum where it can host a community for the management of people who visited that museum, a kind of "livre d’or", a community for the management of people interested in a certain topic, agreeing to let their moves in the museum to be logged on and used for extracting the best visit trail in the museum …​

  • In a pub, where it can host a community for the management of people interested in sharing information on kinds of beer, a community for the management of people interested in the history of the place, etc

  • In a given place of the city, where it can host a community for enabling citizens to push information related to the improvement of the friendship in that place, a community for citizens to push information to the city services to signal them places to improve, to repair, etc

It offers several functionalities (see below) that are available only to users situated in a given neighbourhood of the server (i.e. a certain distance, community area). A user situated in the right area can interact with the community server and create a community, join a community, publish information in the community, get information from the community, etc. Actions are not feasible when the user leaves the area.

The management of a community consists in receiving and processing the actions received from the community assistants:

  • Creation of a community (resp. Deletion of a community): a community assistant creates a community by choosing the type of community and assigning it a given topic that is part of the "ontology" shared by the community assistants. The creator of the community becomes the owner of it. Only and only the owner can delete a community. This can be done only and only when there are no more members into the community.

  • Entering a community (resp. Exiting a community): any community assistant applies to the owner for getting the membership to his/her community. When application is accepted, the community assistant becomes a member of the community. A community assistant can belong to several communities. A member of a community can leave the community at any time as soon as he/she has satisfied the conditions for leaving.

  • Consulting Communities by topics: the list of existing communities (repository) is made accessible to the community assistants as soon as they are in the neighbourhood of the community.

According to the type of community, community assistants can post/read messages (information), vote (take part to decision). The messages are related to different community topics.

Community Assistants

A Community Assistant supports the user in the management of his/her digital life in the communities hosted by community servers. It will help his/her owner in the creation/deletion of communities, posting/reading of messages according to his/her preferences. Preferences may consist in particular topics, in posting behaviours as follows:

  • versatile-egocentric: his/her interest in participating to a community is changing quite often. Each time his/her interest changes, he/she leaves the community. If he/she is owning a community he/she warns the members and delete it.

  • copy-and-paste: each time a new community has been created, he/she registers in it, create a similar community on his/her own and copy any message posted in the community and post it in his/her community.

  • let your imagination work

Work to realise

Based on the above problem description, each group has to define and develop:

  • a vocabulary of topics and terms that will be used for sharing of information, defining the topics of vote,

  • set of community types (at least 2 per member of the group),

  • community server for hosting communities (offers creation, deletion, management of communities, we don’t take into account the location of the community server and the distance to it for accessing its services)

  • community assistant with a management strategy (at least 2 community assistants per member of the group)

  • a demonstrative use case where users, assisted by their community assistant manage communities on the existing community servers and share informations and take part to decisions.

Implementation will be realised using the JaCaMo Platform. The Android JaCaMo version can also be used for the development of Community Assistants on smartphones.

Community assistants will be implemented as Jason Agents. They will include different plans to create, join, leave, delete communities, to publish informations in the communities.

Each community will be implemented as Artifacts from the Cartago platform.

The behaviour and regulation of the community can be made explicit by using an organisational specification based on the MOISE platform.

The community server will be implemented as a workspace where the community artifacts will be executed.