Standards-Based Coastal Sensor Web

Surya S. Durbha, Roger L. King, Nicolas H. Younan, Santosh A. Rajender, Shruthi Bheemireddy Department of Electrical and Computer Engineering

GeoResources Institute (GRI) Mississippi State University

suryad@gri.msstate.edu, rking@cavs.msstate.edu, younan@ece.msstate.edu

Abstract

Coastal buoys and stations provide frequent, high-quality marine observations for oceanographic study, weather service, atmospheric and public safety. Sharing of the generated data sets requires tremendous efforts and coordination among the different sensor network agencies to come to a shared understanding and for dissemination in a uniform way. Syntactic standardization provides data description models that are agreed upon by all the stakeholders. In addition, there is a need for semantic enrichment of the information sources which would help to understand the context of the data and helps to resolve the meaning, interpretation or usage of the same or related data. The standardized data models facilitate improved information retrieval on a variety of Spatio-temporal scales. In this paper we describe the mining of these information sources through a web services based framework. The sensor observation service component of this framework allows operations such as spatial, temporal subsetting, filtering etc. Further, the terminology involved in the coastal domain is being conceptualized in the form of Ontology. The knowledgebase being developed using this ontological model is amenable to querying using SPARQL which is a standardized RDF query language. The knowledge-enabled client being developed will allow to process queries on the coastal sensors networks that goes beyond the prevalent key words based searches. 1. Introduction More then 80 percent of the American population lives within 50 miles of a coast, a population component that has doubled in the past decade [1]. The coastal zone comprises many important onshore habitats (e.g., forests, rivers and streams, wetlands, estuaries, beaches, barrier islands), coastal infrastructure, as well as the coastal ocean. The

Integrated Ocean Observing System (IOOS) is the U.S. contribution to the Global Ocean Observing System (GOOS) and to the oceans and coasts components of the Global Earth Observation System of Systems (GEOSS). The IOOS is envisioned as a user-driven, coordinated, national and international network of observations, data management and communications, and data analyses that systematically acquires and disseminates data and information on past, present, and future states of oceans and coasts [2]. This research is addressing some important NOAA goals that the IOOS data management & communications subsystem (DMAC) system has identified such as [3]: IOOS-wide descriptions of data sets ( metadata) Ability to search for and find data sets of interest

(Data Discovery) The ability to access the data in an interoperable

manner from client applications (data transport)

The ability to evaluate the character of the data through common web browsers and

The ability to securely archive data and metadata and retrieve them on demand

While addressing some of the above goals in their entirety, the scope of this work is however limited to the Northern Gulf of Mexico region. To achieve some of the above objectives, it is imperative that strategies for innovative acquisition, integration, and data exploitation technologies be explored for fully interchangeable, timely, and accurate geospatial data and mapping that extends across the coastal zone. The seamless access to real time or near real time sensor data is constrained by varying characteristics (physical/logical) of the sensor networks. The resolution of conflicts depends on the reconciliation of both syntactic and semantic heterogeneities in the data. Syntactic standardization (interoperability) has long been proposed and a number of metadata standards

2008 IEEE International Conference on Data Mining Workshops

978-0-7695-3503-6/08 $25.00 © 2008 IEEE

DOI 10.1109/ICDM.Workshops.2008.92

369

2008 IEEE International Conference on Data Mining Workshops

978-0-7695-3503-6/08 $25.00 © 2008 IEEE

DOI 10.1109/ICDMW.2008.131

369

such as FGDC [4], ISO [5], etc. have been developed world-wide during the last decade. Although the metadata standards alleviate to a large extent the syntactic heterogeneity of the data, a problem that is still not completely solved is heterogeneity in the process of converting this data into information and actionable intelligence. Hence we require a dual strategy consisting of: • Syntactic standardization of the metadata through

open standards based sensor web components; • Enriching the syntactical terms with semantics by

means of conceptualizing them through ontology-based modeling.

The development of Coastal Semantics Middleware (CosemWare) is the direct result of this effort. 2. Coastal sensor web components The Sensor Web is an emerging technology trend towards achieving a collaborative, coherent, consistent, and consolidated sensor data collection, fusion, and distribution system. It enables to add a sensor dimension to the Internet that allows users to glean meaningful information about the observation via a

web browser. The sensor web is a universe of network-accessible sensors, sensory data and information. Describing the coastal sensors and observation processes with general standardized models and XML encodings enables to fully describe them and hence facilitates the dynamic retrieval of their capabilities and quality of measurements. In this work we use real or near real time data derived from coastal sensor networks (e.g. National Data Buoy Center (NDBC)) and satellite remote sensing data sets.

As part of its effort to enable access to web-resident devices, the Open GIS Consortium, Inc. (OGC) [6] is creating and testing a framework to maximize the discoverability and interoperability of sensor systems through standard Web-based services. SensorML [7] is a foundational part of OGC’s Sensor Web Enablement (SWE). It provides a functional model of the sensor system, rather than a detailed description of its hardware. The root for all SensorML documents is Sensor, or an extension of Sensor such as SensorGroup. The Sensor has a unique id (of type xs: id) as a required attribute. Two optional attributes, documentDate (xs: dateTime) and documentVersion (xs: string), provide the ability to quickly check version information. The sensor description is divided

Figure 1. Architecture of coastal sensor web enablement

370370

into nine main informational components, each of which has sub-parts. (Most of these are optional, so that implementations can be kept as simple as possible). Several of the components have “plug-n-play” capabilities, such that they can accept models that are appropriate for a given class of sensors [8].

2.1 SensorML for Buoy Sensors

In this study, buoys operated by NDBC with different payloads (e.g., ARES, DACT, DART, GSBP, MARS, and VEEP) were described using SensorML. Each of these payloads has a variety of sensors used to measure the marine parameters (e.g., wind direction, wind speed, sea surface temperature, and water level). In SensorML, a Process Chain is defined as a composite processing block consisting of interconnected sub processes. A process chain also includes possible data sources as well as connections that explicitly link input and output signals of sub-processes together. It also precisely defines its own inputs, outputs and parameters [9]. System is derived from Process Chain, and thus inherits all of the properties of the process chain. System also provides relative positions of its components as well as connectivity of the internal process chain to the real world by including interface information. A buoy station usually has multiple detectors such as wind, pressure, temperature, and wave detectors. Thus it belongs to a System when described in SensorML.

The SensorML language itself only defines the relative positions of components and the communication interfaces. However, it provides a means for referencing other documents in the metadata section. The Web service specifications such as Sensor Planning Service (SPS), Sensor Observation Service (SOS), and Sensor Alert Service (SAS) define how data collection requests are expressed, observations retrieved, and alert or alarm conditions defined. The integration of these in the architecture (Figure 1) provides access to observations from sensors and sensor systems in a standard way that is consistent for all sensor systems including remote, in-situ, fixed and mobile sensors.

2.2 Sensor Observation Service (SOS) A service-oriented architecture (SOA) is an application framework that allows applications to be designed into smaller individual functions and processes, called services, and are the building blocks of a SOA. The OGC Sensor Observation Service specification [10] defines an API for managing deployed sensors and retrieving sensor data and, specifically, observation data from in-situ sensors (e.g., marine/meteorological variable measurements) or dynamic sensors (e.g., satellite imaging). The SOS implementation specification defines the interfaces and operations that enable the implementation of interoperable sensor observation services and clients.

Figure 2. Coastal Semantics Middleware (CosemWare) application

371371

The SOS is the middleware between a client and an observation repository or near real-time sensor channel. The SOS GetObservation operation includes an ad-hoc query capability that allows a client to filter observations by time, space, sensor, and phenomena as shown in figure 1 of the Coastal Semantics Middleware (CosemWare) architecture. The different requests such as GetCapabilities, GetObservation, DescribeSensor GetResult, GetFeatureOfInterest, DescribeResultModel GetFeatureOfInterestTime, DescribeFeatureofInterest DescribeObservationType, RegisterSensor, InsertObservation are also supported by SOS. Some of these requests are described in the following sections. 3. Spatio-temporal data mining from the sensor web A typical interaction of a CosemWare client with different sensor observation services is depicted in Figure 2:

The user begins by selecting instances (e.g. Marine sensors service, Biological sensors service etc) from a web catalog Service (CS-W) catalog by using the GetRecords operation.

He/she then performs a service-level discovery on each service instance by requesting the capabilities document and inspecting the observation offerings.

The consumer invokes the DescribeSensor operation to retrieve detailed sensor metadata in SensorML of sensors advertised in the observation offerings of the two services.

Finally, a call is made to the GetObservation operation to actually retrieve the observations from both service instances.

The service components are being developed in Java and existing open source software implementations for Sensor Web Enablement are leveraged upon for this project. The CosemWare client (Figure 2) is developed based on the open source Google Web Toolkit (GWT) Asynchronous Java Scripting (AJAX) implementation [11]. We also integrated Google maps for improved visualization of the results. 3.1 SOS querying The SOS supports a variety of spatio-temporal querying.

Figure 3. Snippet of a spatial query of the sensor web for retrieving data from “all the sensors within a specified bounding box” 3.1.1 Spatial subsetting The queries that are support this operation includes selecting a bounding box and retrieving all the sensors that measure a particular parameter (Figure 3). Overlap, containing, intersection are other spatial queries that can be executed on the sensors data. These kinds of spatial queries are enabled by integrating a spatial database engine (e.g. PostGIS) to RDBMS. 3.1.2 Temporal subsetting This represents the temporal subsets such as after a time instant, before time instant, during time instant, TEquals, past N sec/min/hrs/days. As shown in Figure 4 the sensors data can be requested for any time periods in the past (e.g. past 3 days). Also, the requests use the Geography Markup Language (GML) [12] to represent the temporal and spatial entities. The SOS will respond to the request with the data in the standardized O&M format.

<?xml version="1.0" encoding="UTF-8"?> <GetObservation xmlns="http://www.opengeospatial.net/sos" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" xmlns:ows="http://www.opengeospatial.net/ows" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengeospatial.net/sos http://mars.uni-muenster.de/swerep/trunk/sos/0.0.31/sosGetObservation.xsd" service="SOS"version="0.0.31"> <offering>WSPD</offering> <observedProperty>urn:ogc:def:phenomenon:windSpeed</observedProperty> <featureOfInterest> <ogc:BBOX> <gml:Envelope srsName= "EPSG:4326"> <gml: lowerCorner>29.6880527498568 92.5048828125</gml: lowerCorner> <gml: upperCorner>37.02009820136811 102.1728515625</gml:upperCorner> </gml:Envelope> </ogc:BBOX> </featureOfInterest> <resultFormat>text/xml;subtype="OM"</resultFormat> </GetObservation>

372372

Figure 4. Snippet of a temporal query to retrieve “observation from the past 3 days”. 3.1.3. Filtering SOS also supports filtering (Figure 5) of the sensors data based on comparison operators such as Between, EqualTo, NotEqualTo, LessThan, GreaterThanEqualTo etc.

Figure 5. Comparison filtering of the sensor web results based on the property LessThan.

3.2 Resolving semantic heterogeneities through Ontology Data from the coastal sensors is currently available in text, spreadsheets, relational database management systems (RDBMS), XML web services etc. However these formats are not amenable to retrieve knowledge from the information sources. Hence it is necessary to semantically enrich the data from these different sources. This enables inferences on buoy parameters and their measurements, availability etc as related to particular application context. We adopt an ontology-based approach in which we develop knowledgebase for the buoy sensors data. A knowledgebase is a collection of Ontology Web Language (OWL) [13] statements about resources and the instance data based on the ontological model. We use SPARQL [14] querying to retrieve information from the knowledgebase. 3.3 Querying with SPARQL SPARQL is a protocol and query language for semantic web data sources. It is based on matching graph patterns. Graph patterns contain triple patterns. Triple patterns are like resource description framework (RDF) triples, but with the option of query variables in place of RDF terms in the subject, predicate or object positions. We implemented SPARQL querying in the CosemWare application (Figure 6 and 7). We have integrated the querying using Jena [15] and Joseki [16] open source semantic web framework. Joseki is a SPARQL query web service and Jena provides Java APIs for manipulating RDF stores.

Figure 6. Snippet of a SPARQL query to retrieve sensor stations based on particular payload and buoy type.

PREFIX : <http://cosem.erc.msstate.edu/ontologies/cosem.owl#> SELECT ?hasStationID ?buoyPayload ?buoyType ?ownedAndMaintainedBy ?latitude ?longitude ?location FROM <file:///C:/cosemont/Cosem.owl> WHERE {?hasStationID :buoyPayload ?buoyPayload; :buoyType ?buoyType; :ownedAndMaintainedBy ?ownedAndMaintainedBy; :latitude ?latitude; :longitude ?longitude; OPTIONAL{?hasStationID :buoyLocation ?location.} FILTER ((?buoyPayload = "VEEP" || ?buoyPayload = "DACT") && ?buoyType = "6meterNOMADbuoy") }

<? xml version="1.0" encoding="UTF-8"?> <GetObservation ………………. ………………. <! -- Observation offering id is WindDirection --> <offering>WDIR</offering> <! -- eventTime is time of past 3 days--> <eventTime> <ogc:During> <gml:TimePeriod> <gml:beginPosition indeterminatePosition="unknown"></gml:beginPosition> <gml:endPosition>2006-10-10T10:00:00</gml:endPosition> <gml:duration>P3D</gml:duration> </gml:TimePeriod> </ogc:During> </eventTime> <observedProperty>urn:ogc:def:phenomenon:windDirection</observedProperty> <resultFormat>text/xml;subtype="OM"</resultFormat> </GetObservation>

<? xml version="1.0" encoding="UTF-8"?> <GetObservation ………….. …………….. <!-- Observation Offering id is WindDirection --> <offering>WDIR</offering> <observedProperty>urn:ogc:def:phenomenon:windDirection</observedProperty> <!--result filter filters the observation values which equal to 50 cm--> <Result> <ogc:PropertyIsLessThan> <ogc:Literal> <ogc:Measure uom="cm">50</ogc:Measure> </ogc:Literal> </ogc:PropertyIsLessThan> </Result> <resultFormat>text/xml;subtype="OM"</resultFormat> </GetObservation>

373373

4. Conclusion For a better interoperability among different buoy systems and enhanced data sharing among different organizations and clients, this research adopted a standards based interoperable framework for coastal buoys using OGC’s SWE suite of services oriented components for discovery and access of observations in real time. We pursued an ontology-based approach to enrich the syntactic representations and developed knowledgebase for the information sources. It is envisaged that the coastal sensor web will provide an extensive monitoring and sensing system that provides timely, comprehensive, continuous, and multi-mode observations for the coastal buoy network. 5. References [1] National Research Council Committee on National

Needs for Coastal Mapping and Charting.: A Geospatial Framework for the Coastal Zone: National Needs for Coastal Mapping and Charting, National Research Council, Washington, D.C., (2004) http://www.nap.edu

[2] http://www.ocean.us/documents/docs/ROWProceedings-composite-v3.doc, 2004

[3] http://www.ocean.us/dmac_subsystem. [4] http://www.fgdc.gov. [5] http://www.iso.org. [6] http://www.opengeospatial.org/]. [7] http://vast.nsstc.uah.edu/SensorML/] [8] Botts, M. and Reichardt M. Sensor web

enablement white paper, Open Geospatial Consortium (OGC) (2006) http://ip.opengis.org/swe/SensorWebWhPpr030512.doc.

[9] Open Geospatial Consortium (OGC). OpenGIS Sensor Model Language (SensorML) Implementation Specification, 2006 http://portal.opengeospatial.org/files/?artifact_id=13879&version=2&format=doc.

[10] http://www.opengeospatial.org/standards/requests32.

[11] http://code.google.com/webtoolkit. [12] http://www.opengeospatial.org/standards/gml [13] http://www.w3.org/TR/owl-ref/ [14] http://www.w3.org/TR/rdf-sparql-query/ [15] http://jena.sourceforge.net/ [16] http://www.joseki.org/

Figure 7. Example SPARQL query (scenario: “Find devices that can produce certain output variables”). In the above figure, the query is to classify all devices that measure atmopsheric pressure.

374374