Sensors and the real-time data they produce are novel sources of information which need to be integrated into the Semantic Web at very large scale. Most of the time such data is locked inside speci c applications and only accessible within organizational boundaries. Publishing and integrating sensor data across these islands is di cult and laborintensive. In this paper we present an approach and an infrastructure which makes sensor data available following the linked open data principle and enables the seamless integration of such data into mashups. SensorMasher publishes sensor data as Web data sources which can then easily be integrated with other (linked) data sources and sensor data. Raw sensor readings and sensors can be semantically described and annotated by the user. These descriptions can then be exploited in mashups and in linked open data scenarios and enable the discovery and integration of sensors and sensor data at large scale. The user-generated mashups of sensor data and linked open data can in turn be published as linked open data sources and be used by others.
If we de ne a sensor as a data source which produces a sequence of data items over time { a data stream { then we already have a very large number of sensors deployed all over the planet. Following this unifying de nition beyond the \classical" de nition of sensors, a very large number of sensors already exist and have been deployed: Each mobile phone already hosts a number of sensors, such as GPS, camera, Bluetooth, WLAN, accelerometer, etc., standard computers and CPUs carry a multitude of sensing devices which are already used for remote administration at large scales, large deployments of sensors in the environmental domain, for monitoring tra c, for logistics, supply chain management, etc. exist already and this is not the end of the development.
Gartner predicts that \By 2015, wirelessly networked sensors in everything we own will form a new Web. But it will only be of value if the `terabyte torrent' of data it generates can be collected, analyzed and interpreted."1 Making sensorgenerated information usable as a new and key source of knowledge will require its integration into the existing information space of the Web.
Besides the problem of coping with the vast amounts of data which will be produced, most of these data sources are not easily accessible to enable integration with other data. One of main reasons for this may be the fact that research in the sensor network area has focused on routing, data aggregation and energy consumption inside a single sensor network while the integration of multiple sensor networks has only been studied to a limited extent. On top of that, as the price of commodity sensors is rapidly decreasing we can soon expect large numbers of autonomous sensor networks being deployed. Hence, there is the need for platforms to publish and share sensor data in an easy way and to reduce the cost and complexity of sensor data access and integration.
Several attempts has been made to remedy the problems of collecting and publishing sensor data online, for example, SensorMap2, EarthScope3, and Earthcam4, etc. However, these data sources are di cult to integrate and to make them accessible to other applications. Moreover, sensor discovery, which is vital in the large scales, is impossible with most providers or rarely supported. Additionally, to the best of our knowledge, no research is trying to target support for the casual user who does not have full programming skills while still wants to have access to sensor information and integrate it into Web applications. This gap may prohibit very creative and useful applications of sensor data by non-technical users.
Sensed data is often archived or streamed as raw data, but rarely associated with enough metadata describing its meaning. Meaning of sensor data includes the feature of interest, the speci cation of measuring devices, accuracy, measuring condition, scenario of measurements, location, etc. Such metadata is essential when the user is confronted with large numbers of sensors and gigabytes of sensor data. Especially, when the user does not have clear ideas about what he/she is looking for, he/she can start a quite general search of relevant concepts and narrow it down based on semantic descriptions and their relations. For example, a city planner may want to assess and monitor quality of life in certain area. To do so, he/she can start to navigate from his/her own domain of knowledge,then nds out that quality of life depends on noise, sunlight, humidity, air pollution, tra c condition, etc. Then he can lter out which sensor sources can provide such data in his area of interest.
To enable easy access to sensor data to non-technical users, we propose our SensorMashup platform as a step towards the vision of \The Web of Thing". Our platform will enable the publishing of sensors and the associated data sources as Web citizens under URIs. These published entities, called Sensor Mashups, will be created and then linked to ontological concepts, other (virtual) sensors and other Web citizens under URIs through a visual composer. This phase will create useful linked data for sensor discovery. Hence, the visual composer is able to provide an intuitive GUI which allows users to navigate and explore sensor data sources by following semantic links and using faceted-browsing techniques. After having found the relevant sensor data sources, the user is able to combine
them visually in a work ow editor and then connect them to data processing operators to create a new Sensor Mashup. Sensor data published from our platform can be accessed through SPARQL endpoints and RESTful web services under JSON, XML, RDF formats which can be easily used by various applications. Triple-based query support enables semantic-based traversal over sensor data, thus makes the data ltering and correlating more sophisticated than those of previous approaches. Triple-based query support is only used to enable access via standard mechanisms while internally we use compressed data representations for e ciency reasons. 2
A large number of use case scenarios have been proposed already but to the best of our knowledge none takes into account linked open data as a principle for the seamless integration of physical and virtual data. For our motivating scenario we use the notion of \integrated presence management". The goal of integrated presence management is to combine sources of virtual presence, for example, calendar information, online status in Skype and chats, in IP telephone systems, collaborative environments, etc., with information about physical presence, for instance, location determined via GPS, WLAN, Bluetooth, motion detection sensors, RFID, noise sensors, etc., to build up an integrated view of an entity's presence and availability. This information can then be used in simple yet technically quite sophisticated scenarios. For example, if information from the user' calendar is combined with physical location, then appointments can be automatically changed if the system somehow can use users' current physical locations to infer that all participants are not able to get to meeting location in time, or, despite being seen available on Skype, on the phone, and in a chat client, a user may have an ongoing meeting which can easily be determined via audio sensors and/or the physical proximity of RFID tags in the user's o ce. In more sophisticated scenarios, someone may leave a location-based noti cation for a user who is not in his o ce and which will be delivered as soon as the addressee gets close to this location again, e.g., his o ce. Besides these user-centric scenarios, a plethora of scenarios also exists for the management of things, e.g., for a meeting not only the participants need to be there but also resources like projectors, etc. which are movable and have a usage context.
It is quite simple and straight-forward to come up with further more complex scenarios based on these basic scenarios, for example, if also pro les, policies, and privacy are taken into account. However, the underlying requirement in all these scenarios is the need for exible, transparent integration of data from diverse sources and sensors. It can be accomplished very e ciently with a linked data approach for sensor data sources. 3
In order to link real world data captured by sensors to the Web, it has to become
a form of Web resource. Sensors and their data elements can become Web
resources by publishing their data on the Web using linked data techniques5. When
adopting such an approach, sensors and their data are assigned a URI which
enables the creation of links to other Web entities. Using a similar method to
Stream Feeds [
As sensors and their data elements have URI identi ers, we are able to link them into a virtual RDF graph as shown in Figure 1. The graph is called a virtual graph, because the whole graph is not materialized and stored in a triple storage. It is constituted by interlinked subgraphs controlled by sensor mashups. A mashup's metadata stored in the metadata repository de nes how the raw sensor data in a data stream can be linked to domain knowledge and external linked data. This is driven by a set of ontologies which are used to capture facts and the data model of the sensor information system. This linked metadata will guide the nding of triple patterns needed from the virtual RDF graph of sensor data.
Sensor data from multiple sources can be fused to create derived sensor data
sources. We are later able to use these fused sensor data sources in the same
way as the original sources. The process of composing a new sensor data source
from existing ones is facilitated by the sensor mashup composer of SensorMasher
which enables the user to rapidly create new sensor data sources in a visual way.
The composing process generates the mashup's con guration used to controls the
data ows from sensors to data streams and from data streams to data processing
operators. A mashup's con guration is also stored in the metadata repository.
With the annotated sensor data streams, the composing operation can exploit
existing approaches proposed, such as [
The most important operation when integrating data is exploring existing
data sources to nd out which ones are of interest. The triple-based query
processor will facilitate the semantic-based sensor data exploration. A faceted
browsing functionality helps the user to lter sensor data based on relevant facts. For
example, a user can lter by sensor type as classi ed in the sensor taxonomy,
or by sensor location by choosing an area in a map, or by sensor speci cation
(sensor type, physical context, calibration parameters, precision, accuracy), etc.
The user can navigate from a data set to other data sets by following semantic
links. Under the hood, the exploration and navigation actions are translated into
complex queries (spatial, temporal and thematic queries) to the query processor
as described in [
Along with a URL pattern for direct access to each sensor's data elements, SensorMasher also provides a SPARQL endpoint to query all types of sensor data. To identify a sensor, a query over the semantic descriptions of sensors can be posed to this SPARQL endpoint, for instance, \ nd the nearest webcam from a tourist venue." Queries over sensor data are also supported, for example, \ nd the latest air temperature reading if the average humidity in last 3 hours was higher than 80%."
Sensor and sensor data are also accessible via Web services which conform
to Sensor Web Enablement (SWE) standards [
The SPARQL endpoint, web services and streaming protocol allow a SensorMasher node to integrate sensor data from a remote one transparently. Hence, a set of autonomous SensorMasher nodes will create a federated sensor information system from which sensor data can travel and be queried across the borders of single systems. 4 4.1
and vice versa. Sensor data can be streamed from IP-based connections in both push-based and pull-based fashions. Using the push-based paradigm, the wrappers listen and wait for the sensor data being actively streamed from a peer. Alternatively, in the pull-based paradigm, the wrappers periodically pull the data from a remote peer, for instance, by making an HTTP request. As soon as a new reading arrives, the wrapper pushes the data into the appropriate stream in the DSMS component.
Sensor data can arrive in the ways which cannot be directly handled in
persistent storage systems such as relational databases. Data streams di er from
conventional stored relational models in several aspects. The data streams not only
have data elements arriving continuously but also potentially have unbounded
size. Additionally, the order of data elements arriving within a data stream or
across multiple data streams is unpredictable and not necessarily arranged.
Furthermore, as soon as an element in a data stream has been processed it can
be discarded or archived, thus it cannot be no longer easily retrieved, unless it
is explicitly stored in memory, which typically is small relative to the size of
the data streams. To deal with these characteristics, data stream management
systems (DSMS) are designed for monitoring, combining and analyzing and
correlating streams of data [
The fusion operators implement typical sensor data processing operations
including data ltering, data alignment and association, correlation and classi
cation. They employ algorithms and techniques used in multisensor data fusion
process models [
The Sensor & Mashup manager component controls the data ow from sensors to the DSMS and from the DSMS to the fusion operators and vice versa. The Sensor & Mashup manager also provides interfaces to the metadata repository such as editing and querying metadata under a triple-based model. It also enables the deployment of sensor mashups by initializing associated wrappers to feed data from sensors. It is also responsible for providing access control via the User Manager component. The User Manager manages pro les of the mashups' authors as well as the mashups' sharing policy.
The Query Processor component supports triple-based queries over sensor data from both the DSMS component and the metadata repository. To process such queries, it has to follow the mapping rules that are generated from the metadata repository. These rules guide it in delegating continuous queries to the DSMS component as well as triple-based queries to the metadata repository.
The Explorer component provides a GUI enabling the user to explore sensor data on a map or along semantic links. This Explorer also includes a facet-based lter over triple-based sensor data. This semantic exploration is empowered by APIs, the Query Processor and Sensor & Mashup Manager components and Web services provided from remote SensorMasher nodes. The Web interfaces provided include a Web services interface, a SPARQL endpoint and HTTP requests from URL-based Sensor Web sources. The Mashup composer is used for visually composing sensor mashups by creating a work ow connecting sensor data sources with fusion operators. In composing processes, the user has to employ the Explorer component to search for the input data sources required.
The SensorMasher platform can be deployed in a federated fashion whereby autonomous nodes are able to query each other via Web interfaces. The streaming APIs provided by wrappers allow a local node to stream data to a remote one and vice versa. 4.2
Using the Sensor model of the SensorML6, we abstract the sensor model, sensor data model and data processing components in Figure 3, and represent this model in OWL-DL. In this data model, the sensor mashup is the key abstraction of the SensorMasher. We de ne a sensor mashup as an observation (Observation class). An observation is conducted to observe an feature of interest of a real world object. For example, \ nding vacant parking spots in an underground parking lot" is an observation which targets the real world object \underground parking lot" and is interested in the feature \vacant parking spots". A feature of interest may have several properties which can be measured by sensing devices, called ObservableProperty. In the previous example, the observable property is \car in parking lot or not". The ObservableProperty class is the basic class that describes the meaning of sensor outputs. For example, Temperature and Humidity are sub-concepts of ObservableProperty, that represent the meanings of temperature and humidity readings.
The observation is facilitated by a sensing process represented as AbstractProcess. The subclasses of AbstractProcess describe 4 types of sensing processes. The rst one, SensorComponent, is for representing an atomic sensor to detect a single sensing signal. The second one is for presenting a sensing system (SensorSystem) containing a set of atomic sensors. For instance, a weather station7
is a sensing system which has autonomic sensors such as thermometer, barometer, anemometer, etc. The third one (ProcessModel) is for representing fusion operators as software processes that are used to process sensor data. The last one is the composition of sensing processes, called ProcessChain. This process also contains a list of links to describe the ow of sensor data streams from constituted processes. The sensor mashup often uses instances of ProcessChain to de ne how the data from sensors is to be connected to the fusion operators along the prede ned work ow to generate a new output data stream. This instance plays the role of the mashup's con guration.
As mentioned earlier, we use the DSMS for managing sensor data streams and do not expose all sensor readings as materialized triples. The triple-based query over sensor data linked into the virtual RDF graph mentioned in Section 3 is parsed to create a query plan consisting of a set of subqueries. There exist two types of subqueries: continuous queries over stream data and triple-based queries over sensor metadata. The query planner will delegate the corresponding subqueries to the DSMS and the triple-based query processors of the metadata repository. The query aggregator later composes the individual partial query results into the nal result.
The user is able to explore all facets of sensor data by traversing virtual RDF graphs of the federated SensorMasher nodes. After identifying the relevant streams, the user can connect them to fusion operators to generate the nal sensor mashup with the expected output streams. The mashup will be deployed by creating data streams associated with work ow fusion operators into the DSMS component and storing metadata as triples in the metadata repository.
As the sensor mashup's con guration is represented as triples, the sensor mashup composing component is therefore an RDF graph composer. The nal component required is a tool for dragging RDF nodes to a canvas and connecting them to create triples. As such, the user is able to drag sensors, mashups and fusion operators (identi ed by URIs) into the composer's canvas, then connect them into a work ow, and nally, save the work ow as a graph. Using this methodology, adding facts to sensors and sensor data is simply a process of creating triples. 5
Based on the above design, we have implemented SensorMasher. The system
is available at sensormasher.deri.org. Similar to some related DSMSs such
as TelegraphCQ [
We use two main ontologies to control the SensorMasher: the core ontology and the extended ontology. The core ontology represents core concepts and properties which are the same for every SensorMasher deployment. The extended ontology contains subclasses of the core ontology which can be customized based on speci c requirements. In our prototype, the extended ontology was built by using concepts and properties from the Physical Property taxonomy in the SWEET Property ontology8 and the SANY Sensor Taxonomy9. To support implicit properties inferred from ontological relationships such as subClassOf, subPropertyOf, inverseOf, etc. in answering SPARQL queries, we use the Jena in-memory reasoner to reason about these two ontologies at class level to generate query mapping rules. For example, if we query for sensors that can measure meteorological measurement, the result will contain sensors that can measure temperature, humidity, wind speed, etc.
The Mashup Composer and Explorer are implemented as Ajax-based web applications. Screen shots are shown in Figure 4 and Figure 5. The user is able to nd and explore sensor data sources by drawing a polygon on the map to locate the area of interest. The user is also able to drill down into the result set by using facet lters on types and properties. Furthermore, from an result item, it is possible to follow its relationships to discover other items which which have
semantic links to the previous one. If the user has identi ed a sensor data source of interest he can drag it into Mashup Composer to later wire it into his mashup.
After a mashup has been deployed in a SensorMasher node, it has an associated URL pattern to request di erent types and formats of data. For instance, URL http://sensormasher.deri.org/resource/79 contains semantic description of a weather observation using the weather station mentioned in an example of Section 4.2 . This weather station uses a thermometer to measure temperate and an anemometer to measure wind speed. The left hand side of Figure 6 shows some RDF snippets of this weather station. In this description, along with the speci cation of the weather station, we see that the URL http://sensormasher.deri.org/data/185 is URL its latest reading. The right hand side of Figure 6 shows the RDF output of this URL with some links to the aforementioned sensor description. Via this URL, the corresponding sensor reading also can be retrieved in other formats such as RDF, JSON, XML, RSS, CSV, etc. by using HTTP negotiation, so that it can be consumed by various third-party applications such as mobile applications, scripting web applications, etc.
Figure 7 shows a sample query over real-time sensor data. This query requests
the \the temperature and location where the wind speed has reached 30 miles per
hour around the Cli of Moher". We also extended the 52oNorth[
Some e orts to improve accessibility to sensors are on the way as. Usually
the proposed approaches try to provide simple interfaces to publish and retrieve
sensor data via centralized portals. SensorBase11 enables the publication of
sensor data via HTTP POST and provides web services to query sensor data from
its relational database. In a similar fashion, Pachube 12 provides a RESTful
interface to stream real-time sensor data. Historical data and real-time data can
be retrieved via feeds in XML (EEML) or JSON formats. Along with web
services to publish and request historical and real-time sensor data, SensorMap[
Typically, the user is interested not only in sensor readings but also in facts and statements about them. Sensor data streams have some common properties such as deployment, design, sensor type, sensor capabilities, targeted phenomena, etc. On top of that, without the associated meaning, the user cannot decide whether a sensor reading is suitable for an observation. For example, ambient temperature readings would be inappropriate for a weather analysis which looks for air temperature readings. This is a general shortcoming of the above approaches. From a user's perspective, such facts and statements about data are signi cant in exploring and collecting information sources to meet the user's demands of monitoring and observing the proper real-world phenomena. In a real-life setting, the most important concern are the observed object and the observable properties of interest. Only then, a user would be concerned about which sensors are able to provide the required quality and quantity data. Hence, metadata about sensors and sensor data which supports this data using fashion is essential.
In response to this demand, the Open Geospatial Consortium (OGC)
proposed sensor and observation models based on XSD schema to specify
interoperability interfaces and metadata encodings that enable the real-time integration
of heterogeneous sensor webs into an information infrastructure. However, there
is a gap between the syntactic XSD of OCG's Sensor Web Enablement (SWE)
and the RDF/OWL-based metadata which is commonly used for representing
domain knowledge. To bridge this gap, Shet et al. [
Some e orts make use of semantic descriptions of sensor data streams to
automatically compose sensor applications and services. In 2006, Whitehouse et
al. proposed Semantic Streams [
Along these e orts of coping with sensor data interoperability and integration issues, we propose SensorMasher as the rst platform for publishing sensor data as linked data. Its mashup engine enables the user to visually explore and combine sensor data resources in a homogeneous triple-based data model. As sensor data is published as linked data sources, every single data element can not only can be easily accessed but also can it be annotated with meaningful linked data. Using linked metadata as semantic description of sensor data leverages the dynamic discovery, querying, exploration, navigation and combination of sensor data sources.
There are several challenging data management issues in Sensor Web
environments such as data ingestion, temporal and spatial data management, data
exploration, analysis and visualization, statistical modeling, data uncertainty
management, data interoperability and distributed, large-scale data processing [
The current version of SensorMasher uses SPARQL to query sensor data
streams. However, SPARQL is not expressive enough to address speci c data
stream issues such as window slicing, sampling operators, join and correlation
operators over streams, etc. Additionally, aggregating functions such as COUNT,
MAX, MIN, AVERAGE, etc. which are vital in stream data processing, are
not natively supported in the current version of the SPARQL working draft
[
Due to the lack of declarative query languages over triple-based data streams,
there exist no approaches to map this type of query to physical query plans. In
SensorMasher, we try to map SPARQL queries to query plans over the
continuous queries of the underlying data stream management system (DSMS).
However, additional optimization of query plans is required. Since a SensorMasher
node is accessible as an autonomous SPARQL endpoint, federating SPARQL
queries over distributed SensorMasher nodes is an inevitable need. DARQ [
The scalability of a SensorMasher node heavily depends on the scalability of
the stream query processor on top of the DSMS used by the platform. Medusa [
As the sensor data processing and integration in SensorMasher platforms is carried out in an autonomous and distributed fashion, data provenance is an issue which must be dealt with. Even though there have been various e orts investigating data provenance, inferring and computing origins of a derived sensor data source after it has gone through many processing phases such as summarization, aggregation, correlation, etc. are still open questions. Data provenance is especially complicated when dealing with federated queries where sensor data is transparently streamed from one autonomous node to another. By recording as much relevant sensor metadata as possible we can use semantic links to support the tracing of a particular piece of information to its origins and deciding how much to trust it.
The above discussion shows that this area requires signi cant research e orts in various aspects. We believe that SensorMasher can be used as an experimental platform to support practical experiments with the coming approaches and can integrate the research results produced in a straight-forward way.
This paper is the rst attempt to publish sensor data as linked data to enable dynamic discovery, integration, and querying of heterogeneous sensor data sources. The ontology-driven data model and related system enable the user to easily deploy, combine and annotate sensor data sources by using a visual composer and explorer without requiring expertise in sensor programing and sensor data processing. As a linked data citizen, SensorMasher enables linking real world sensor data to The Linked Open Data dataset cloud13. 9
This work has been supported by Science Foundation Ireland under the Lion project (SFI/02/CE1/I131)and by the European FP7 project PECES (FP7224342-ICT-2007-2). 13 http://linkeddata.org/