Citizen-Friendly Participatory Campaign Support

Jesse Zaman, Ellie D’Hondt, Elisa Gonzalez Boix, Eline Philips, Kennedy Kambona, Wolfgang De MeuterSoftware Languages Lab,

Vrije Universiteit Brussel, Brussels, Belgium

{jezaman, eldhondt, egonzale, ephilips, kkambona, wdmeuter}@vub.ac.be

Abstract—Participatory sensing, which appropriates wearabledevices such as mobile phones to enable ad-hoc, person-centricmobile sensing networks, has the potential of delivering datasetswith high spatio-temporal granularity. We argue that to obtainsuch datasets the concept of a participatory campaign, a recipefor gathering data to answer a particular concern, is essential,and that technological support for organising such campaigns iscurrently lacking. Campaign support is crucial to ensure thata dataset of adequate quality is gathered to study the concernunder consideration, and additionally, to empower communitiesby providing them with a tool to answer local concerns andset up grassroots sensing actions without having to wait for aninstitutionalised action to take place. In this article we presenta proof-of-concept architecture for participatory campaigns. Thelatter is built upon a formal definition of a campaign and thedescription of a campaign lifecycle, both of which are distilledout of earlier expertise with and related work on organisingparticipatory sensing campaigns.

I. INTRODUCTION

The rise of relatively cheap, Internet-connected, pro-grammable, sensor-laden smartphones has vastly increased thepotential for person-centric applications. As a result, the ideaof participatory sensing emerged [1], [2], in which public andprofessional users participate in gathering, analysing and shar-ing local knowledge about different aspects of the environment.Since about 2008 the field has gained a lot more tractionbecause of the rise of mobile apps and app stores, amongothers. As a result, many platforms, typically consisting of acombination of mobile app, web app and underlying database,have been developed [3]. However, the systematic usage ofthese platforms in setting up sensing campaigns is a much lessexplored aspect of the field. Indeed, while earlier work alreadyrecognised the importance of campaigns and the necessity ofproviding the required support for setting them up [1], sofar most platforms have only been used for one-off, proof-of-concept campaigning. The reasons for this are first, thatthe methodology for running successful campaigns was yetto be investigated, and second, it is very difficult to scale upcampaigning actions without adequate platform support, evenfor platform designers [4]. As a result, it is even more difficultfor communities to do so, as their primary interest is in localconcerns rather than the enabling technology.

In this work we present a first approach in supporting par-ticipatory campaigning in a way that puts issues of scalability,usability and data quality on the forefront, with the aim ofempowering all citizens to tackle their environmental concerns.Here we rely on earlier expertise on using the NoiseTubeplatform for organising noise mapping campaigns [5]. Whileour technical contributions build on top of this platform,the methodology used applies more broadly for any geo-located environmental information. Our work differs from

existing platforms such as EpiCollect in that it targets not onlysurvey-based, behavioural information, but also sensor-basedenvironmental data. It is maybe most similar to the recentlydeveloped ohmage platform [6], which is based on much thesame philosophy as the one presented here, but is focused on acombination of configurable surveys and background activitymonitoring rather than environmental sensing.

The rest of this paper is organised as follows. The nextsection defines the concept of a campaign, its lifecycle, andmotivates the need for automated orchestration of campaigns.In Sec.III we present a prototype framework that enablescitizens to define noise mapping campaigns independently, andwhich provides automated orchestration functionalities so thatdata quality can be guaranteed. This orchestration framework isbuilt around the notion of a workflow engine that orchestratesthe participants, their contributions, and the overall campaign.Finally, we conclude and describe work in progress in Sec.IV.

II. PARTICIPATORY SENSING CAMPAIGNS

The idea of a campaign emerges naturally in the context ofparticipatory sensing because of two reasons. First, participa-tory sensing is a person-centric sensing method which activelyinvolves citizens, and so it is subtly different in practice thanmore passive crowdsensing systems. Indeed, one typical usecase is the one of communities organising themselves to tacklea local issue.1 In this case, there is typically a location whichthe community targets, while sometimes a particular time spanis also of interest. However, one should realise that everyparticipatory sensing framework can also be used as a datarepository for crowdsensing campaigns that do not necessarilyactively involve contributors. An example is where a researcherwants to compare peak hours in different countries, or whenhe wants to compare contextual tags to do with sound sourcesas added by different age groups. A second reason for theimportance of the concept of a campaign is one of dataquality [5]. Indeed, in a participatory context one has to strikethe right balance between quality and quantity of data, statis-tically averaging over large datasets so as to minimise randomerrors while at the same time increasing representativeness ofvalues obtained. By focusing measurement efforts in terms ofgeographical and temporal boundaries one can ensure that adense enough dataset is collected.

Based on the key aspects that we observed from analysingparticipatory environmental mapping campaigns within thecontext of NoiseTube and beyond, we propose to concretisethe definition of an environmental mapping campaign givenin [1] as follows.

1Examples of this type of campaigns can be found athttp://www.brussense.be/experiments.

2014 IEEE International Conference on Pervasive Computing and Communications Work in Progress

978-1-4799-2736-4/14/$31.00 ©2014 IEEE 232

A campaign is a collection of measurements M constrainedby a quadruple of predicates P = (Pg, Pt, Pc, Pu) on geog-raphy, time, context and users respectively, such that M iscollected participatively by a set of users U satisfying Pu.We call P the campaign protocol. A campaign is consideredsuccessful if M is dense enough to generate a qualitativeoutput (typically a map).

It is important to notice that next to the constraints,embodied in the protocol, we also capture the necessity ofobtaining qualitative data that can be used by the communityfor local actions. Whether or not a particular output is qual-itative is of course an issue which one has to investigate inspecific contexts. For noise (and arguably, other environmentalgeolocated parameters where statistical averaging makes sense)we rely on a formula which computes data density in terms ofa geographical grid which was presented in [5]. The formulacouples measurement frequency, the number of participants,the size of the area, and the length of the time interval todetermine data density for each grid element, and is used inwhat follows below at the level of campaign definition as wellas monitoring.

From analysing participatory environmental mapping cam-paigns we derived a typical campaign’s lifecycle to be asillustrated in Fig. 1.

Initiative

Recruitment

Seek Assistance

Info

ExecutionData Aggregation Planning

Concern

Proof

...

Protocol Definition

Campaign Preparation

Campaign Definition

Fig. 1. The lifecycle of an environmental mapping campaign.

The first phase is one of preparation, where a citizen’sconcern about local issues motivate him/her to take initiativeand look for a solution for this problem. This solution may beinstitutional or participatory. In case of the latter, the campaigndefinition phase starts: additional citizens are informed of theinitiative and the concept of a participatory sensing campaign,and the campaign protocol is defined in an iterative manner.Once the planning is complete, the actual execution of thecampaign can finally begin, entering the campaign monitoringand analysis phase. After participants collected enough datafor the campaign to be successful, the data is aggregated toform the campaign’s output (typically a map) which can beused by the community to prove their concern is legitimate.

While the above shows that the notion of a campaign hasmatured well enough for them to be a practical tool for citizens,there are several hurdles to overcome. First, because there is nosupport for campaigns within existing frameworks there is anissue of scalability, and this at the level of campaign frequency,campaign size as well as campaign parameters. The reasonis that defining a campaign, monitoring it for data quality,

and orchestrating it dynamically so that campaign success isguaranteed, is currently managed by platform owners ratherthan by citizens themselves. This brings us to the secondhurdle: that of end-user usability. Indeed, by automatisingcampaign support features and encapsulating methodologiesfor data quality citizens would no longer need to rely onthe expert knowledge of a platform owner and rather couldtackle local concerns autonomously. We note that involving adynamical orchestration component improves on data qualitywhile at the same time provides participants with feedback ontheir contributions, which may aid to motivate them to continueor increase their contributions.

In what follows below we propose a prototype frameworkwhich automatises the campaign definition, monitoring & anal-ysis phases of the campaign lifecycle, while also incorporatingan orchestration component to guide towards successful termi-nation of running campaigns. While the methodology proposedis applicable to campaigns in participatory settings in general,the implementation of our framework and its validation wascarried out in the context of the NoiseTube platform.

III. CAMPAIGN DEFINITION & ORCHESTRATION

FRAMEWORK

The prototype we developed consists of two components,which relate to participants as depicted in Fig. 2. The campaigndefinition component provides citizens with a web interfacewhich enables them to create, monitor, raise awareness about,and contribute to participatory noise mapping campaigns au-tonomously. This web interface is designed to be understand-able by citizens, incorporating elements dealing with dataquality in a transparent manner. To the best of our knowledge,the orchestration component is the first attempt to supportorchestration for participatory sensing campaigns technolog-ically. In our prototype, we focus on supporting the definitionand the execution phase of a campaign, while support for otherparts of the campaign lifecycle is work in progress [4].

As workflows are well-known for their usefulness inorchestrating processes and widely recognised as a usefulparadigm to describe, manage, and share complex scientificanalyses [7], we decided to base the implementation of ourorchestration framework on them. Although the mapping isquite natural, to our knowledge this is the first time workflowsare used in the context of participatory sensing.

Because it is an open-source, running project which hasbeen extensively used for campaigning, we chose to build ourframework on top of the NoiseTube platform [8]. The basicdata components our orchestration component operates onare so-called tracks: series of timestamped, geolocated soundlevel measurements, potentially augmented which social tags.However, our framework could easily be modified to operateon data streams generated by other sensing applications.

A. Campaign Definition

Our system provides an understandable interface for spec-ifying a campaign protocol, allowing citizens to define theirown campaigns by specifying the campaign goal, along withgeographical, temporal and contextual constraints that specifythe concern they wish to tackle (the user predicate Pu isnot included at this point because the NoiseTube database

2014 IEEE International Conference on Pervasive Computing and Communications Work in Progress

233

Fig. 2. System architecture.

does not store user information at this level of detail). Thecampaign creator must also specify whether the campaignshould be public or private. While everyone can participatein a public campaign, private campaigns are intended fordedicated groups, and can only be joined by invitation. Publiccampaigns allow dynamic evolution of contributors, a featureintegrated in the orchestration component discussed below.The last step in campaign definition relies on the data qualityformula presented in [5] and mentioned earlier in Sec. II. Itinforms the campaign creator of the workload involved (i.e.the number of participants required) to complete the campaignsuccessfully, determined in terms of the concrete constraintsprovided. This feature is extremely useful as it providesan immediate feedback mechanism in case creators defineunrealistic campaigns. For example, it will tell a campaigncreator that creating a good map of a whole city involvingonly 10 participants for an hour per day during a week issimply not reasonable.

Once a campaign is created, the system also provides aninterface that enables members of the campaign (in addition toother users of the system, if the campaign is public) to monitorand discuss the campaign’s progress.

The campaign definition framework is built using the Rubyon Rails framework and is written as a combination of Ruby,HTML, CSS and JavaScript (as is the NoiseTube platform). Inthe backend sits a PostgreSQL database with the PostGIS spa-tial extension. We specifically chose the PostgreSQL DBMSin order to use PostGIS, which adds data type support forgeographic objects and allows various types of spatial queriesto be handled at the SQL level.

B. Campaign Orchestration

The creation of a campaign instantiates a campaign-specificentity which lies at the basis of the orchestration of a campaign.In our approach, this entity is a workflow, and orchestration

proceeds by executing this workflow via a workflow engine.When a new campaign is created, the constraints imposedby the creator are used to initialise this workflow, whichorchestrates a campaign by processing contributions, monitor-ing the overall campaign progress, and providing feedback toparticipants to guide campaign creators towards a successfulcampaign. The main purpose of this workflow is to helpcitizens obtain a qualitative result from their autonomouscampaigns.

In the remainder of this section, we discuss the four partsof our campaign orchestration workflow: track preprocessing,verifying campaign relevancy, adding relevant measurements,and monitoring campaign status. For the full workflow we referthe reader to [4]. We implemented this workflow in NOW [9], aworkflow language built for orchestration purposes in nomadicnetworks, where a fixed infrastructure is complemented withmobile ad-hoc components. This setting fits nicely in ourapproach, where participants use mobile phones to connect tothe campaign framework. Additionally, by using a workflowlanguage such as NOW, we were able to use high-level work-flow patterns to ensure that the control flow of the applicationand the fine-grained application logic are not interwoven. Thisfacilitates the development of large-scale complex applicationssuch as participatory sensing frameworks.

Track preprocessing. The first part of the workflow is amandatory preprocessing phase in which uploaded tracks frommobile devices are parsed so that their contents can be added tothe data environment. If the workflow is orchestrating a privatecampaign, then this part of the workflow is also responsiblefor selecting only tracks uploaded by users participating in thecampaign.

Verifying campaign relevancy. The second part is respon-sible for track-based orchestration. This is accomplished bytranslating the constraints in a campaign protocol into datafilter patterns, in charge of verifying which track measure-ments are relevant to the campaign. Measurements violatingat least one constraint are no longer considered. One concreteexample is the geographical filter, which checks whether theGPS coordinates of a measurement are compatible with thegeographical constraint of the campaign. Each of these datafilters is monitored for the number of measurements that arefiltered out, information which is used to provide feedbackto the participants and campaign creators. For example, if aparticipant collects measurements outside the campaign’s areaof interest, he/she will be informed that some of the measure-ments could not be considered as relevant to the campaign, andis requested to consult the campaign information to preventfuture mistakes. This feature alleviates a common issue incampaign execution: that of accidental faulty data collection.Without orchestration, this issue can only be spotted by regularinspection of data arriving in the repository.

Adding relevant measurements. Tracks that make it to thispart of the workflow contain measurements that are relevantto the campaign. If the user who contributed the track is aparticipant of the campaign, the flow is directly passed to thefinalisation activities of this part of the workflow, which informthe user on the number of measurements contributed to thecampaign, in addition to actually storing that information inthe database. If the user is not a participant of the campaign,additional actions must be undertaken: the user is informed

2014 IEEE International Conference on Pervasive Computing and Communications Work in Progress

234

that his measurements could be used for the campaign and isasked if he wants to join the campaign, in addition to askingpermission to use the measurements already collected. Onlywhen allowed are the measurements added to the campaign,as in our system the user is in control of what happens to hisdata.

Monitoring campaign status The last part of the campaignorchestration workflow is not track-based but rather monitorsthe overall campaign progress. It does this by accumulating allmeasurements considered relevant for the campaign. The ideais as follows: each hour, an activity checks whether the hourthat just passed is compatible with the temporal constraintsof the campaign. If it was not, no further calculations areperformed. If it was, the activity further verifies how manymeasurements were collected during that hour. Since thispart of the workflow keeps track of the total amount ofmeasurements already contributed, it can inform the campaigncreator about the current average contribution rate. Here wereuse formula for data quality, which was used statically atthe level of campaign definition, in a dynamic manner. If thisaverage falls beneath a certain threshold, additional feedbackis provided. Concretely, a message is posted on that campaignweb page notifying participants that a higher participationgrade of is required. Alternatively, the campaign creator isinformed that he most likely will have to increase the runtimeof the campaign or the number of participants, in order toobtain a qualitative result.

IV. WORK IN PROGRESS

This article presents a framework for defining and moni-toring community-driven environmental noise mapping cam-paigns through an automated orchestration interface. We val-idated our framework by simulating reruns of several noisemapping campaigns, originally orchestrated manually on topof the NoiseTube platform. As such, we observed that thecampaign constraints specified in our campaign definitionframework correctly translate into a campaign workflow, whichin turn is capable of processing contributions, providing par-ticipant feedback, increasing campaign quality, and monitoringcampaign progress. With these results in hand, we can nowenvision developing our framework further, both within thecontext of noise mapping campaigns and beyond.

As always in participatory sensing contexts, one has tomove beyond a proof-of-concept implementation, which maysuffice for academic purposes but not for citizens actually usingthe system. A first action is then to fine-tune our implemen-tation so that it is stable enough for real-world deployment.An important aspect hereof is the feedback system, whichcurrently runs on a command line interface instead, ratherthan via an online or mobile message centre. To do thisrequires to open up the distributed features of workflowsand the NOW workflow engine in particular. Also, we couldenvision extending our implementation so that it covers allaspects of a campaign’s lifecycle, adding also functionalityfor campaign planning and analysis, for example. Once theseissues are resolved, we can validate our system by using it inreal-world participatory sensing campaigns, for which thereis much demand. Concretely, we have contacts both withnational organisations (as a result of previous campaigns) andinternational ones (several city administrations from a project

consortium), all of which have high interest in running noisemapping campaigns but are currently only able to do so on asmall scale.

A second line of research is at the level of the underlyingtechnology. Indeed, we are now convinced that participatoryplatforms would highly benefit from the area of reactiveprogramming [10]. It is not difficult to see that such platformsare in inherently event-based, as sensor streams are dynamicquasi-continuous streams of information and surveys can beconsidered as discrete events. However, it is not only at thelevel of mobile data gathering that reactive aspects come intoplay. Indeed, the monitoring of campaign data and resultingfeedback mechanisms are also inherently reactive processes.We are currently looking into introducing reactive program-ming concepts into participatory sensing contexts. Becauseof the cross-cutting nature of reactivity, as well as currentstate-of-the-art, this may very well lead us to evolve fromtraditional three tier programming to a tierless programming[11] approach, where boundaries between architectural com-ponents are much more transparent. While it is clear thatworkflows will keep on governing aspects of participatorysensing architectures, such a fundamental change of approachmay require us to implement them as a component rather thanas the base technology to start from.

While the concept of a campaign, map visualisation and themethodology for guaranteeing data quality are more generallyapplicable than for noise, our framework only provides supportfor defining and orchestration noise mapping campaigns. Infact even without considering campaign support it is currentlythe case that each and every participatory sensing platform hasto be developed from scratch – a substantial development effortwhich is far beyond the means of most communities. To thisextent, our current research focuses on finding a more genericapproach towards reusable and reconfigurable participatorysensing platforms, keeping in mind that end users are typicallynon-ICT experts. This is a much more substantial researcheffort which we hope to report upon in the coming years.

REFERENCES

[1] J. A. Burke et al., “Participatory Sensing,” October 2006.

[2] A. T. Campbell et al., “People-centric urban sensing,” in Proc. 2ndannual international workshop on Wireless internet. ACM, 2006, p. 18.

[3] D. Christin et al., “A survey on privacy in mobile participatory sensingapplications,” J. Syst. Software, vol. 84, no. 11, pp. 1928–1946, 2011.

[4] J. Zaman, “Orchestrating participatory sensing campaigns with work-flows,” Master’s thesis, Vrije Universiteit Brussel, June 2013.

[5] E. DHondt et al., “Participatory noise mapping works! An evaluationof participatory sensing as an alternative to standard techniques forenvironmental monitoring,” Pervasive and Mobile Computing, vol. 9,no. 5, pp. 681–694, 2013.

[6] N. Ramanathan et al., “Ohmage: an open mobile system for activity andexperience sampling,” in PervasiveHealth. IEEE, 2012, pp. 203–204.

[7] The Taverna team. Why use workflows? [Online]. Available:http://www.taverna.org.uk/introduction/why-use-workflows/

[8] N. Maisonneuve et al., “Participatory noise pollution monitoring usingmobile phones,” Information Polity, vol. 15, no. 1, pp. 51–71, 2010.

[9] E. Philips et al., “Now: Orchestrating services in a nomadic networkusing a dedicated workflow language,” Science of Computer Program-ming, 2011.

[10] E. Bainomugisha et al., “A survey on reactive programming,” ACMComputing Surveys, 2012.

[11] “Opa language,” http://www.opalang.org, Jun. 2013.

2014 IEEE International Conference on Pervasive Computing and Communications Work in Progress

235