The term sensor web was originally used to describe a wireless sensor network architecture in which the nodes of the network were autonomous and able to react to the data measured by themselves and other nodes in the network [11]. Since then, the term sensor web has been used more generally, as it is in this paper, to describe a distributed web service architecture for publishing, discovering, and combining data from multiple sensor networks and related data sources.

One proposal for such a sensor web architecture is the set of data model definitions and web service specifications that comprise the Open Geospatial Consortium Sensor Web Enablement (ogc-swe) framework [9,10]. The three data model standards—Observations and Measurements Schema (o&m) [12], Sensor Model Language (SensorML) [13], and Transducer Markup Language (tml) [14]—provide syntactic data models for representing sensor measurements, the sensors that capture the measurements, and the processing performed on the measurements, respectively. The web service specifications define a service-oriented architecture that provides the functionality to interoperate with sensors and their data across organisation boundaries over the Internet. The Sensor Observation Service (sos) [15] provides the means by which sensor data can be published, allowing other services and applications to request sensor data. The Sensor Planning Service (sps) [16] enables, where it is permitted by the sensor, new tasks to be passed to the sensor. The Sensor Alert Service (sas) [17] and Web Notification Service (wns) [18] provide mechanisms by which services, applications, and users can receive alerts regarding sensor readings.

A reference implementation of the ogc-swe framework was developed in the sany project [19,20]. The sany project provided soap bindings for the abstract service definitions of the ogc-swe specifications. This enables clients to interact with services using standard web service messages (viz. soap) encoded in xml. The sany services also provided a rest interface [21] to the services. This enables clients to interact with the services through a http interface offering the operations get, post, put, and delete. (See [22,23] for a comparison between rest and soap web services.) However, issues of providing a rest-style interface, which focus on resources rather than operations, to a service-oriented architecture were not addressed in the sany project, see Section 4.4 for more details. A central notion of the sany project was the “plug and measure” paradigm whereby sensor networks could simply be deployed in the field and the measurements returned through a standard service interface. However the approach relies on the metadata to describe the sensor deployment having already been stored in the system. The sany project also defined a Cascading Sensor Observation Service for merging data from different sources and performing some post processing of the data, e.g., converting units or computing moving averages [24].

The ogc-swe architecture, and sany implementation, enables interoperability between disparate sensor networks by enforcing a common model and syntax for the data: data is exchanged as xml according to the xml Schema models defined by the ogc-swe standards. The semantic sensor web architecture proposed in this paper supports the independence of the data sources by allowing them to publish their own data models: a particularly important consideration when data is already being generated by sensors owned by autonomous institutions, or being operated by experts from different domains (each of which has its own set of terminology and concepts). The sany Cascading sos supports the merging of data from sos sources. However, it relies on the data conforming to the standard syntactic encoding, o&m gml. The semantic integrator in the architecture described in this paper supports the merging and correlation of data from disparate sources, including those external to our framework (e.g., sos). This approach to reuse transcends the original purpose for collecting the data or our set of services.

The ogc-swe framework does not define a registry service. One option for incorporating such functionality is to use the OpenGIS catalogue service [25]. The OpenGIS catalogue service is based on an attribute-value pair data model over which filters, expressed as attribute-operator-value statements, can be applied. In the semantic sensor web architecture proposed, both the data model (viz. rdf) and the query language (e.g., stsparql) provide a greater level of expressivity. For example, semantic terms drawn from an ontology can be used to refer to spatial geometries besides using coordinates to explicitly specify them.

The European projects osiris and genesis have developed a Sensor Instance Registry (sir) that offers operations for inserting, harvesting and querying information about sensor instances [26]. SensorML is used to describe sensor instances and queries are posed using a combination of spatial constraints, temporal constraints and keywords. Query answering is carried out by using three indices, one for each of the three kinds of criteria allowed. There is another component called Sensor Observable Registry (sor) where semantic information about phenomena observed by sensors can be stored using an ontology. sir can use sor to exploit semantic information to offer better answers to queries, e.g., to determine equivalent phenomena. A discussion of how to link this discovery framework with ogc catalogues and automatically expose resources provided through ogc-swe services to them is provided in [26,27].

ogc-swe also enables the tasking of services using their own mechanism provided through the Sensor Planning Service. We adopt the approach of declarative queries that describe data needs. These are passed down to the sources which can then satisfy the need according to their abilities to answer queries. For example, a query over a sensor network which is able to perform in-network processing can distribute the query into the network to save energy [28].

The Sensor Alert Service and the Web Notification Service provide a custom set of operations to provide limited support for publish/subscribe notifications of events. The semantic sensor web architecture proposed in this paper builds upon the Web Services Base Notification standard (ws-n) [8]. In addition stream query processing languages, such as sneeql [29] and sparql_Stream [30], provide support for push-based delivery of sensor measurements according to a declarative description of the data need. Note that the specification of the event service in ogc-swe v2.0 [31] takes a similar approach to the one proposed in this paper. However, our approach uses a single service to publish sensor data for either polling or push-based delivery whereas the ogc-swe 2.0 approach requires two services, the sos and the eventing service.

The term Semantic Sensor Web was coined by Sheth et al. [32], who proposed to combine the ogc-swe framework with existing W3C standards for annotating service interfaces and publishing sensor data as rdf. After this pioneering work, many other works have embraced the idea of applying semantic technologies for different tasks related to the discovery and integration of data stemming from autonomous heterogeneous data sources, including the work that we present in this paper. The work presented in [33] uses semantic descriptions of sensor deployments to support discovery and syntactic conversion of the data from sensors for publication into an ogc-swe sensor web. However, the semantic descriptions are not published in the sensor web, which uses the syntactic approaches of the ogc-swe framework for data discovery and publication.

In [34], five challenges are identified for the application of semantics to the Sensor Web. The first of these challenges is the abstraction level in which sensor data can be obtained, processed and managed in general. The second is the need to handle adequately the quality of data. The third challenge is the integration and fusion of data coming from heterogeneous and autonomously deployed sensor networks. The fourth challenge is the identification and location of relevant sensor-based data sources. The final challenge is the rapid development of applications that are based on these types of data sources. Theses five challenges are addressed by the semantic sensor web presented in this work.

There is also some ongoing work addressing the publication of sensor data on the Web, in the form of linked sensor data [35,36], although no standardisation or set of agreed best practices have been achieved so far in this respect.

Computer based Decision Support Systems (dsss) are information systems to enable users to make informed choices based on data and forecasts from a wide variety of sources [37]. dsss support a wide range of functionality and capabilities to help planners and managers to assess alternatives and ultimately take appropriate decisions. Increasingly, dsss are offered as web-based or mobile applications. These offer a considerable advantage over traditional dsss in terms of better cooperation capabilities, access to distributed data sources [38], or increased usability [39]. A number of web-based dsss applications have been developed to use data stemming from the ogc-swe framework [31]. However, these are limited by the capabilities of the ogc-swe framework, as described above, and cannot exploit semantic information provided with the data for discovery, integration or linking to related datasets.

The DHI Group have developed Flood Watch [40] and the Mike modelling framework [41] to provide a dss in the context of coastal flooding. These proprietary tools provide real-time forecasts in areas prone to flooding and issue early warnings to flood response managers and the public. They can be used to manage and examine real-time data from a range of external sources, support a range of modelling tools, and include a scenario management tool aimed at carrying out comparative assessments and response planning. Being a closed-source system, however, this framework requires extensive customisation and user input at all levels of the decision making process. The ability to dynamically discover relevant data sources, provided by the semantic sensor web architecture proposed in this paper, and the reliance of a light web-based client architecture instead of a centralised approach is certainly beneficial from the point of view of stakeholder cooperation, e.g., in the emergency response scenario used to motivate our approach. The use of ontologies as a means of mutual understanding between different types of system users in the development and deployment of decision support systems, advocated by this paper, has been successfully tested by the developers of semantically enabled SoKNOS emergency management system [42].

Casola et al. [43] describe the architecture of a spatially and sensor type-constrained Early Warning System which combines data from multiple sensor networks and low-level services. The architecture consists of a data modelling and access service, a computing and simulating service, and an alert and notification service. The proposed semantic sensor web architecture aims at ensuring interoperability of different sensor platforms together with contextual datasets and services that operate on the published data, and therefore has the potential to provide the decision makers with more flexible solutions than other highly-customized early warning systems. Jirka et al. [44] identify the importance of accessing multi-domain semantically-enabled sensor information for efficient risk monitoring in a number of use scenarios. Our semantic sensor web provides the richer functionality for discovery, data access, and integration identified by Bröring et al. [31] as a requirement for disaster management or early warning systems.

The semantic registry service supports the registration of services and their datasets through the Registration interface. The deployed registry service, Strabon (Table 2), accepts rdf documents describing the interfaces supported by the service, and the spatiotemporal and thematic description of the datasets. These semantic descriptions are expressed with respect to the network of ontologies [46] depicted in Figure 1. For example, descriptions of sensor networks and corresponding observations refer to the Semantic Sensor Network (ssn) ontology [47]. Note that the registry service implementation is not limited to using terms from the ontology network.

The semantic registry supports the discovery of datasets by answering queries posed through the Query interface. The service implementation accepts queries expressed in stsparql: a sparql extension which has additional support for spatiotemporal constraints [60]. This enables dataset and service discovery based on the spatiotemporal and thematic coverage of the data, expressed in terms of concepts from the ontology network, rather than simply in terms of the functionality offered by the service. For example, an emergency response planner who is responsible for a specific region, say the Solent—the strait of water separating the Isle of Wight from the south coast of England—can specify their region using the relevant concept from the ontology network, viz. AdditionalRegions:Solent. The ontology concept contains a definition of the Solent region as a polygon represented using the Well-Known Text (wkt) format [61]. Alternatively, an environmental scientist who focuses on an area of coastline that exhibits particular features and which spans different regions can specify the exact region directly.

The queries posed to the registry service can request any information that is stored in the registry. The information returned is either in the form of sparql bound variables or an rdf document, depending on the query posed. Thus, the client can retrieve only the endpoints of selected services or all the information stored in the registry about a service. Figure 4 shows an example query posed to the Strabon registry service to discover the endpoint reference and service type of all data sources for the Solent that provide data about wave height sensor readings. Lines 13 and 14 declare the area covered by the dataset, while line 15 declares the region of interest to be the Solent. The FILTER on line 16 ensures that the dataset covers the Solent region. The results are returned as sparql bound variables.

The data source component depicted in Figure 2 denotes three distinct types of data service: (1) streaming data services that enable access to sensor data as continuously updated streams of values; (2) stored data services that enable access to data stored in repositories, such as a relational database or a triple store, including sensor deployments that load their readings directly into a database; and (3) external data services that enable access to data via some defined service interface, e.g., an ogc Web Map Service for publishing map images (ogc-wms [71]), or an ogc-swe sos [15].

A key requirement for a sensor web is the ability to combine data from multiple sources. Existing approaches rely on either the end user manually combining datasets in a spreadsheet, or using data fusion or mash-up approaches which simply juxtapose datasets from multiple sources. The latter cases rely on the end user to visually interpret the result and the resulting data set has no coherent semantics. Such an approach can result in useful data but can be more laborious.

A key ability of the semantic sensor web is integrating and correlating data from heterogeneous sources: both in terms of the modality of the data (i.e., streaming and stored), and the representation of the data (i.e., the schema used). Through the Integration interface, the integration and query service (iqs Table 2) supports the creation of a virtual data source in which the data from multiple physical data sources appear to co-exist in a single data model. The virtual data source can be queried through the Query interface and query answers retrieved through either the Data Access or Subscription interfaces.

The iqs is configured to expose an ontological view over a set of data sources through a mapping document. The mapping document relates the data conceptualisations exposed by the data sources to a global data model. The mappings are expressed in terms of selections and transformations over the data sources, and can be created either manually or with the help of a mapping tool. For example, the iqs service deployed for the flooding application exposes the data published by the cco-ws service and the abp-ws service using the SSN ontology. Users and applications can pose queries expressed in sparql_Stream over the ontology. These are transformed, according the relationships expressed in the mapping document, by the iqs into queries over the data sources. The generated queries are then passed to the snee-ws service with the answer streams flowing back. Full details of the mappings and the semantic integrator implementation can be found in [30].

A motivating use case for the integrator, drawn from the flood surge application, is to expose sensor readings and associated metadata for the south coast of England. A user, most likely a domain expert, creates the virtual source by providing a mapping document to the iqs through the Integration interface which states how to relate the source streams of the cco-ws and the abp-ws together with the tables of the cco-stored to the ontological model of the SSN. The integrated data source is automatically registered with the registry service, making it available to all users. Any user can then pose queries over the resulting data source to explore aspects of the data, or indeed be informed of interesting events as characterised by queries over the integrated source. For example, it is desirable to be informed when a sea defence has been over-topped by a wave. This can be determined by a query that relates the wave height readings from the sensor network with the associated threshold value stored in the database. The query over the integrated observation model is shown in Figure 6 expressed in sparql_Stream. Line 16 of the query relates the data stored in the cco-stored database with the current sensor reading from the cco-ws, the keyword ‘NOW’ on line 6 limits the sensor readings to the current time-point. The query is evaluated by posing a translated query to the snee-ws distributed query processing service. The snee-ws service poses a query to the locations table of the cco-stored data service and correlates the results with the streams consumed from the cco-ws and abp-ws.

Note that the new data stream generated by the query in Figure 6 can be used to inform users whenever such an over-topping event has taken place. For example, it can be used as an input feed to an alert service such as the ogc-swe sensor alert service [9], as depicted in Figure 3.

The previous subsections have presented the core web services that form a service-oriented architecture, specifically those which comprise the data and middleware tiers of the semantic sensor web architecture (Figure 2). The focus of those services is to provide programmatic access to the data for the creation of orchestrations to enable discovery, publication, and integration of data. The top tier of the semantic sensor web architecture provides services which are domain-specific and user-facing. An example of such a service is the High-Level Application Programming Interface (hlapi) service (Table 2). The focus of the hlapi service is to support higher-level tools, particularly web-based applications and mashups. For example, to enable time series sensor data to be presented in a mash-up together with other contextual datasets. This is achieved through a linked data [75] approach to publishing sensor observations, received from the data services and semantic integrator, in combination with rest conformant representations specific to the geographic and environmental domain.

While it is possible to send and receive soap messages from code running in a web browser using a library such as CXF [76], this approach is, in general, not followed in mash-up development. Web application developers typically expect to retrieve data through a rest interface [21] supporting the four http operations, viz. get, post, put, and delete, that are supported in the execution environment provided by a web browser; services following this pattern are deemed “restful”. To make full use of the semantic content provided through the semantic sensor web while exposing data in a manner consistent with rest design, it is also desirable for an interface to follow the principles of linked data [75]. That is: (1) use uris as identifiers for resources; (2) use http uris so that resources can be looked up; (3) provide meaningful standards-based representations of the resources when they are looked up containing links to more data—also known as the follow-your-nose principle; and (4) include uri links to related resources to enable discovery through link navigation.

In the environmental area, many mash-ups and web applications are further characterised by an approach by which datasets are overlaid on a base map with each dataset displayed being transformed into a layer (as depicted in Figure 10 and explained in Section 5.2). To create these map layers, the web application needs to access the data through an interface that is supported in the restricted execution environment provided by a web browser, and in a format that can be converted to a layer in that restricted execution environment (e.g., a geojson array, or wfs gml). These formats are, when accessed through a rest interface, additional representations that complement those provided as linked data (viz. rdf).

Applying these complementary rest and linked data approaches over the ontology network described in Section 3, a High-Level api (hlapi) for sensor observation data has been developed [35,77,78]. It enables web applications to access and navigate the data (practising the follow-your-nose principle) using resources comprising the observations, sensors, and time-series collections of observations grouped by the property being observed, the gathering sensor, and temporal boundaries. Links are made and maintained between collections and observations—a single observation is likely to be included in several collections, and a collection may in turn be a constituent of several higher-level collections—and to externally defined linked data sources, e.g., relating sensor positions to geopolitical boundaries, or observed properties to their definitions in the domain. Representations include those needed for linked data applications (viz. rdf, also via sparql), for use within geographic applications and for layer generation (viz. o&m gml, geojson, wfs gml) and for general human-readable browsing (viz. html). The hlapi is implemented as a service which generates the structure of resources and links between related data resources according to the rules provided in the service configuration. This has two main parts: the alignment of the incoming data streams with a single data model, which is directly inherited from the integrator service (Section 4.3) when that is the providing data service; and the declaration of an api such that resources are appropriate to the specific data being published, e.g., defining collections of manageable size derived from observation frequency.

For example, to support mash-up developers in the reuse of sensor data published by the cco sensor network (Section 4.2), we have instantiated a hlapi service to provide access to the observations published by the virtual data source available from the integration service. The deployed hlapi service automatically generates uris for sensors and each observation as data is received from the integration service. It also dynamically organises, and creates as required, the collections to group observations according to their location, the property that is measured, and the time at which it was measured. A selection of resources from this example deployment are shown in Figure 7. A semantic web client might initially access the hlapi service using the uri for all sensor resources (A) (also Table 2). The client can follow the link to the Boscombe sensor resource (B) and request an rdf representation of the Boscombe sensor resource. This representation would contain a semantic description of the sensor in terms defined by the ontology network: including its capabilities, location, and annotated links to collections to which it has contributed observations, such as an annual collection of wave height measurement (C). The latest observation, say 9.30 pm on the 11th February 2011 (D) is accessible through a link. Alternatively a client may receive a link to a specific observation, such as (D). From this resource, the client can follow links to preceding or following observations of wave height from the Boscombe sensor, or to collections of which the observation is a constituent. The rdf representation is best used for semantically navigating the dataset due to library and tooling support. However, once the desired resource is located, the client can request any representation, e.g., geojson to create a layer, through content negotiation.

Environmental models that forecast the behaviour of the sea-state have the potential to predict future flooding events (within given error margins): specifically where, when, and how severe they may be. These models are computationally expensive to run and depend on data from a wide variety of data sources including sensor data, weather feeds, and data stored in databases. In the context of forecasting flooding events and planning a response, three environmental model services have been developed. These models forecast the sea-state, likelihood of over-topping or breaching flood defences, and the water levels on the flood plains. The output of the models are exposed to applications using the semantic sensor web as layers published by ogc web mapping services (ogc-wms) [71] which have their semantic descriptions registered with the registry service.

The first service models the mean wave height and sea level for the next eight hours. The model uses sea-state data from the cco sensor network together with meteorological data as input. The result is a finite element mesh which predicts the sea-state (level and wave heights) at each point on the mesh and is represented as a raster grid. The raster grid output format (GeoTIFF) is exposed as a collection of layers distinguishable by their order of precedence and a timestamp through an ogc-wms.

The second modelling service uses the output of the sea-state forecast model together with information stored about sea defences in databases such as the National Flood and Coastal Defence Database (nfcdd) of the UK Environment Agency [3]. The input data is processed using an empirical over-topping formula [84] to predict the probabilities of sea defences being over-topped. The output of the model is a collection of ESRI ASCII Grid files which can be served by an ogc-wms.

The final modelling service predicts the depth of water on the flood plains in the event of an over-topping event. It runs the LISFLOOD-FP inundation model [85] using the tidal water levels provided by the sea-state modelling service. The output is a raster grid showing the maximum forecast flood level for each cell at each time point. The result is again made available as map layers through an ogc-wms.

Tidal surges and the resulting flooding have the potential for devastating effects to businesses and lives. A wide range of users, including emergency response planners, harbour masters, and members of the public, need to be supported in interacting with the data in these situations. We have developed a web based application, i.e., one that executes in the limited environment offered by a web browser and only permitted to make http calls, which enables users to discover data sources based on their spatiotemporal and thematic content, and to juxtapose that content as layers on a map. Screenshots from the application are shown in Figures 8, 9, 10, and 11, and will be discussed in the remainder of this section.

The application exploits the functionality provided by the services of the presented semantic sensor web: specifically the ability to discover datasets and services, and to orchestrate the services to integrate heterogeneous data sources and dynamically publish the resulting dataset through a rest interface. For example, the application can interact with data in native web formats, such as geojson, by using an appropriately configured hlapi service instance (Section 4.4) to return observations through a rest interface. In turn, the hlapi service instance can use the semantic integration service (Section 4.3) to retrieve data stemming from multiple heterogeneous data sources, both in terms of modality and data model, as a unified virtual data source which presents its data as instances of an ontology.

In this section we describe the web application and the issues faced in its development. The application is an exemplar of the type of mash-up that can be developed on top of the semantic sensor web. The web application is available from http://www.semsorgrid4env.eu/services/dynamic-demo and http://www.semsorgrid4env.eu/services/static-demo. The latter provides a more stable demonstration interface highlighting stable functionality, while the former aims to be as dynamic as possible, at the potential expense of stability/usability.