VGI frameworks are applications that address the problem of “allowing users (generally in the role of administrators) to produce VGI applications that other users (generally in the role of volunteers) are able to contribute with geographic information and be rewarded and recognized by their work”. ThemeRise encapsulates a set of structures considered relevant to produce an entire VGI application as a unit called Theme. In practice, a theme represents a phenomenon of interest about which there is the need to collect geographic information through volunteers. ThemeRise includes, as relevant structures, the instruments that allow collecting contributions, involving a geometric shape as spatial representation, descriptive attributes about the phenomenon of interest, and the user’s reward and reputation system. The main advantage of this strategy is the ability to control each of these structures independently for each theme, a task that can be handled over to administrators in the moment of theme creation. This control adds a new level of refinement to VGI applications, allowing a diverse group of interdisciplinary administrators to combine all their themes and share volunteers in the scope of one application, using meaningful structures independently for each theme. Also, since user reputation is linked to the theme, it is possible to avoid scenarios where the rewards of different themes are considered to be the same, when in reality user contribution frequency and quality varies according to the user’s relationship to each theme. For instance, contributions related to ephemeral events, such as noise pollution, are very different from contributions to persistent themes, such as map updates.
During the process of developing the framework, a set of requirements was defined and an architecture was designed considering an evaluation of tools that could be used to implement the whole application. The requirements were divided into functional and non-functional, where the functional ones describe the desired features and the non-functional ones described constraints for the implementation of features. The requirements for the development of the framework are described next, followed by an exploration of ThemeRise’s architecture.
Requirements
Summarizing the problem that VGI frameworks address, the functional requirements were defined in terms of user identification and roles, theme creation, user evaluation and geographic contribution. Each of these sets of requirements will be presented next.
We consider two kinds of users: administrators, which are able to use the framework to create VGI applications (themes), and volunteers, which are able to perform contributions. Additionally, volunteers can be anonymous, which in some cases can encourage people to more securely contribute about sensitive themes. Hence, the application must implement these two roles for identified users (administrator and identified volunteer), and should allow the administrator to choose if a theme can receive anonymous contributions. Anonymity must be defined for each theme, since some themes may require different kinds of user profiles and permissions to accept contributions. Unlike identified volunteers, anonymous volunteers cannot receive rewards, and therefore do not have a reputation score.
In ThemeRise, only administrators are able to create new themes. In the process of creating a new theme, themes are identified by name and description. As said before, contribution instruments should be selected and customized as part of theme creation. Administrators must be able to define a form for volunteers to fill out when they perform a contribution on the theme. In the form, along with descriptive fields, the administrators will also define which data types will be used to store the information collected in an underlying DBMS, along with the geographic representation. The framework should allow the administrator to choose the most suitable geographic representation for the theme, which can be Point, Line or Polygon. The administrators should also set their desired visualization settings in the moment of theme creation, including the representation symbols. Additionally the framework should allow administrators to define if the theme will require complementary artifacts to enrich the descriptions, like wikis and files, or if the theme will provide instruments to support discussions about the contribution, by receiving comments on contributions.
In ThemeRise, users should be recognized by their efforts on contributing to a theme, rather than by their overall contributions to multiple themes. Therefore, the framework should allow the administrators to define how many reward points the identified volunteer should receive for performing an action within the theme.
To bring more recognition and identify the most committed volunteers, the framework should assign users to groups of expertise. Administrators must be able to define a set of rules for users to evolve across these groups using ranges of reward points for each one.
These strategies were created based on [18]. However, ThemeRise also considers the theme for evaluation. The previous work proposes a system of rewards in which the user receives points for performing positive contributions to the community, and loses points when the contributions are negative. Volunteer efforts are also recognized by a title, based on experience or derived from belonging to a group of expertise. In [18], scores are taken into account and aggregated as a single value for each user, regardless of theme.
Finally, the last group of features is related to the ability of collecting contributions by volunteers to themes defined by administrators. The framework should allow volunteers to contribute in a theme providing information according to the settings defined by the administrators in theme creation, including geometric representation and descriptive attributes, arranged in a form. Following the same idea, volunteers should also be able to create complementary artifacts like wikis, comments, and attach files according with those settings. Also, according to the idea of recognizing the volunteers by their contributions, they must receive rewards for performing these actions.
Non-functional requirements define how the features are developed, and also are taken into account when the tools are evaluated to be used. Therefore, these requirements include the extensibility and flexibility of the framework, since it should be able to expand in the future and attend to different scenarios. Non-functional requirements also refer to tool selection, and include aspects such as the existence of good documentation that ensures the maintenance of the project. For the client application should be Web-based, and it should be implemented as a single page application, which can be better optimized. RESTful services were also included as requirements, since they can encapsulate some processes like database storage, and simplify the development of the framework. Additionally, RESTful services should use an ORM library that provides DBMS-independence.
Architecture and development
The proposed framework is divided into three independent layers. This structure follows closely the RESTful architecture, as proposed by Fielding et al. [19]. This design simplifies the development effort and isolates the implementation of components, allowing further expansions, such as the introduction of new components and replacement of existing ones.
The three layers in the framework are: (1) Persistence layer, where user generated data are stored; (2) Business layer, which works as a gateway between the components of the other layers; and (3) Applications layer, which hosts the application code, as shown in Fig. 1. Each of these layers is described next.
Persistence layer
The Persistence layer is where data produced by all users (administrators and volunteers) are managed to be stored. The component responsible for this function in this project is a relational DBMS with spatial support, which must implement the data model required by the framework. The data model can be divided into three main structures: Themes, Users and Reputation (Fig. 2).
As the name suggests, the Themes module contains the classes required to describe the themes and the corresponding volunteered contributions. Therefore, the main class is the Theme class and contains various descriptive attributes of the contribution, along with the connection to additional artifacts, such as wiki, files and comments, as was described by the theme creation requirements in previews section (p. 3). An important point of this class is the description of the attributes which will be collected as part of the contribution, since they will be used to generate the table that will store the actual contributions for this theme. The class will also be used when the user makes a contribution, since it describes the HTML elements that need to be rendered in the contribution form.
Along with the Theme class, there is the Contribution class, which contains the common structure required by every contribution and that will be extended after a theme is created to generate a specialized version to represent a theme contribution. The common structure present in all contributions describes the information about the author of the contribution (volunteer), version, date of creation, updating and deletion. As previously mentioned, the table that materializes this class in the DBMS should be dynamically created after the new theme is created by the user and inserted in the Theme table. The Theme and Contribution classes describe, thus, a behavior that emulates the catalog system in relational DBMSs.
Another group of classes involved with a theme and its contributions, as mentioned in the “Requirements” section (p. 3), are the artifact classes, which are composed by Wiki, WikiHistory, File, and the Comment classes. The latter provides a mechanism of interaction between volunteers to discuss the content of a contribution. The classes File and Comment contain the identification of the user who was responsible for that artifact, and for the contribution and theme to which the contributed file or comment belong to. Each one of these classes contains specific attributes to ensure their purpose. File, for example, contains fields like file name, type and location address, and Comment contains a text attribute. The Wiki class describes the current state of a wiki from a contribution, which should be shown to the application’s users. To enable the possibility of going back in wiki editing, the WikiHistory class was designed. It contains a reference to the editing author and the respective theme and contribution, along with its text.
Other then those classes, for quality measures, it is interesting to allow volunteers to rate a contribution. For this purpose, the framework includes the Rating class, which describes the computed rating value of a contribution. There is also a companion class, called RatingHistory, that describes every single user rating for a contribution.
The other module of the data model contains only theUsers class, which represents both administrators and identified volunteers. This class manages all user information, such as name, the e-mail address used to access the application, password and dates of creation, update and deletion.
The last module is related to the reputation system, which was designed based on [18], but with a theme-oriented perspective. In this context, the reputation data module contains a class (Action) that describes the actions that the user can perform, and the default reward for each action. The default reward works as a suggestion for the application administrator, who can change these values for each theme in order to adjust the application to the contribution patterns that the theme can take on. The customizations made by the administrator are described by a class called ThemeReward. Additionally, the score earned by the user in each theme is described in the UserScore class, which contains references to the theme and the action performed, along with the score earned by this type of action and its numerical value.
As the user progresses and her score gets higher, the framework is designed to provide feedback in recognition of the user’s involvement, by promoting her to a higher experience group. In this sense, the Group class was designed to describe the progress groups which can be reached by the volunteers. As in the Action class, this class also contains suggested threshold values for achieving a higher group. As described in the “Requirements” section (p. 3), the framework should also allow the customization of group score ranges for each theme. The ThemePromotion serves this purpose. It contains a reference to the group, theme, and the minimum and maximum scores that the user must achieve to progress or regress along the groups for each theme. There is also a class that indicates the group to which the volunteer belongs in each theme, called UserGroup.
Business layer
The Business layer is responsible for controlling the access to the Persistence layer and processing user-contributed information. Currently the Business layer contains only one API, but the layer’s architecture allows for further expansion as the clients or the data storage get more complex. The API can be divided by protocol type, in order to deal with HTTP to fetch data from the database, as well as use web sockets to handle real-time updates in contributions, so they can be shown by the application as map updates.
The HTTP part of the API includes routes like login, registration of new users, creation and management of themes, creation and retrieval of contributions, their artifacts and ratings, and also allows editing and showing user’s profiles. These routes contain three levels of access: public, authenticated and administrator, reflecting the corresponding user roles. This separation limits the access to sensitive operations, such as the creation of new themes, banishment of users, and others.
The web socket architecture uses another way of communication between the client and the service, which consists in watching and triggering events. In this design, instead of creating a short-term connection between client and service to request and receive information, with web sockets this connection is started and remains active until the client requires the end of connection, or the connection is unexpectedly interrupted by network failure. This enables the service to send new information every time it receives updates. Updates are usually sent as an event that is watched by the client. For the application, this behavior is useful, since it keeps the application map always up-to-date. Hence, the web service should implement events using web sockets to actively send current information to the client.
Considering the requirements analysis, four frameworks were considered as alternatives for the development of the API: Django and Pyramid, for Python, and Express and Hapi, for NodeJS (which was developed using Google’s V8 Javascript engine). We preferred Hapi at the end of the analysis because of its good performance, flexibility and maintainability. Hapi is currently used by major companies such as Netflix and Walmart.
We also set out to select an ORM library for the framework, in order to ensure component independence from the Persistence layer. The ORM2 and SequelizeJS libraries were tested in order to verify their ability to handle data definition and queries for both spatial and conventional data types, relying on the underlying DBMS’s capabilities. SequelizeJS was chosen, since it was able to handle spatial data from PostgreSQL Although SequelizeJS is only fully functional with PostgreSQL, the support for other DBMSs is likely to expand, since the library is already capable of handling conventional data managed by other platforms.
The API was also implemented with a web socket element by using the Socket.io library. This library is the most popular one for NodeJS environment, and also has a client version. As mentioned before, the web socket is responsible for notifying the clients when a new contribution is made.
Application layer
The last layer is the Application layer, which contains client applications. For this project, there is only one Web client so far. This client must contain an administration section, where the application administrators can create themes and manage users, a section for registered users, where they can verify their profiles and points earned in each theme, and a section with a map that allows the volunteers to contribute. Additionally, the application must contain the mechanisms for login and registering new users.
In the Application layer, one of the requirements for a web client was to use the single page application concept in the design. There are many libraries and frameworks that can be used to create this kind of application. We considered two of them, AngularJS and ReactJS, to implement a simple blog application and verify its features. This two libraries lead to different architectures. Although ReactJS allows more control over the components and the data flow through the application, AngularJS was chosen for its simplicity in promoting the MVC architecture. Associated with AngularJS, the Angular Material library was used to speedup the user interface design process.
Since AngularJS uses the MVC pattern, the web application can be divided into views, like login, register, map, create contribution, view contribution, profile, and administration views. The first ones enable the users to access the application, and are composed by simple form views. The most important user view is the map, in which the volunteer can visualize the contributions regardless of having an account in the application. The map is created using Leaflet web mapping library, which is simpler than Openlayers, but supports various plug-ins for different tasks. In the contribution part of the map, if the volunteer is not authenticated, the application will show only the themes that allow anonymous contributions. The identified volunteer can see all the themes. Additionally, a view was created for filling out the contents of the contribution, using a dynamic form that changes depending on the theme’s predefined attributes. A view for the display of the contribution was also developed.
For signed-in volunteers, the application also presents a profile view, containing personal information and the current scores and groups by theme. This view is composed by a series of charts that were developed using the C3 library, which encapsulates the D3 visualization library. Besides this view, there is also a view where the identified volunteer can edit her personal information, such as email, name and password.
The administrators can access additional sections that enable them to manage themes and users. In this way, a view for creating, listing and showing the theme was developed. There are two views to manage users, one for listing and another that is similar to the profile view that the authenticated volunteers can access.
