Information coming from sensor networks is being increasingly used in a variety of systems (decision support systems, information portals, etc), normally combined with information coming from more traditional sources (e.g., relational databases, web documents, etc). However, existing ontologybased information integration approaches cannot be easily used for this combination task since they are mainly focused on the integration of information coming from these traditional sources, and do not support sensor network data. In this paper we make a first step towards enabling the inclusion of sensor network data into these integration approaches, with the automatic generation of data wrapping ontologies for sensor networks. Our approach extends existing ones used for extracting data wrapping ontologies from relational databases, using the schema of sensor network queries and external ontology search and relation discovery services.
Sensor networks generate large amounts of heterogeneous data that can be used in a
range of systems, from providing information about temperature and humidity in a
piece of land to monitoring the heart rate of a person, to give a few examples. With
this increase in the amount of data available, and with the subsequent increase in the
range of applications that make use of this data, new challenges in data access and
integration arise. Traditionally, many data integration problems have been approached
through the use of ontologies [
Ontology-based information integration approaches make use local ontologies,
more commonly known as putative [
None of these methods has focused though on the automatic construction of
ontologies from data coming from heterogeneous sensor networks, even considering
that the problem of automatically generating ontologies from sensors is similar to the
case of extracting ontologies from relational databases. Hence, we propose to use and
extend one of these approaches for the specific case of sensor data. More specifically,
we use and extend Tirmizi et al’s approach [
In order to illustrate our approach, we present an example of how to derive a data
wrapping ontology from a sensor network system based on a well-known benchmark
(the Linear Road benchmark [
This paper is organized as follows: In Section 2 we present the Linear Road Benchmark, which is the running example, used throughout this paper. Section 3 describes how an ontology can be generated from a sensor network. This section is divided in several blocks according to the degree of complexity of the ontology that is being generated. Finally, Section 4 we present conclusions and future work
The Linear Road Benchmark is a well-established benchmark for Data Stream
Management Systems [
Arasu et al describes the Linear Road benchmark, which is used as basis of a
running example for queries in the Continuous Query Language (CQL) language [
PosSpeedStr(vehicle_id/* unique car identifier speed, /* speed of the car x-pos); /* coordinate in express way */ */ */
We also expand our running example by adding a new base relation Vehicles, which would be a relation with details of vehicles. This base relation is not part of the original benchmark, however we find the need to add this relation in order to show results in the following sections.
Vehicle(vehicle_id, /* primary key */ model, /* model of the vehicle */ license_plate); /* license plate of vehicle */
Fig. 2. Schema of PosSpeedStr stream.
This benchmark considers a 100 mile long highway divided in one hundred 1-mile
segments. Vehicles only pay a toll when they enter a congested segment. A segment
is congested when the average speed of all vehicles in a segment over the last 5
minutes is less than 40 mph. The objective of this benchmark is to calculate the toll
that each vehicle is supposed to pay. Due to the fact that calculating tolls for each
vehicle is fairly complex, the final desired query is expressed using several derived
queries, as shown in Figure 2. For example, the query TollStr is created by a
combination of queries on VehicleSegEntryStr, SegVolRel and
CongestedSegRel.
We describe the meaning of each query in Table 1. Each of these queries results in
either a Stream or a Relation. The exact queries in CQL and the different type of
Stream and relation operators can be found in [
This section presents our proposed method of generating an OWL data wrapping
ontology from sensors. We assume the following formal definitions of Arasu et al [
Definition 1 (Stream) A stream S is a (possibly infinite) bag (multiset) of elements (s, t), where s is a tuple belonging to Q, the schema of S and t ∈ T is the timestamp of the element.
Definition 2 (Relation) A relation R is a mapping from each time instant in T to a finite but unbounded bag of tuples belonging to Q, the schema of R. It is similar to the relation of the standard relation model.
Definition 3 (Base Streams) The source data stream that arrives at the Data Stream Management System (i.e PosSpeedStr) Definition 4 (Derived Streams) The intermediate streams produced by operators in a query (i.e. SegSpeedStr, VehicleSegEntryStr, TollStr)
Definition 6 (Derived Relations) The relations produced by query operators (i.e. ActiveVechileSegRel, CongestedSegRel, SegVolRel) Definition 7 (Derivation of Queries) A derivation of queries (DoQ) is a directed graph D = (V, A) where V is a set of base or derived streams S and base or derived relations R, which act like nodes, and A is a set of ordered pairs of vertices. Figure 2 is a DoQ.
Our proposed method consists of three phases. First, we generate an ontology from the base streams and base relations. This phase is very similar to the generation of ontologies from relational databases, hence the same technique will be applied. Second, we generate another ontology from the set of derived streams and derived relations through a novel approach. Finally, both ontologies are combined into the final data wrapping ontology.
We have defined a number of predicates to aid in the process of defining transformation from base streams and base relations to an ontology. There are two sets of predicates: Sensor predicates and Ontology predicates. The sensor predicates (see Table 2) determine whether an argument matches a construct in the domain of sensors. The ontology predicates (see Table 3) determine whether an argument matches a construct that can be represented in an OWL ontology.
Following [
Class(x) BaseStr(x)
Class(x) BaseRel(x) Example of Rules 1 and 2:
Rule 1 identifies the base stream PosSpeedStr as an OWL class.
An object property is a relationship between two classes in a particular direction. Because sets of sensors are not explicitly related, as it occurs with relational tables through foreign keys, the existing rules from Tirmizi et al. cannot be similarly applied.
The primary key of the base relation Vehicle has the same identifiers used in the PosSpeedStr base stream. Taking this assumption into consideration, if base streams and base relations share the same attributes, then that attribute can be mapped to an OWL Object Property. The domain and range of the property could be any of the resulting OWL Classes.
ObjP(x,r,s) FK(x,r,x,s) Example of Rule 2:
Given the stream PosSpeedStr and the relation Vehicle, Rule 1 and 2 would map PosSpeedStr and Vehicle as OWL classes. Furthermore, because PosSpeedStr and Vehicle have the attribute vehicleID in common, this attribute would be mapped to an OWL Object Property. PosSpeedStr could be the domain and Vehicle the range, or vice-versa.
A datatype property is a relationship between a class and a literal. Every attribute of a base stream or base relation is mapped to an OWL Datatype Property.
DataTP(x,s,type(x)) NonFK(x,s) where type(x) is a function that maps an attribute x to its corresponding XML datatype.
Example of Rule 3:
The attributes speed and xPos from PosSpeedStr would get mapped as OWL Datatype Properties with domain PosSpeedStr.
The resulting ontology from this approach is shown in Figure 5. The ovals are OWL classes and the squares are the range of the OWL Datatype properties. These squares are blank because in this phase, it is not possible to identify the range (integer, float, etc) because it is not specified in the schemas. This issue will be dealt with in the following phases.
Derived streams and derived relations are produced by query operators, and have been
derived originally from base relations and/or base streams [
In this second phase, we intend to identify more semantics through the derived
streams and relations. This phase makes use of external ontology search such as
Watson [
The ontology generated in phase 1 lacks important classes and relationships in this domain. For example, requirements such as: a vehicle has a speed, unit of speed (km/h or mph), a vehicle pays a toll, or a vehicle is located in a segment, are not represented in the ontology from phase 1. In this step, we present a heuristic that analyzes the derivation of queries in order to identify these types of missing classes and relationships.
Table 1 shows all the queries used in order to derive the final query. Figure 2 shows a graph that represents the derivation of the queries shown in Table 1. In this step, we proceed to extract the unique attributes across all the queries in a DoQ. For our running example, these attributes would be:
{ VehicleID, Speed, XPos, SegNo, NumVehicles, Toll}
The previous step extracted all the unique attributes from the queries. However, at this moment, there is no way to identify the role of these attributes in an existing ontology because these could be either classes or properties. Therefore we consider these attributes as entities.
Definition 7 (Entity) An entity is a unique attribute x extracted from a DoQ which may correspond to an OWL Class, OWL Object Property, OWL Datatype Property or instance.
Each query in a DoQ is either a stream or a relation. The schema Q of the stream or relation has a series of attributes. We proceed to create binary relationships between all the attributes of each schema Q, which have at least two attributes.
PosSpeedStr(vehicleID, speed, xPos) SegSpeedStr(vehicleID, speed, segNo) ActiveVechileSegRel(vehicleID, segNo) VehicleSegEntryStr(vehicleID, segNo) CongestedSegRel(segNo) SegVolRel(segNo, numVehicles) TollStr(vehicle, toll)
VehicleId ↔ Speed VehicleId ↔ xPos Speed ↔ xPos VehicleID ↔ Speed VehicleID ↔ segNo Speed ↔ segNo VehicleID ↔ segNo VehicleId ↔ segNo No relationships segNo ↔ numVehicle vehicleID ↔ toll
Given all the entities from Step 2.2 and the relationships between the entities from Step 2.3, we identify the unique relationships and consequently create an unlabeled bidirectional graph as shown in Figure 6.
Ontologies can be considered as directed graphs with labeled edges. However, the graph in Figure 6 is not an ontology for several reasons. First, in order for it to be converted into an ontology, we need to determine what each node means. For example, the node speed makes sense being an OWL Datatype property with domain Vehicle. This would mean that the node vehicleID makes sense to become an OWL Class.
Second, the edges are bidirectional and unlabeled; therefore there is no knowledge about the domain and ranges. For example, the nodes vehicleID and segNo could be both considered as OWL Classes. Therefore the edge between the two nodes would be considered as an OWL Object Property. This property could then have a label isLocatedIn with domain vehicleID and range segNo. Identifying the labels of the edges is another issue. Either a relationship discovery system can give you a series of possible labels (hasSpeed, hasMaximumSpeed, etc), or a human user needs to label the edges manually.
Third, this graph presents nodes and edges that may not make sense in the real world to a user, for example the relationship between the nodes “segNo” and “speed”.
In this step, these mismatches need to be identified and the graph refined into an
ontology. In order to do so, we propose to identify the relationship between two
entities relying on existing background knowledge and ontologies on the Semantic
Web. One way to do this is using Scarlet [
Therefore, our future work is to take the lessons learned from Scarlet and extend the use case in order to discover relationships between two generic entities. For example, given two entities vehicle and speed, there is sufficient background knowledge on the Semantic Web to determine that vehicle is a concept and hasSpeed is a datatype property with domain vehicle and range float. Furthermore, it would be possible to discover the appropriate labels for classes and properties. This approach would then fully automate the process of refining the graph into an ontology. The final result of manually refining the ontology is shown in Figure 7, which we acknowledge can be automated by applying the techniques previously proposed.
The outcomes of phase 1 and phase 2 are two different ontologies that complement each other. The final step of this process it to merge both of these ontologies. The result of this process is shown in Figure 8.
We have described a method for the automatic generation of data wrapping ontologies from sensor network data. By automating this generation process during runtime instead of design time, it may become easier to integrate data from sensor networks that are not known a priori. This method extends one of the existing methods for the generation of data wrapping ontologies from relational data sources, making appropriate extensions that are related to some of the specific characteristics of sensor-based data. We have illustrated the application of our method with an example coming from a well-known benchmark for data stream management systems, the Linear Road Benchmark, so as to highlight the main differences with respect to ontology extraction from relational data sources and to provide examples of some of these characteristics.
This is still work in progress, hence there are many limitations and open challenges that need to be addressed in the future. First, our illustrative example has only shown the feasibility of applying our method in simple scenario. In order to be able to claim the adequacy of our method for a more generic kind of settings involving sensor networks, we need to make more extensive tests in other scenarios. For this reason, we will analyze data coming from sensor networks available in services like sensorbase2 or pachube3, and we will make more extensive tests that will allow us determine the quality of the generated ontologies, especially in terms of their adequacy for the task of enabling better data integration. The design (and subsequent execution) of these experiments is complex, due to the high variety in the amount and 2 http://sensorbase.org/ 3 http://www.pachube.com/ complexity of data integration tasks that can involve these sensor networks. Besides, another open problem with this type of information is that it is still difficult to find good public sources for sensor network information.
Second, proposed method does not take advantage of the fact that it is dealing with sensor-based information. Although, as expressed in the introduction, the domains in which sensors are used are very broad, most of the measurements that they take are related to physical quantities (temperature, speed, humidity, etc.). Hence restricting or prioritizing somehow the domains in which the external ontology search and relation discovery services are used may increase the accuracy of the obtained results. This could be also done by allowing simple annotations from human users to be used also as inputs.
Spatio-temporal aspects of sensor-based information are also very relevant when it
comes to processing (and integrating) information from them. Every tuple generated
by a sensor network in response to a query will normally have a timestamp associated,
together with, possibly, some additional spatial information (e.g., GPS coordinates).
Hence every instance of the data wrapping ontology that may be generated from the
sensor network should have that additional information associated to it, and this
information may be used in the integration process. The ontological representation of
time and space may be done in different ways, either by using specific
spatiotemporal ontologies, or by using extensions of the RDF and OWL models, such as the
one proposed for time by Gutiérrez et al [
Finally, measurement units are also a major source of heterogeneity when dealing with this type of information. It is not always easy to determine which is the measurement unit that a sensor network is using when providing data for an observation. In fact, this information comes in many occasions attached to the written specifications and manuals of the deployed sensors, and is not available as part of the schema or metadata that is attached to it. This problem would be easier to deal with if sensor networks provided a more homogeneous set of metadata to describe the measurement units that they use, together with any other type of useful information. Other possibilities would be related to the combination of data with existing relational data whose units are known, although this is not the most common case either. Acknowledgments. This work has been supported by the European Commission projects SemSorGrid4Eng (FP7-ICT-223913).