A Semantic Registry Method Using Sensor Metadata Ontology to Manage Heterogeneous Sensor Information in the Geospatial Sensor Web

Abstract

Efficient information management and precise discovery of heterogeneous sensors in the Geospatial Sensor Web (GSW) are a major challenge. Intelligent sensor management requires a registry service to store and process sensor information efficiently. In this paper, we propose a Sensor Metadata Ontology (SMO) to achieve a unified semantic description for heterogeneous sensors that is used to express sensor semantics. Through mapping between the sensor registry information model and the SMO, the sensor metadata could be stored with semantic information for the registry. The framework of a Sensor Semantic Registry Service (SSRS) has been successfully implemented for the registration and discovery of heterogeneous sensors. The results of GEOSENSOR-SSRS experiments show that the proposed semantic registry method can be used to enable sharing in an open distributed sensor network as well as to promote accuracy and efficiency of discovery.

1. Introduction

The Geospatial Sensor Web includes a large number of heterogeneous sensors that are connected to the Internet [1,2]. For example, approximately 10,000 weather stations, 1000 hydrologic stations, and 137 satellite sensors monitor the Yangtze River, thus providing considerable hydrological information for measuring water levels, temperature, and other conditions. Numerous related sensors exist [3,4]; these sensors are heterogeneous, comprising different types of formats. In this paper, we propose a semantic registry method and implement the registry service to manage these sensors.

The representative registry service is the Catalog Service for the Web (CSW) [5], which has specific registry information models such as the ebXML Registry Information Model (ebRIM) [6]. Previous research [7] has applied the CSW to registering sensors and algorithms. In the existing sensor registry service, the same terms or concepts have varied descriptions in different sensors. Thus, the synonyms described in SensorML [8] could be not recognized in the query of the sensor registry service, which leads to semantic conflicts. Consequently, the service could not improve precision and recall.

Improving the semantics of sensor metadata will assist in solving this problem. The concept of semantics has attracted many researchers because of its feasibility for intelligent information processing and interoperation. Semantics play a significant role in the Sensor Web [9,10,11,12]. A sensor registry service that adds semantic information will be useful for improving query precision. It will provide a better platform for managing sensor information. Some existing services provide semantic registration and discovery [13,14,15,16], which is generally implemented in two manners.

●

Integrating semantics into a registry information model (such as ebRIM) using three different methods: (a) mapping from Web Ontology Language (OWL) elements to ebRIM elements using EXtensible Stylesheet Language Transformations (XSLT) documents, as in the case of GeoNetwork (GN)-ebRIM [17]; (b) adding new classes, classification schemes, associations, and slots with semantic information to extend the ebRIM, as in the case of the George Mason University (GMU)-CSW [16]; and (c) disassembling the concept of ontology and relationships to extend the ebRIM [18].

●

Adding semantic information to a catalog using two different methods. One is to extend the catalog interface for supporting a semantically augmented query directly [19,20]. The other is to create semantic middleware for a catalog service [21] that does not change the service interfaces [22,23,24]. For example, the Sensor Observable Registry (SOR) [25] has to make a connection with a sensor discovery service (e.g., CSW) to achieve sensor discovery enhancements.

In summary, there are several limitations of the current methods: (a) the lack of synonym query; (b) use of an indirect semantic registry method; (c) support of a single sensor type, e.g., in situ sensors; and (d) use of a non-standard model, increasing the difficulty of re-use. Moreover, these services adopt a syntax description of the registry information models that lacks inference support in sensor discovery.

To solve these issues, this paper proposes a new semantic sensor registry method using a Sensor Metadata Ontology (SMO) that can be included in an OGC-CSW (Open Geospatial Consortium -Catalog Service-Web) catalog to enable semantic discovery. The remainder of this paper is organized as follows: Section 2 introduces the SMO, the proposed mapping from the ebRIM to SMO for storing sensor metadata, and the instances of the SMO. Section 3 describes the implementation of the proposed semantic registry service and results. In Section 4, the results of comparisons between the existing registry method and the semantic registry, as well as comparisons with other semantic registries, are discussed. Finally, the conclusions and future work are addressed.

2. Methods for Enabling a Sensor Semantic Registry

The flow of the sensor semantic registry is shown in Figure 1, primarily comprised of three stages:

• Model (steps 1–2): building a sensor metadata ontology (SMO).
• Data (steps 3–4): providing the mapping for storing sensor metadata in the ontology to obtain the data from the registry service.
• Experiment (steps 5–7): implementing the sensor semantic registry service (SSRS).

2.1. Model Ontology for the Semantic Registry

For representing the sensor metadata, the SMO requires the following features:

●

The pattern of the ontology describes a sensor in terms of its information, its data type, and the process element type it takes.

●

The content of the ontology includes the concepts and associations of sensor metadata from the description of the sensor model. Additionally, it captures the meanings, properties, and relationships of sensor resources.

To satisfy the above characteristics, based on the SensorML [8] and the meta-model [26], the SMO includes two modules: the conceptual sensor information (the blue icons in Figure 2) and the sensor metadata (the yellow icons in Figure 2).

• Module 1: conceptual sensor information
  According to previous research [8], the properties of sensor processing include inputs, outputs, parameters and methods. In the ontology, these process properties could be described by the “smo:Process” class, and other sensor properties could be represented by the “smo:nonProcess” class.

  ●

  The “smo:Process” class describes the conceptual properties of a process.

  ●

  The “smo:nonProcess” class includes three sub-classes for describing more detailed information than the sensor’s thematic features [26,27].

  (a)

  SensorTag: For sensor recognition, the “smo:SensorTag” and “smo:Identification” class are used as sensor tags.

  (b)

  ObservationCapability: A sensor is often described by information that includes its physical, measuring, and communication properties and the area observed by the sensor. For any sensor property, the performance of the sensor might be affected by prevailing environmental conditions as well as its position and location. These properties are modeled as observation capabilities. Thus, the observation capabilities of a sensor can be specified using related records. For example, we developed the “smo:capability”, “smo:geoLocation” and “smo:quality” classes, which are inherited from the “smo:ObservationCapability” class.

  (c)

  InteroperationService: To describe constraint information and to access the sensor, the “smo:Accessibility” class could reflect the fact that the observation capability of a sensor is affected by its position and location.

• Module 2: sensor metadata

  ●

  DataType: The types of data (described by the “smo:datatype” class) that describe the non-process information of a sensor. This part contains nine sub-classes: “smo:General”, ”smo:Property”, ”smo:timespaceRef”, ”smo:geoPosition”, ”smo:History”, “smo:Constraint”, ”smo:Contact”, ”smo:Interface”, and ”smo:associationClass”.

  ●

  ProcessElementType: The types of process elements (described by the smo:ProcessElementType class) describe the process information of a sensor, which includes the “smo:Input”, “smo:Output”, “smo:Method”, and “smo:Parameter” classes.

Moreover, there are a few relationships described in the ontology. The conceptual information of a sensor can be described by metadata, so the “describedBy” association could connect the “smo:nonProcess” with the “smo:DataType” class and link “smo:Process” with the “smo:ProcessElementType” class. Similarly, other associations between the classes of modules 1 and 2 were developed. For example, the sensor identification has general information, so there is the “hasGeneralInfo” association between the “smo:Identification” class and the “smo:General” class.

The SMO can describe some special sensor information, including the observation capability and interoperation service and the input used as well as the output data produced. Additionally, concepts for describing the data types of sensors are included as part of the sensor metadata. Relationships in the SMO can be utilized when searching for sensors. The ontology can be used to describe sensors of weather stations, hydrologic stations, and satellite sensors for monitoring floods. The ontology is a discovery-oriented application and facilitates the discovery of information relevant to sensors. The structure can be used to describe the details of sensors that are relevant to a particular application.

2.2. Mapping for Storing Sensor Metadata in Ontology

The ebRIM and GEOSENSOR-CSW model [7] have the following features: (a) the sensor metadata are stored by the structure of ebRIM, including the objects, slots, classifications and associations; and (b) the structure could not describe the relationships (e.g., the relationships of sensor metadata that are described in Section 2.1) among the sensor metadata elements. Thus, the ebRIM model stores the sensor information yet lacks the close relationships of sensor metadata.

For solving these limitations, the semantic registry method described in this paper is capable not only of representing the sensor metadata relationships through the ontology but also of transforming information from the registry information model into that of the ontology. Thus, we built the mapping between the GEOSENSOR-CSW model and the SMO based on the sensor metadata in the previous registry service [7]. According to the mapping, it transformed the instances of the registry information model into instances of the ontology. Then, the instances of the SMO can be directly stored into an ontology database such as the Oracle Database. Additionally, the mapping allows storage of information pertaining to sensors. It will enable concepts in the SMO to be instantiated with data available in the database. In this case, the previous registry information model could be represented entirely by semantic constructs of the SMO.

The mapping includes four parts:

• Mapping of the rim:ExtrinsicObject (basic attributes)
  The objectType attribute in the GEOSENSOR-CSW model maps to the “smo:SensorMetadata” class to describe the type of rim:ExtrinsicObject, e.g., where one of the object types of the sensor is “system”. The basic attributes of “system” include sensorID, a long name and a description, which could be mapped into the “smo:sensorID”, “smo:sensorLongName” and “smo:sensorDescription” classes of the SMO, respectively.
• Mapping of the rim:ExtrinsicObject slot (additional attributes)
  The slots of rim:ExtrinsicObject store detailed information pertaining to sensors, such as a short name, keywords, valid time, location, ObservedBoundingBox, inputs, outputs, and parameters. The mapping of the slots is shown in Figure 3.

  ●

  Steps (1) and (2) describe the mapping of short names and keywords.

  ●

  Steps (3) and (4) show the mapping of the attributes of valid time.

  ●

  Step (5) describes the mapping between the location attribute of a sensor and the “smo:sensorLocationClass” class.

  ●

  Step (6) expresses the “sensorBBOXClass” class that can store the area of interest observed by a sensor.

  ●

  Steps (7)–(9) represent that the inputs, outputs, and parameter attributes of a sensor could be mapped into the “smo:Input”, “smo:Output”, and “smo:Parameter” classes, respectively.

• Mapping of the ClassificationScheme
  There are attributes of rim:ClassificationScheme in the sensor registry model that classify the sensor information. We built four subclasses of the “smo:ClassificationClass” class to describe the classifications of “IntendedApplication”, “ServiceType”, “SystemType”, and “OrbitType”. The four subclasses in the SMO include “smo:SensorClassification_IntendedApplication”, “smo:SensorClassification_ServiceType”, “smo:SensorClassification_SystemType”, and “smo:SensorClassification_OrbitType”.
• Mapping of associations
  In the GEOSENSOR-CSW model, there are four sensor associations (ComposedOf, AccessibleThrough, InputConnection, and OutConnection). The related associations could be mapped into the “smo:SensorAssociation_ComposedOf”, “smo:SensorAssociation_AccessibleThrough”, “smo:SensorAssociation_InputConnection”, and “smo:SensorAssociation_OutputConnection” classes.

2.3. Instances of the Sensor Metadata Ontology

As mentioned in the Introduction, many sensors in satellites and hydrologic stations can be used to monitor flood conditions. We choose two sensors as the instances of SMO: the Moderate Resolution Imaging Spectroradiometer (MODIS) and water level sensors for floods. The instances could be directly registered into the service.

The MODIS process information is described by the subclasses of the “SMO:ProcessElement” class. The non-process description of the MODIS sensor can be expressed by the SMO through the following steps:

• The information relating to SensorID, SensorName, keywords, and classification can be described by the “smo:General” class.
• The properties of length, height, width, and observed region can be expressed by the “smo:Property” class.
• The valid observation time of MODIS can be described by the subclasses of the “smo:Constraint” class.
• The contact and interface information can be described by the “smo:Contact” and “smo:Interface” classes, respectively.

Figure 4 shows that a water level sensor, named “Accubar Bubble Gauge 5600-0131-5”, is expressed in the SMO. The classifications of the sensor are instantiated by the subclasses of the “smo:ClassificationClass” class to describe the classification of IntendedApplication, ServiceType, and SystemType. Compared with the MODIS sensor, this sensor contains additional position information inherited from the “smo:sensorLocationClass” class, as shown in Figure 4.

3. Experimental Data and Results

3.1. Experimental Data

The experimental area (Hubei Province) lies in the middle reaches of the Yangtze River (108°21′–116°07′E and 29°05′–33°20′N). Flood-related disasters affect agriculture and have caused great economic and social losses in Hubei. According to World Meteorological Organization (WMO) statistics [28], there has been a significant increase in the number of satellite sensors that are available for flood monitoring. We choose 167 sensors (up to 120 satellite-carried) that can monitor flooding in Hubei. The study data were used for the registry of sensors and a discovery experiment based on the proposed ontology.

3.2. Implementation

The SSRS prototype was developed by the State Key Laboratory of Information Engineering in Surveying, Mapping, and Remote Sensing (LIESMARS) of Wuhan University in China. The SSRS was demonstrated to be effective for the GEOSENSOR-CSW server. Web services and Java technology were used to implement the service. Based on the previous registry service (GEOSENSOR-CSW), we named the semantic registry service (GEOSENSOR-SSRS). It creates a foundation for semantic information processing in the sensor registry.

3.2.1. Semantic Registry of the SSRS

The service can insert the sensor information into the database based on the SMO. When a user selects documentation for a sensor encoded by SensorML, the service will automatically transform it into SMO. The program then generates an XML request called a “transaction-insert”. This request registers the sensors into the GEOSENSOR SSRS. The operation of inserting MODIS into the service is shown in Figure 5. By importing the instance to the database using the “Insert” operation, the MODIS instance is stored.

3.2.2. Semantic Query of the SSRS

The SSRS semantic query is based on the GetRecords operation in the CSW specification, with modifications to satisfy the specific queries of hydrology applications. The query goes through several steps. First, the user sends a request to the service, compliant with specific filters (i.e., the request uses query templates). The user can also use the SPARQL Query in the implementation (Figure 6). Second, the query is sent to the database, which contains ontologies and semantic annotations. Then, the query refers to the semantic descriptions, and results with related concepts are returned. Third, the result is returned to the user based on the query parameters. For the query shown in the left portion of Figure 6, the result of the query (the right portion of Figure 6) returns information on a corresponding sensor located at 30.582323°N and 114.58029°E. The service is based on the SMO that describes the related characteristics of sensors, so semantic discovery could be implemented effectively.

4. Discussion

4.1. The Comparison between GEOSENSOR-CSW and SSRS

Because the same data could be used from the previous registry service, GEOSENSOR-CSW [7], to compare the precision, recall, time required and performance of a synonym query for SSRS, we chose the GEOSENSOR-CSW as a reference.

• Precision and recall: Precision and recall measurements were employed to assess the matching quality of information retrieval. Precision is the fraction of retrieved instances that are relevant, and recall is the fraction of relevant instances that are retrieved. Figure 7 shows that the SSRS yielded better precision and recall for GetRecords. When the number of sensors in the experimental data set was 150, the precision for GetRecords was 81.1%, and the recall was 85.6%.
• Time required: With a data set comprised of 150 sensors, the total mean response time for the operation “GetRecords” was approximately 0.841 s for SSRS and 1.162 s for CSW. Figure 8 shows that less CPU (Central Processing Unit) time was required to execute retrieval using “GetRecords” in GEOSENSOR-SSRS than in GEOSENSOR-CSW when the number of sensors in the experimental data set was 100 or 150. However, because the SSRS has a new operation of “Semantic Query”, more CPU time was required to execute the operation “GetCapabilities” in SSRS than in CSW.
• Synonym query: Additionally, we added the operation “semantic query” in SSRS. It adds a synonym query, as in the operation “GetRecords” of the CSW in flood scenes. In GEOSENSOR-CSW, clients can search for one or more sensors by keywords to match the sensor ID, intended application, and sensor type. However, the service will not respond with all of the related results in the case of synonyms. The sensor semantic registry method could achieve synonym queries with less data loss. For example, when the a user requires information on sensors related to flood detection, the service will automatically search for the synonyms of “flood” in the database, such as “fresh”, “flow”, and “inundation”. The SSRS can enhance the effectiveness of sensor data management and retrieval by providing synonymous results. It can enlarge the retrieval area and enhance the results retrieved by the search engine.

For example, when a user searches for the intended application field named “flow” in GEOSENSOR-CSW, three sensors will be found, which are shown in the left portion of Figure 9. Actually, there are six possible sensors in the database that could be applied to monitor flooding. The six sensors include “AVHRR3_NOAA-16”, “AVHRR3_NOAA-17”, “AVHRR3_NOAA-19”, “AVHRR3_Metop-A”, “AVHRR3_NOAA-18” and “AVHRR3_Metop-B”. In SSRS, the query of “flow” could capture all six sensors, as shown in the right portion of Figure 9. In short, the synonym query has a higher precision of discovery in SSRS than that in GEOSENSOR-CSW.

4.2. Comparison with SSN Ontology

The Sensor and Sensor Network ontology (SSN ontology), developed by W3C [29], aims to improve sensing applications by merging sensor-focused, observation-focused, and system-focused views. It contains the comprehensive representation of information in the Sensor Network. A comparison between the SSN ontology and the proposed ontology is shown in

Table 1. Comparison between the SMO and SSN ontologies.

Features		Sensor Metadata Ontology (SMO)	Semantic Sensor Network Ontology (SSN)
target		a semantic description of sensor metadata for better registry and discovery, and the conversion of the registry model and ontology	development of ontologies for describing sensors, and the extension of the SensorML to support semantic annotation
key concepts	sensors	√	√
	observations	×	√
	sensor metadata	√	×
	device	×	√
	ObservationCapability	√	×
	MeasureCapability	×	√
	InteroperationService	√	×
relationship to SensorML		link SensorML and the proposed ontology	extension of SensorML
range of subject matter		moderately broad	comprehensive
adoption		a small number of examples for satellite sensors and in situ sensors	numbers of examples, most of them are in situ sensors
best features		support the registry of sensor metadata	interoperability and broader applicability
weakest features		only focuses on the sensor metadata	lack of description about satellite sensors
related service(s)		SSRS	SIR and SOR

. Some differences are as follows: (1) the SSN has more comprehensive concepts than the SMO, which focuses on the sensor metadata information; (2) most examples of SSN focus on in situ sensors, especially weather stations, while the SMO could be used for satellite sensors and in situ sensors; and (3) the SMO is more appropriate for registration and management of sensor metadata.

4.3. Comparison with Other Semantic Registry Services

In this paper, the semantic sensor registry approach can facilitate the management of various sensors including access, discovery, and inference. Compared with other existing services, the semantic sensor service not only provides the functions (publication and search) of a catalog service but also satisfies the semantic requirements of sensor discovery in the GSW, as shown in Figure 10.

• Comparison of the application mode of the registry method:

  • Situation: indirect registry method. The Sensor Instance Registry (SIR) [25] is capable of harvesting, managing and transforming sensor metadata. The SOR is a web service interface that can provide definitions of phenomena observed by sensors for the exploration of semantic relationships between phenomena [30]. The registry method employed by SIR and SOR is an indirect registry. The administrators of SIR/SOR must establish a connection to a generic catalog service that publishes all the pertinent data instances. This method is more time-consuming for sensor registry and discovery and possibly loses information.
  • Development: direct semantic registry for heterogeneous sensors. A data and service registry with direct descriptions of semantics in a catalog service is a challenging task. Both the registry service (GEOSENSOR-CSW) and the semantic registry service (GEOSENSOR-SSRS) use a direct registry method. End-users with a specific field of expertise can query potentially interesting sensors directly if the sensors are included within a catalog.
• Comparison of registry content:

  • Situation: representing semantics of geospatial data and service. The semantically enhanced GN-ebRIM catalog service that was examined by Gwenzi [17] integrates ontologies and semantic annotations for improving searches for data and services. GMU-CSW [20] uses a registration method with the OWL/OWL-S format for geospatial data and services to support semantic searches. These services have good semantic registry performance, but this method could not represent the semantics of sensor metadata for inference.
  • Development: representing semantics of heterogeneous sensors for inference. In this paper, the sensor semantic registry method could transform sensor metadata into an ontology to describe the semantics of sensors. All the metadata related to sensors are described by the Sensor Metadata Ontology, enhancing the efficiency of discovery and supporting the inference of the registry.
• Comparison with the basic model of the registry method:

  • Situation: some registry methods use an off-standard registry model. A semantic geospatial service catalog has been proposed by Maué [31] to support the discovery of geospatial services. The Open Geospatial Consortium (OGC) data services, such as the Web Feature Service and the Web Map Service, could be registered in the catalog, but they do not use a standard information model.
  • Development: it is necessary to use a standard model language to build the registry model for sharing. In this paper, a normal ontology language called OWL is used for representing the ontology. It will enhance the versatility and ability for sharing of the proposed ontology.

5. Conclusions

This paper embeds semantic constructs in a sensor registry that can advance sensor registry and management in the GSW. Compared with other catalogs, the SSRS includes sensor ontologies encoded in OWL to simultaneously provide semantic query capabilities. Based on the objectives of this research project, the following conclusions can be drawn:

• The method of the semantic sensor registry supports synonym query and direct sensor registry, which enables better precision of retrieval and requires a shorter time.
• Different types of sensors (e.g., satellite sensors and in situ sensors) could be stored in the SSRS through the proposed ontology, which facilitates the efficient management and sharing of heterogeneous sensors.

We intend to improve the performance and scalability of the service by implementing it in an open network. Moreover, the improvement of query through ontology visualization requires further study, whereby users can interact with the hierarchy of concepts linked to resources through their metadata descriptions. This will allow users to choose the appropriate search concept for intelligent sensor query to avoid information loss.