When searching for sensor data, sensor instances, or Sensor Web Enablement (SWE) services the description of the observed phenomenon plays an important role. Obviously, every user searching for sensor data needs to specify in which kind of sensor data he is interested. In current SWE applications, the information about the observed phenomenon is provided as a unique link encoded as a Uniform Resource Name (URN). However, relying on those URNs to perform string based search for sensor observables has serious drawbacks when it comes to realizing advanced sensor discovery tools as the meaning of the observables is ignored. This work presents an approach that makes use of semantic annotations of SWE resources. The presented solution relies on a dictionary for sensor observables, the Sensor Observable Registry (SOR). This dictionary comprises URNs identifying observables, definitions of these observables in natural language, and pointers to formal phenomenon definitions contained in ontologies. This makes it possible to rely on existing reasoning mechanisms for determining equivalent or related observables (e.g., specializations or generalizations) to the one specified by a user. Finally, an approach is presented, how the SOR can be used for enhancing the sensor discovery process by linking it to sensor catalogues and registries.

The goal of the Sensor Web Enablement (SWE) initiative of the Open Geospatial Consortium (OGC) is the definition of web service interfaces and data encodings to make sensors discoverable, taskable and accessible on the World Wide Web. The SWE specifications enable a standardized communication and interaction with arbitrary types of sensors and sensor systems. The central concepts within OGC's Sensor Web architecture are sensors, observations and features of interest. Sensors and their observations can be registered and stored through the Sensor Observation Service (SOS) to make them accessible for clients. So far, mechanisms are missing which support a semantic matching between features of interest stored in a database and referred to by an observation. The same applies for the matching between observations as sensor outputs and the properties of the features of interest. By taking a use case from disaster management, we outline the challenges and demonstrate how semantically annotated SWE data models and service interfaces support semantic matching. The result is a roadmap towards a semantically enabled sensor plug \& play within the Sensor Web.

In this paper, we describe a meta-framework that helps guide development of sensor network (SN) cyberinfrastructure in a way that enables emerging sensor infrastructures, including advances in sensor hardware, communication, monitoring applications, and knowledge representation, to interoperate. This framework is guided by the DAST principle. That is, the overall goal of any SN infrastructure is essentially the same: to acquire the right Data from the right Area using the right Sensors at the right Time. In conformity with this principle, our meta-framework integrates SN infrastructures along axes related to the answers to five questions: Why has processing been requested? What are the goals of the processing? Where is it carried out? How is it carried out? And, when will the results be provided? The infrastructure components are integrated by using various data standards and technologies currently available from various SN research groups, and mapping them to an overarching knowledge-based meta-framework. In concrete terms, we show in this paper how four distinct sensor technology projects under development in our research lab are used to fit these five axes of SN infrastructure and how they can be indirectly integrated through the use of software agent-based tools, which embody the meta-framework: an ontology-based decision support system that applies models of SN infrastructure to its evaluation techniques; SN configuration tools that enable network configurations to be exported into common geospatial standards; a transformation engine that converts these SN configurations, along with collected data, into a representation that meshes with our infrastructure models so that they may be used within our decision support environment; and a Virtual SN to handle many of the management and control aspects of SNs.