=Paper=
{{Paper
|id=Vol-1322/paper_1
|storemode=property
|title=A Practical Approach to an Integrated Citizens' Observatory: The CITI-SENSE Framework
|pdfUrl=https://ceur-ws.org/Vol-1322/paper_1.pdf
|volume=Vol-1322
}}
==A Practical Approach to an Integrated Citizens' Observatory: The CITI-SENSE Framework==
https://ceur-ws.org/Vol-1322/paper_1.pdf
A Practical Approach to an Integrated Citizens'
Observatory: The CITI-SENSE Framework
Mike Kobernus1, Arne J. Berre2, Marta Gonzalez3, Hai-Ying Liu1, Mirjam
Fredriksen1, Richard Rombouts4, Alena Bartanova1
1
NILU, Norway
Mike.Kobernus@nilu.no, Hai-Ying.Liu@nilu.no, Mirjam.Fredriksen@nilu.no,
Alena.Bartonova@nilu.no
2
SINTEF, Norway
Arne.J.Berre@sintef.no
3
Tecnalia , Spain
mailto:marta.gonzalez@tecnalia.com
4
Snowflake Software Ltd., UK
richard.rombouts@snowflakesoftware.com
Abstract. The prevalence of research projects that include a focus on Citizens’
Observatories (CO) is on the rise, and this increase has led to many initiatives,
most notably ‘Eye on Earth’ which aims to provide a platform which will
“facilitate the sharing of environmental, societal and economic data and
information, provided by the diversity of knowledge communities, to support
sustainable development.” This statement covers a whole range of CO
communities and projects that can be said to share a common goal, but in many
other ways are quite diverse and, from an architectural and Shared
Environmental Information System (SEIS) perspective, may focus on different
aspects. This paper will seek to provide a practical approach to creating an
integrated Citizens' Observatory based on the work undertaken in the EU FP7
CITI-SENSE project and following the CITI-SENSE Framework (CSF).
Keywords: Citizens' Observatories, Environment, Infrastructure, Platform,
Architecture
1 Introduction
The key to protecting and improving our environment is in the hands of the many, not
the few. Although our political, economic and administrative structures may be
designed to tackle our environmental concerns through scale and strategic decisions –
it often leaves citizens as unused and silent observers [1]. The Environmental data
products and services created in the CITI-SENSE project [2] (or indeed, any project
with a strong Citizen Observatory focus) are intended to change this. Although they
may be consumed by a varied group of stakeholders ranging from large government
organizations with enterprise systems, to SMEs and environmental scientists,
ultimately it is the citizens in their home with consumer devices such as mobile
phones or laptops that we wish to target. In order for any such project to be successful
it is paramount that information is published in the most accessible form according to
the user, their capabilities and their expectations. Since users vary in their level of
understanding and interpretation of environmental information, then underlying this
basic principle is the very real challenge of developing services or products that can
cater to them. For example, providing citizens with near real-time environmental data,
generating reports to municipalities and regulating bodies, and providing state-of-the-
art monitoring is all part and parcel of the expectations imposed upon those who
provide the ICT (Information Communication Technology) services that support the
complex world of environmental data monitoring, analysis and dissemination. And
while these objectives may not appear to be conflicting, they do require quite distinct
methods and approaches in terms of data analysis, modeling and presentation; the
correct approach being dictated by who the data is for, what that user understands and
what they expect to get from it. Recognizing that there is no such thing as a typical
‘end user’ or rather that end users are quite different both in terms of expectations as
well as knowledge and expertise is the first step in developing a Citizens’
Observatory, as these requirements will drive the functionality and service design that
is intended to cater to them.
Within the topic ENV.2012.6.5-1 “Developing community-based environmental
monitoring and information systems using innovative and novel earth observation
applications”, EU FP7 framework currently funds five projects with a clear focus on
Citizens' Observatories. These are: CITI-SENSE [2], WeSenseIt [3], Cobweb [4],
CitClops [5] and OMNISCIENTIS [6]. The environmental domains differ widely
between these projects, covering air quality, water management, biosphere reserves,
coast and ocean optical monitoring and odour monitoring, respectively. However, as
different as the subject of their data may be, their overall goal of creating an
interactive and vibrant environment where users are encouraged to participate with
their own observations is likely quite similar, sharing many of the same goals.
However, this paper’s focus is primarily on describing the development of an
architectural approach to supporting citizens' observatories and their users from the
perspective of just one project, although it will draw on the experiences and lessons
learned from several EU FP6-7 projects that are now completed. The subject project
that we take our framework from is the FP7 CITI-SENSE project, part of the
ENV.2012.6.5-1 topic, mentioned above.
2 What is a Citizens' Observatory?
At this time, there is no consensus exactly on (i) what a CO is; (ii) what it should do,
(iii) who it should be for and (iv) how it should be made. According to Liu, et al. [7],
a CO is defined as being “citizens observing and understanding environment related
problems, and more particularly as reporting and commenting on them.” While we
agree with this general statement, it does not indicate any kind of approach or
methodology. Indeed, even the definition of exactly what 'citizens' means can be
discussed. But, as short and to the point as that definition is, careful consideration of it
does clearly reveal three core components that underpin its objectives. We can define
these broad objectives as: raising awareness, initiating dialogue and data exchange.
These points can be considered as the three pillars that support a Citizens’
Observatory. As we discussed in the introduction, how these pillars relate to the
stakeholder’s experience, expertise and expectations are clearly important. In the
following section, we briefly discuss them in turn.
2.1 Raising awareness
Information is available to us in a myriad of ways and from many sources. Via
newsprint, radio, television, online portals and mobile devices. In fact, there is so
much information it is sometimes hard to keep track of what we need, or even to
really understand what we need to know. At the recent 2013 Green Week conference,
the European Environment commissioner, Janez Potočnik reinforced this when he
stated that “We have learned that public awareness is of key importance for the
implementation of existing air policy, as well as for the success of any future air
pollution strategy” [8]. Clearly, getting the useful ‘message’ across to the public, in
the right way and thereby effectively raising public awareness, is critical. The first
criterion therefore is to determine who you want to get your message to, and then
targets those users in a way that ensures a certain level of interest engages their desire
to know more.
In previous projects (ACCENT [9], HENVINET [10], and ENVIROFI [11]) we have
attempted to engage users through various campaigns, including mass emailing,
printed media such as brochures, online video presentations and workshops in the
Café Scientifique format. These methods did generate a sufficiently moderate number
of public users interested in knowing more about the project topics but ultimately they
did not create a self-sustaining community of users willing to engage or participate
long term in a community forum based on a social networking style platforms. So
while it could be argued that we were moderately successful, it was clear that we did
not really create a viable, sustainable community. What was missing was the
emphasis on knowledge transfer. Raising awareness is not just about alerting the
public or recruiting users; it is just as much about helping those users understand the
issues, problems and concerns relating to the environment so they can make informed
decisions of their own. And while these platforms did include expert users who could
answer questions about environmental issues, this does not automatically translate to
true knowledge transfer. An additional factor is to ensure that our communities’
opinions, thoughts, questions, etc., are not only heard/informed, but valued and just as
importantly, are seen/involved to be valued. To do this, we needed to provide a
platform for creating a dialogue with our users.
2.2 Initiating dialogue
Successful multi stakeholder dialogues are critical to ensuring a deeper level of
interest from stakeholders, especially the general public. At the most basic level, these
can take the form of peer to peer as well as public to expert (which includes science
and policy) so any forum for discussion needs to have a comprehensive membership
drawn from a multidisciplinary volunteer ‘workforce’. Not only this, but the members
must be consistently active. Nothing kills a communication portal quicker than low
levels of active participation. Only if regular activity, from a varied group of users is
achieved are you likely to see sustained growth over time, as more people begin to
participate than fall away. It cannot be overemphasized that this is not a place for
passive participation and that static information portals guarantee a quick demise.
Social media applications can be employed as a platform for initiating dialogue but in
itself, this is ultimately insufficient. It is critical to move to a more advanced level,
since multi-stakeholder dialogues are more than just question and answer or
discussion forum style communication as they must include technology based
information gathering and exchange systems. These can include sensors as well as
personal, subjective observations from the users, which will create a much broader
canvas for information gathering and of course, data exchange.
2.3 Data exchange
Data exchange is much more than just pushing data to users and goes beyond the
sharing of ideas or questions, etc. In a Citizens’ Observatory context, this must
include a variety of VGI (Volunteered Geographic Information) observation types, in
addition to personal observations on an array of topics, such as physical wellbeing,
perceived environmental effects and even personal opinions. Key to this is that the
citizen is encouraged to collect and provide data input regularly and finds value in the
way that this information is used. The citizens' peers may also find value in this data
and be further encouraged to make their own observations available. An important
aspect is that all data, not just electronic sensor data, has a geo-temporal marker.
The wider public is now in a position where micro sensors can be accessed in
increasing numbers due to advances in technology and lowering costs. An individual
might purchase sensors for any number of reasons, and tying them into a national
(even international) collection, storage and dissemination platform is becoming
increasingly possible. However, while this results in more data being generated it is
not necessarily engaging the users themselves who might be entirely passive data
providers. An important aspect of the Citizens’ Observatory concept is the realization
that citizens are now potentially walking, talking sensors and their inputs (covering a
wide spectrum of data types) are potentially very useful. For example, pollen data is
generally very limited, so major generalizations are often made about the prevalence
of pollen in any given area (the further from measurements stations, the more this is
true). Therefore, if individuals reported the presence of particular types of pollen
(there are about thirty that cause allergies) in a specific area, then this could be of
great interest to others who also have an allergic reaction to that particular pollen
type. Therefore engaging citizens in providing personal observations on their
perception of the environment can have beneficial consequences for others, which
will further encourage others to participate with their own observations as well.
Finally, presenting information that combines heterogeneous data sources which
includes VGI data allows the stakeholders, in particular public users, to see just how
their individual contributions add to the value chain, ultimately creating a reinforcing
mechanism that will help to create a self-sustaining community.
2.4 Applying the three pillars
Within CITI-SENSE there are nine pilot cities that will employ one or more end user
‘products’ developed within the project. These products are separate from the various
support services, such as GIS, WMS, Modeling, etc that actually enable the products
to function. The products fall into two basic types: a) a web application and b) a smart
phone/mobile device application. For the web applications, these take the form of web
portals with dynamic content (beyond the usual database driven CMS). The dynamic
content includes visualizations of sensor data from various locations. For example,
one of the pilots places varying sensors in school classrooms. The data generated by
the sensors will be stored in a database, and ultimately displayed on the web portal in
near real-time. The visualization of the sensor data is handled by widgets that fetch
the data from the database, and display them in accordance with the pilot officer's
wishes (eg. graph, 1 month historic data, 3 months, etc). This can be viewed as the
archetype for all the web portals, since they all work in much the same way regardless
of location, sensor or data source.
The smart phone applications are, naturally, a little different. They also display sensor
data to the user, but due to the nature of the platform, they demand a much more
interactive approach from the user. The web applications can display more data, with
associated descriptions, content, etc, because they have much more 'real estate' in
which to work. The smart phone applications suffer from having a relatively small
screen area, and consequently, much more care is needed in presenting the data to the
user, or rather, in choosing just what data to present first. In addition, because the
mobile devices have GPS capability, several of the pilots leverage this by tracking the
movements of the user and storing that as additional data alongside any sensor data
generated by the user or from attached sensors, or from the phone itself. Since several
smart phone applications will be developed for the city pilots, it is obviously
important to develop a platform that enables them to share common libraries and
where possible, re-use of code. This is a core objective when designing the
architecture which must enable end products which serve entirely different users, with
different needs and expectations and levels of understanding.
Since the smart phone applications cover a variety of uses, from simply displaying
textual information, to tracking the user's movements in order to provide assessments
on UV exposure, to using meteorological sensors which communicate with the phone
via Bluetooth and also detect motion from gyroscopic functions within the phone
itself which enables the calculation of movement, it is essential that the architecture is
both flexible and scalable to be able to adapt to any changing demands as they occur.
Both data delivery platforms, web and mobile, push data to the user, but both can
receive data from both the end users as well as (in the case of the mobile devices)
attached/connected sensors. The interactive nature of a web or phone application is
ideal for generating VGI, or observations of a personal or subjective nature. These are
observations that the user can make on his perceptions of the environment and or
health and well being. Further, directed requests for data can be made through the use
of questionnaires which the user can complete and submit, thereby generating more
data of a subjective nature, but with an aimed focus.
These approaches are all used in the CITI-SENSE project where there is a wide
variety of Test Cases employing sensors in schools, in the hands of users as they go
about their daily routines (UV for example) and sensors that are part of the mobile
device, or even the user himself. An example of the latter is the method taken by the
city pilot which is investigating noise, thermal comfort and outdoor spaces and which
uses a combination of human as sensor, Smartphone as sensor and both VGI and
directed data request (quiz). When taken as a whole, the CITI-SENSE project covers a
broad spectrum of requirements where every pilot is a Citizen Observatory in its own
right. Key to this ambitious objective is, of course, an underlying architecture that is
both flexible and adaptable.
3 Developing a Framework
In this section we describe the CITI-SENSE Framework, which is based on
combining a life cycle perspective of the services needed for a Citizens’ Observatory
with an architectural perspective of the services and components that can support this,
in accordance with the SDI description approach of CEN/TR 15449 and ISO 19119.
This life-cycle based perspective facilitates the identification of enablers with both a
service centric and data centric viewpoint. The project makes use of components
which have been identified in a recent activity from the European Committee for
Standardization (CEN) and Technical Committee (TC) 287 for building a reference
model for spatial data infrastructures (SDI) [12], see Figure 1.
Fig. 1. Core Components of the SDI Reference Model ([11], modified).
The primary organizing structure is determined by the following generic core life
cycle components (corresponding to the service centric view in the figure above):
Register: for describing and publishing resources.
Discovery: for searching for and discovery of resources.
View: for visualizing of resources.
Download: for downloading and exchanging resources.
Invoke: for interacting with resources.
Orchestration and Composition: for providing aggregated resources
including in particular workflows for service composition.
Security and Rights Management: for managing access rights to resources.
Related to the data centric and service centric view shown in figure 1, we illustrate the
requirements of the environmental usage area. First, we define the roles, as part of
overall added-value chain. Then we define the stakeholders, before applying the
TR15499 framework to the project’s architecture. In doing so, we provide a bridge
between practical environmental applications and the wider political framework. The
presented findings could equally be applied to other geospatial and non-geospatial
domains beyond the environmental domain.
3.1 Roles and Value Chain of Environmental Knowledge Generation
Analyzing the requirements of eEnvironment services for the terrestrial and
atmospheric sphere, we define a total of six roles, which may contribute to the
generation of environmental knowledge [13]:
1. Observer, being the initial source of information about the environment. This
may be a sensor measuring weather conditions to a citizen making an
observation.
2. Publisher, making a resource, such as an observation, discoverable to a
wider audience, e.g. by providing required resource descriptions (metadata).
3. Discoverer, being the entity that finds a resource, e.g. pollen occurrence data,
based on all available descriptions.
4. Service Provider, making information or an environmental model accessible
to (and usable by) the wider audience, e.g. by offering a standard based
service for data download.
5. Service Orchestrator, being responsible for combining existing services in a
way that they create information for a distinct purpose, i.e. environmental
application focusing on a particular sphere, such as air quality.
6. Decision Maker, consuming an environmental application in order to retrieve
decision supporting material and making a final decision based on the
information available.
Consequently, the process workflow can be summarized as in the figure below
(Figure 2). Notably, following this workflow, services may get published in order to
serve as building blocks for more complex eEnvironment solutions.
Fig. 2: Added value chain of environmental knowledge generation [12]
3.2 Overview of Stakeholders
The tasks identified above (section 3.1) are performed by a variety of individuals and
organizations. These can be further defined as:
Citizens of a particular social, political, or national community;
Environmental agencies on sub-national, national and European level;
Public authorities of national and regional and other level;
Industries from the primary, secondary and service sector;
Platform providers offering frameworks on which applications may be run;
Infrastructure providers offering physical components and essential services;
Sensor network owners holding the sensor and basic communication hardware.
observe provide discover create orchestrate decide
Citizens x x x x x x
Environmental agencies x x x x
Public authorities x x x
Industries x x x x
Platform providers x
Infrastructure providers x
Sensor network owners x (x) (x) x
Tab. 1. Added-value chain of environmental knowledge generation [12].
Table 1 provides an overview of the manifold mappings between these stakeholders
and the different roles in the value chain of environmental knowledge generation.
Notably, citizens can play all roles within the value chain of environmental
knowledge generation.
3.3 Applying the TR 15449 Architecture to CITI-SENSE
The life cycle based enablers and relevant applications can further be described in
terms of their architectural components and enablers/services. The following figure
shows how the different types of enablers can be related in the context of a complete
end-to-end ICT architecture.
Boundary
Interaction services Composition &
Boundary
Workflow
Interactions services
Composition &
Management and metadata
Workflow
services
Security a nd Priva cy
Management, Communication services
Processing
services
metadata,
Security,
Privacy
Data and Model
Management Processing Data and Model
services Management
services services
Communication
services
Fig. 3: Relationship of enablers in both a layered and a bus architecture
Figure 3 shows the relationship of different enabler categories both in a layered
architecture and also as a bus architecture. The taxonomy of the enabler types is in
accordance with ISO 19119 Geographic information – Services, clause 8.3. [15]. The
approach is to define both generic domain independent and specific enablers, such as
geospatial and environmental specific enablers, in each of the following six groups,
color coded in the figure: Boundary Interaction Enablers, Workflow/Task Enablers
Processing Enablers, Model/Information Management Enablers, Communication
Enablers and System Management and Security Enablers.
4 A Practical Approach to the CITI-SENSE Architecture
The CITI-SENSE project is developing an architecture based on state-of-the-art, open
standard components, defining a Citizen Observatory ontology and implementing a
series of nine empowerment initiatives that validate the architectural design.
4.1 Use of Ontologies and Linked Data within CITI-SENSE
Too often information is made available as lists of figures or spreadsheets that only
experts can interpret. To encourage and benefit from participation of a broad spectrum
of users, we need to present our information in a way everyone can understand [18].
One of the objectives of CITI-SENSE is to create city observatories across nine
locations in Europe and the near East. As described in section 2.4, diverse pilots have
been defined and will be deployed. But what to do with the data they generate? How
can this data be gathered and disseminated in a standard way so citizens and
stakeholders can make use of it? Visual analytics is, of course, a key component, but
how the data is stored and accessed, is important too.
Linked Data is the technology that allows publishing of data in a standardized way
and linking to other data sources that complement it. For instance, while a CITI-
SENSE pilot is gathering information about thermal comfort in a public park
(objectively measured with sensors and subjectively by asking people for their
impressions), we can also link this information with the current weather forecast, the
wind speed or even the humidity measured by weather stations in the surroundings,
thus providing a wider context for the data.
The ontology developed in CITI-SENSE is used to annotate the data gathered by
sensors, modelled data, VGI and answers to questionnaires, with the aim to publish
this annotated dataset under the Linked Data paradigm as open data, linking it to other
linked datasets in the Linked Open Data Cloud.
Fig. 4: Ontologies in CITI-SENSE
The Citizens' Observatories ontology adopts the Semantic Sensor Network (SSN) [19]
ontology as the upper ontology. The SSN ontology is considered to be the de facto
standard in the sensor world, so this ontology ensures future scalability of the CITI-
SENSE knowledge domain as well as providing possible links to other existing efforts
in sensor data gathering and publication. However, the SSN ontology leaves the
observed domain unspecified, so other ontologies have been selected and aligned with
the SSN ontology. Each additional ontology has been selected to address a concrete
need:
When are we measuring? This is modeled by the OWL Time ontology, a
W3C-recommended ontology based on temporal calculus, that provides
descriptions of temporal concepts such as instant and interval and which
supports defining interval queries such as within, contains, and overlaps.
Where are we measuring? The European INSPIRE Directive defines how
the different locations should be modelled. This includes two aspects: the
environmental monitoring facility as a spatial object in the context of
INSPIRE and Observations and Measurements linked to the environmental
monitoring facility.
What are we measuring? This covers the CITI-SENSE knowledge domain
and is represented by the requirements coming from the CITI-SENSE
empowerment initiatives.
Who and how are we measuring? The citizens actively involved in sensor
measurements are also an important part because their social and personal
context (e.g. age, occupation) can influence the analysis of the gathered
sensor data.
The Citizens' Observatories’ composite ontology provides the vocabulary to annotate
the available resources at each pilot: the description of the place where to perform the
observations and the person in charge of such observations, to describe the different
sensors and their measurements as well as the calculated data values from sensor data.
The ontology has been implemented following the network ontology approach, trying
to re-use as much as possible existing efforts in the ontology, linked data, sensor and
Internet-of-Things (IoT) worlds. This can easily be seen in our efforts to be conform
with the European INSPIRE directive from which, data specifications relevant to
CITI-SENSE, have been implemented: Geographical Names, Utility and
Governmental Services, Buildings, Addresses and Land Use.
The CITI-SENSE ontology is ready to annotate datasets with sensor observations,
modeled data, metadata on people in charge of the observations and location, amongst
other things, to be published under the Linked Data paradigm in the Linked Open
Data Cloud. Thanks to the reuse of well-known and widely used ontologies such as
the SSN and GeoNames, the links to existing published datasets are possible without
modifications of the ontology.
The Citizens' Observatories ontology is open for future evolution where new sensors
types, measure types or unit of measures may be required, without needing to modify
of its core structure, only enhancing it with new instances.
4.2 An Open and Standards-based Architecture
The CITI-SENSE architecture has been designed around the concept of a centralized
data platform (the "CITI-SENSE Platform"), which ingests data from a variety of data
providers and provides access to this data via a range of web services and interfaces
each aimed at a specific stakeholder domain.
The diagram (below left) shows a high-level enterprise viewpoint of the overall
architecture, while the digram on the right shows and Information Viewpoint which
clearly demonstrates the technologies that support the high level overview. Both
diagrams show the various data providers on the left-hand side, the CITI-SENSE
Platform at the core and the data consumers on the right.
Enterprise viewpoint Information viewpoint Capabilities
Government Services
GML
INSPIRE
Fixed GEOSS WFS,
Sensors SOS
KML
Existing
SenML XML, JSON
Mobile Sensors platforms
Citizen Relational
CITI‐SENSE Storage REST
SenML Model GeoRSS
platform
Citizens’
Observatories WS‐Noti
Citizens’ fication, WS‐
SME/Startup
Observations SES Notification
Federated WFS‐T
platforms Sensor Triple Store
metadata SPARQL
Academic / RDF
Calculated Data Research RDF
Fig. 5: Enterprise and Information viewpoints of the CITI-SENSE
Architecture
The architecture of the CITI-SENSE Platform is built on open standards, and not
constrained to any specific proprietary data exchange format or vendor specific data
repository, thus making the Platform accessible via open standard interfaces and web
services. Figure 6 shows the CITI-SENSE Platform architecture, where three different
data providing platforms have been identified:
1) Providers that already have an existing platform for receiving, storing, post-
processing and publishing data.
2) Providers that can collect or create the data but have no mechanism for
storing, post-processing or publishing data.
3) Providers that have developed an algorithm, service or application that can
create derived or value-added data products from the original observation data.
They need to be able to access the original data, have a mechanism for storing
and publishing the derived or value-added data. Additionally they may want to
run an algorithm, service or application on the CITI-SENSE architecture.
Sensor
Application
Platforms
sense
PSP -It-
now
GeoTech
Atmos
OBEO, …
Fig. 6: - CITI-SENSE Architecture for sensor and data management
The CITI-SENSE architecture therefore consists of three distinct components, or
platforms, that are all developed on standards-based technologies:
1) Sensor Application Platforms (W3C/OGC) – From various sensor platform
providers, with associated input services and apps.
2) Spatial Data Services Platform (OGC/INSPIRE) – Implemented by GO Loader
and GO Publisher and to be deployed using the Amazon Web Services (AWS) cloud
infrastructure.
3) Linked Data Platform (W3C/OGC) – Using CITI-SENSE ontology for
annotation and a Linked Data server to publish the dataset in the Linked Open Data
Cloud.
SensApp is an open-source service-based application used to store and exploit data
collected by the Internet of Things (IoT):
Application can registers sensors, stores their data.
SensApp notifies clients with newly arrived data.
A third-party application is provided to visualize data.
SensApp offers web services to upload, from smart phones or other data gathering
mechanisms, sensor data or extrapolated data to a repository. The data gathered by
SensApp and other sensor platforms is loaded by the GO Loader component into the
cloud-based centralised data repository.
GO Loader supports the configuration of enterprise-level relational databases and the
loading of data delivered in XML and its geographic equivalent, GML. GO Loader’s
‘schema aware’ technology means it can automatically adapt itself to any XML and
GML application schema. GO Loader is responsible for the ingestion of data into the
centralised data repository and supports data provided in a number of standard data
specifications adopted in the CITI-SENSE project such as SenML (W3C), SensorML
(OGC), Observations and Measurements (ISO/OGC) and INSPIRE Environmental
Monitoring Facilities.
The GO Publisher software is used for making the stored data available via a number
of open standard web interface technologies, such as Web Feature Service (WFS),
Representational State Transfer (REST), Rich Site Summary (RSS) and Event
Services. GO Publisher transforms the data from its SQL format into standard
encoding formats as XML, GML and JSON.
5 Conclusion
The CITI-SENSE project is quite unusual in that it is not a single Citizen
Observatory, but rather a collection of nine independent and in many cases, unrelated
initiatives that may, or may not share resources and data. While this does pose
difficulties, it also ensured that when developing an architecture to accommodate
these different end points we were forced to address the question of creating a
common platform from the very start. Naturally, this led to the adoption of existing
standards, technologies and methodologies in order to not “re-invent the wheel” such
as ensuring compliance to GEOSS, Linked Open Data, the INSPIRE Directive, etc,
as well as re-using generic enablers developed in previous projects, such as SensApp.
The CITI-SENSE Framework can be said to be comprised of the following major
components; its architecture, its products and citizen engagement through the ‘three
pillars’.
The three pillars approach provides a basic starting point for interacting and engaging
with the public covering the aspects of raising awareness, initiating dialogue and data
exchange. Supporting this is the work on product development which describes the
core objectives for the various observatories, identifies commonalities and provides
initial mock-ups. In this way, the CITI-SENSE Observatories have begun to take
shape.
Although still at a relatively early stage in the project, we have already implemented
some of the fundamental building blocks necessary for the foundation of the CITI-
SENSE Framework. Our experience has shown that integration of existing
infrastructures is not just desirable but entirely possible, as demonstrated by the
inclusion of SensApp, GO Loader/GO Publisher and the Linked Open Data Cloud.
The adoption of internationally recognised open standards for exchanging data allows
data and services to be truly interoperable.
We have designed the architecture towards enabling services for 3rd party
consumption in order that external users, willing to make use of the CITI-SENSE
Framework, will find a variety of connection possibilities. From the point of view of a
data provider, the CITI-SENSE Framework offers web services for data ingestion. As
a data consumer, the framework can be seen as a pool of data access protocols and
visualization widgets. A common repository for real time raw and/or derived sensor
data has been developed but in addition a repository for data using different standards
is also necessary. Consequently, new initiatives coming to join CITI-SENSE should
be seamlessly integrated.
Further, we see the value that the Open Linked Data Cloud provides as it enhances
our data through its ability to link datasets. In addition, the Linked Data paradigm
provides a standard way to expose, share and connect data on a global scale.
Acknowledgments. We thank the CITI-SENSE (FP7–308524) project consortium for
the lively discussions we had. This paper is based on our common findings, extended
from our previous work in previous European research projects and in the context of
ISO/TC211, CEN/TC287, OMG and OGC.
References
[1] Global citizen observatory - The role of individuals in observing and
understanding our changing world (European Environment Agency, 2009):
http://www.eea.europa.eu/pressroom/speeches/global-citizen-observatory-the-role-of-
individuals-in-observing-and-understanding-our-changing-world
[2] CITI-SENSE – Development of sensor-based Citizens' Observatory Community
for improving quality of life in cities, http://www.citi-sense.eu
[3] WESENSEIT – Citizen Water observatories, http://www.wesenseit.com
[4] COBWEB – Citizen Observatory Web, http://cobwebproject.eu
[5] CitCLOPS – Citizens' observatory for coast and ocean optical monitoring,
http://www.citclops.eu
[6] Omniscientis – Odour MoNitoring and Information System based on CItizEN and
Technology Innovative Sensors, http://www.omniscientis.eu
[7] Liu, H-Y., Kobernus, M., Bartonova, A., et al. Conceptual approaches to an
integrated citizens' observatory: supporting community-based environmental
governance (manuscript).
[8] Raising air pollution awareness ‘of key importance’. Available on
http://www.airqualitynews.com/2013/06/10/raising-air-pollution-awareness-of-key-
importance/
[9] ACCENT – Atmospheric Composition Change – the European Network of
Excellence, http://accent.nilu.no
[10] HENVINET – Health and Environmental Network, http://www.henvinet.eu
[11] ENVIROFI – The Environmental Observation Web and its Service Applications
within the Future Internet, http://www.envirofi.eu.
[12] European Committee for Standardization (CEN): TR15449 Geographic
information — Spatial data infrastructures — Part 1: Reference model. Technical
Report (2011).
[13] Schade, S., Fogarty, B., Kobernus, M., Schleidt, K., Gaughan, P., Mazzetti, P.
and Berre A.J.: Environmental Information Systems on the Internet - A Need for
Change. In: Hřebíček, J., Schimak, G., Denzer, R. (eds.) ISESS 2011. IFIP AICT, vol.
359, pp. 165–172. Springer, Heidelberg (2011)
[14] The European Parliament and of the Council: Directive 2007/2/EC of the
European Parliament and of the Council of 14 March 2007 establishing an
Infrastructure for Spatial Information in the European Community (INSPIRE).
Official Journal on the European Parliament and of the Council (2007)
[15] Commission of the European Communities: Communication COM(2009) 223 -
GMES and its initial operations (2011 - 2013). (2009)
[16] Commission of the European Communities: Communication COM(2008)0046 -
Towards a Shared Environmental Information System (SEIS). 2008/0046 (2008)
[17] Group on Earth Observations (GEO): The Global Earth Observation System of
Systems (GEOSS) 10-Year Implementation Plan. (2008).
[18] Semantic Sensor Network Ontology www.w3.org/2005/Incubator/ssn/ssnx/ssn