StarFL – a modularised metadata language for sensor descriptions

Abstract

An ever-increasing number of sensor resources are being exposed via the World Wide Web to become part of the Digital Earth. Discovery, selection and use of these sensors and their observations require a robust sensor information model, but the consistent description of sensor metadata is a complex and difficult task. Currently, the only available robust model is SensorML, which is intentionally designed in a very generic way. Due to this genericness, interoperability can hardly be achieved without the definition of application profiles that further constrain the use and expressiveness of the root language. So far, such SensorML profiles have only been developed up to a limited extent. This work describes a new approach for defining sensor metadata, the Starfish Fungus Language (StarFL) model. This language follows a more restrictive approach and incorporates concepts from the recently published Semantic Sensor Network Ontology to overcome the key issues users are experiencing with SensorML. StarFL defines a restricted vocabulary and model for sensor metadata to achieve a high level of interoperability and a straightforward reusability of sensor descriptions.

Keywords:

• data exchange models
• sensor metadata
• sensor web
• SWE
• usage techniques

1. Introduction

An ever-increasing number of sensor resources are being exposed via the World Wide Web today. In a Digital Earth environment it should be possible to find, visualise and make sense of this vast amount of information (Craglia et al. 2008). This requires a robust sensor information model that describes both the sensor and its deployment in the real world. Due to the plethora of sensor manufacturers, sensor types, sensor access protocols and sensor deployment situations, development of such a model is not straightforward. Furthermore, user requirements on sensor description vary across communities and application domains.

The Sensor Web Enablement (SWE) initiative of the Open Geospatial Consortium (OGC) standardises web service interfaces and data encodings as building blocks for the Sensor Web (Bröring et al. 2011a). SensorML is the proposed standard for modelling and encoding sensor metadata (Botts 2007). SensorML is very flexible and allows modelling virtually any type of sensor in multiple ways. However, this flexibility comes at significant cost – new and experienced users struggle with creating sensor description instances as there is no single unambiguous way to encode sensor characteristics. This leads to interoperability issues at the encoding level. SensorML parsers do not support the full language spectrum and SensorML receivers have to adapt their applications to various flavours of SensorML. Hence, it is crucial to develop constraining application profiles to ensure the interoperability of SensorML instances. Profiles mandate the presence of certain elements and thus restrict the generic properties of SensorML. Currently profiles for SensorML are still in discussion. Two draft profiles have been developed – an earlier profile serves for the specific purposes of sensor discovery (see Jirka and Bröring 2009, Jirka et al. 2009) that has recently been adjusted to a profile for the lightweight description of sensor metadata (see Jirka et al. 2011, 2012).

A Digital Earth raises the need for both, detailed and interoperable sensor descriptions, easy to apply and exchangeable among different communities of practice. Non-expert users need to be supported in order to grow the sensors available to the Digital Earth. The rise of volunteered geographic information (Goodchild 2007), participatory sensing, or the Internet of Things (Gershenfeld et al. 2004) resulting in sensor data portals such as COSM,¹ presents one avenue for growth. Furthermore, concepts of the semantic web, such as ontologies and ontology brokers have been developed to either complement or replace the concept of SensorML. The Semantic Sensor Network Ontology (SSNO) (Lefort et al. 2011), developed by a W3C incubator group, identifies key elements of a sensor network and provides definitions of sensor concepts with particular focus on sensor type organisation and classification. The SSNO is grounded in the Dolce Ultra-Light (DUL) upper ontology. This makes it hard to combine the SSNO with the Observations & Measurements (O&M) (Cox 2010) standard, which is the primary way of encoding measured sensor data as proposed by SWE. O&M models how real world features are observed in the physical and natural sciences.

To bridge the SSNO with O&M requires mapping the SSNO to SensorML. We present a modularised sensor mark-up language called the Starfish Fungus Language (StarFL) to do this mapping. StarFL re-uses concepts of SSNO to restructure and restrict elements of SensorML and also re-interprets their semantics to fit the SWE standards. StarFL might work as a meta-language enabling generic mapping between SSNO and a profiled SensorML. It is aligned to O&M and due to its restrictiveness aims to be highly interoperable and user-friendly. It has originally not only been developed for in situ sensors, but also supports remote sensors. StarFL applies the Pareto principle (also known as the 80:20 rule) and aims to describe most sensors with the least complexity. Intentionally, it does not support every detail of a sensor or its constellation in space, but concentrates on the common features shared by a wide range of users and communities. StarFL does provide extension points for domain specific encodings that can be added by communities with special needs.

The remaining paper is structured as follows. Section 2 acquires an overview of available sensor metadata description languages. Section 3 introduces the StarFL concept. Section 4 compares elements of StarFL to SensorML and SSNO in detail. Section 5 summarises the paper and gives an outlook on future work.

2. Background and related work

SensorML was originally developed to describe satellite remote sensing systems. It specifies a model and XML encoding to describe complete sensing processes. Physical sensors, ranging from simple sensors such as thermometers to composite instruments consisting of multiple single sensing components, as well as virtual sensors can be described. SensorML defines and models physical sensor devices as processes, which provide conversions of typically some physical phenomenon (e.g. temperature, conductivity or pressure) as input and the quantification of another phenomenon as output (e.g. water temperature, salinity or depth). The common root is the abstract type Process. Additionally, various metadata about the process can be specified, including its identification, classification or contact information of the responsible provider among many others. To model physical sensors, the System type can be used which adds spatial (e.g. the definition of a geographic position) and temporal (e.g. the definition of a sampling time) attributes. A measurement station, which is a collection of sensing processes, can be modelled using a hierarchic combination of those system types, where the root node represents the platform. Its attached sensors are modelled as child nodes representing a component of relationship. Measurement stations can be either fixed or mobile (Figure 1).

Figure 1. Fixed and mobile measurement station.

However, there are also cases where modelling the platform is not necessary. For an interoperable and domain comprehensive usage, SensorML allows the development of profiles. Those profiles define the core characteristics of any given type of sensor or platform. This is necessary, due to:

1. The interpretation of a certain system type, as it can adopt several functions (platform, sensor device and sensor sub-device).

2. The omnipresence of optional elements, which allow valid but otherwise meaningless SensorML instances.

Jirka and Bröring (2009) attempted to define a basic SensorML profile orientating on a weather measurement station. They suggest partitioning the sensor devices according to their observed property. In addition, solutions for spatial sensor discovery are presented. However, the issues of dynamic sensor descriptions and redundancy of data and discovery for measurement capabilities are not addressed. Besides such profiles, SensorML uses semantic annotation techniques to support interpretation of elements. Sensor ontologies provide a vocabulary that can be integrated with SensorML to enable semantic interoperability, or used apart from SensorML as an alternative approach to express sensor metadata. Avancha et al. (2004) and Eid et al. (2007) introduce ontologies that mainly focus on measurements with little capacity to describe sensor systems, or how measurements are taken. Other ontologies highlight the role of stimuli, observed properties or processes (Stasch et al. 2009, Devaraju et al. 2010). The SWAMO (Witt et al. 2008) and Marine Metadata Interoperability (MMI) (Bermudez et al. 2006) ontologies extend the analysis along a third dimension, from measurements and sensor types to systems. Each ontology focuses on systems, the components of a system, and how those components are organised. OntoSensor (Russomanno et al. 2005) covers a wider range and is able to describe most of the spectrum of sensor concepts including definitions of SensorML and extensions to IEEE SUMO (Pease et al. 2002). It describes sensors, their capabilities and measurands as main types. Compton et al. (2009) perform a detailed survey over the further mentioned ontologies and compare them to the CSIRO sensor ontology (Neuhaus and Compton 2009), which influenced, together with the Stimulus-Sensor-Observation ontology design pattern (Janowicz and Compton 2010), the work of the W3C Semantic Sensor Networks Incubator Group. The W3C Incubator Group introduced the SSNO, which is aligned with classes of DUL foundational ontology to facilitate reuse and interoperability. It provides concepts to align devices in a sensor context by differentiating between a platform and a sensor. A sensor is defined by its observed property qualified by measurement capabilities and inherits from a system concept that itself has capabilities such as operational range, survival range or deployment. The Sensor Interface Descriptor approach (Bröring et al. 2010, 2011b), which is based on SensorML, goes beyond the metadata description of the sensor instance, and includes the description of the sensor communication interface, which is similar to IEEE 1451 (Lee 2000), and can also be combined with the new OGC PUCK protocol (O'Reilly et al. 2011) as shown in (del Rio et al. 2011).

3. The StarFL concept

StarFL focuses on modelling sensor capabilities, leaving aside the description of the sensor interface or protocol. It makes use of concepts from both SensorML and SSNO. StarFL is described using UML and implemented as an XML schema using the Hollow World ² environment, which provides a framework to develop GML compliant models. StarFL is modularised and consists of two main modules, the Static Module and the Dynamic Module, plus an additional Common Module.

3.1. Static Module

Measuring devices of a certain model offered by sensor vendors typically have the same measuring and physical capabilities summarised in a sensor datasheet. To compress information and avoid redundancies, StarFL separates parts of the sensor description in the Static Module (Figure 2). It consists of three classes. The device-focused part is modelled within the SensorCharacteristic class and describes physical attributes (e.g. height and weight), operational attributes (e.g. survival range) and model identification attributes such as the manufacturer or the model number.

Figure 2. Static Module.

A sensor model typically implements one or many procedures to compute measurement results for a phenomenon. The StarFL sensor model encapsulates each procedure for a distinct observed property as a SensingProcedure. Besides the observed property, the measurement units and capabilities, which are aggregated by the MeasurementCapability class, can be expressed.

Both, SensorCharacteristic and SensingProcedure perform a self-aggregation pattern, which allows the modeller to express a sensor component hierarchy on the device side and a sensing chain on the operational side. Figure 3 shows a sensor characteristic tree with the root as the main device (in our case, a Vaisala weather station) consisting out of subcomponents each responsible for a collection of sensing procedures.

Figure 3. Sensor characteristic component hierarchy.

A SensingProcedure can be based on several other procedures implemented in the same SensorCharacteristic hierarchy tree. The combination of the sub-procedures with the succeeding procedure is described via its method attribute. As a convention, the SensingProcedure is described only once in detail at the most atomic level of a SensorCharacteristic component. The upper SensorCharacteristic elements refer to the detailed descriptions using the W3C recommended XLink technique (DeRose et al. 2000). Figure 4 shows the basedOn pattern in combination with the relation between the SensorCharacteristic tree and the procedure chain. The procedures generating outputs for temperature and wind speed are described in detail within the Thermocap and Windcap sensor characteristics. The root component either uses an XLink reference to its particular SensingProcedures, if they are described in detail in one of its components, or a detailed description if it is not provided by any of its components. In Figure 4, the wind chill computation is based on temperature and wind speed procedures.

Figure 4. Sensing chain and linkage of operational and device part.

StarFL narrows the definition of SensorML and SSNO, which interpret sensors to be physical objects performing observations and transform an incoming stimulus to another representation. In StarFL, sensors are physical devices with several implemented processes that perform observations.

3.2. Dynamic Module

The Dynamic Module (Figure 5) models the second common characteristic of sensors understood as physical devices. They are aligned to time and space. These are dependent on the usage of a certain physical sensor instance and non-static, such as operating location and time, deployment or calibration. The representations for the devices deployed in the real world are instances of the class Sensor.

Figure 5. Dynamic Module (part).

Usually a physical sensor device deployed in the field is of a certain type and model. Once the static description of that explicit sensor model is accessible via a URI, the dynamic part may include references to this static description using the already mentioned XLink technique. In that case the Sensor element, which represents the Dynamic Module device part, refers to its belonging SensorCharacteristic. As the deployed sensor is a real world instance, an identifying serial number is also provided. According to the static description, it aggregates one or many Sensing elements, which themselves refer to their specific SensingProcedure instances (Figure 6). The Sensing class stores information about its status, the observed property or the used unit of measure for that concrete instance. This fits into the process element of an O&M observation, but narrows the interpretation to a sensor device.

Figure 6. Connection between Static and Dynamic Module.

A sensor is either mobile or deployed at a fixed location. Furthermore, a sensor is optionally attached to a platform, which is a physical structure that binds one or many sensors and itself is either mobile or deployed at a fixed location. The sensor-platform linkage is described by the SensorDeployment element. The analogue part for a platform is the PlatformDeployment. Both infer from a class Deployment that stores attributes such as the responsible person, the deployment location or whether the device is deployed mobile or fixed. Note that if a platform or a sensor is mobile, the actual position might be detected using an integrated position sensing procedure (e.g. based on Global Positioning System [GPS]). The original deployment location is not updatable. Following the approach used in SensorML, StarFL supports low-level encoding for calibration events. A Calibration is linked to a Sensing element. The quality of both deployment and calibration is expressed with a ConformanceTest (Figure 7), which identifies tested characteristics. Manufacturers or organisations such as the World Meteorological Organization set specifications and/or protocols on sensor deployment and calibration. For example, a wind vane must be deployed in a certain distance to buildings or trees or a tipping bucket shall not leave a certain accuracy interval in a test. These requirements are described within the ConformanceCharacteristic element. A ConformanceTest refers to a ConformanceCharacteristic with an additional attribute saying whether a specific requirement is passed or not.

Figure 7. Quality of calibration and deployment.

In practice, both the Static and the Dynamic Module could be managed in separate catalogues. A catalogue for the Static Module could be searched for attributes such as sensor model, observed property or measurement capabilities. Instances could either be stored within the catalogue or on the manufactures website in addition to the already available sensor data sheets. A management system for the Dynamic Module must provide techniques to update attributes, such as the actual position of a sensor or deployment and calibration events. A distinct section in the static catalogue could list ConformanceCharacteristics. Once the static description of a sensor model is available, the creation of the application specific dynamic description of a sensor is straightforward and includes the more complex static description of a sensor through a link. It contains the following steps:

1. Description of all deployed sensors and sensings with a reference to their according static descriptions.

2. Description of the platform and its deployment (if any).

3. Description of linkage (SensorDeployment) between sensors and platform.

4. Description of Calibration with linkage to ConformanceCharacteristics.

The use of different catalogues follows the idea of linked open data (Bizer et al. 2009). One sensor description document is split into several. That allows reuse of available information and keeping instance information to a bare minimum. One problem with linked open data is its maintenance management. If a resource is updated, all referencing resources need to be checked on alignment. In our case only two links are suggested and both refer to static and unchangeable instances: the one from the dynamic description to the static description and the other to the ConformanceCharacteristics.

3.3. Common Module

The CommonModule contains three elements either extending the SWECommon2.0 encoding or are meant to be referred to by all possible sensor descriptions. A ConditionalValue can express whether a value is only valid under certain conditions, e.g., influencing the accuracy of a sensor (Figure 8).

Figure 8. Conditional value.

A set of ConditionalValues, modelling intervals is aggregated by the ComplexConditionalValue. The aforementioned ConformanceTest is also allocated within the CommonModule.

4. Comparison to current sensor description languages

The following section compares StarFL to SensorML and the SSNO. Advantages and disadvantages of StarFL with respect to SensorML are listed in six subsections discussing semantics, the atomic process pattern, observed property and measurement capabilities, snippet management, the dynamics of metadata documents and the tool support. Regarding the comparison with the SSNO, the alignment of StarFL to O&M, the role of Sensor and Sensing, usage of additional ontologies and the sensor categorisation are pointed out.

4.1. SensorML

StarFL and SensorML were developed from different points of view. SensorML follows the approach to provide syntactic interoperability by providing a definition language that supports every detail of sensors and sensor-to-platform constellations and, therefore, requires application-specific profiles for SensorML (Botts 2007). Without such profiles, we will have inconsistent sensor descriptions leading to significant interoperability issues. If a profile should be domain comprehensive, all members have to reach agreement on that profile, something which is often difficult to achieve. However, a more detailed profile requires significantly more detailed sensor characterisation and associated effort. That is the reason why StarFL has been designed the other way round, with a restricted collection of identifiers, properties and capabilities as a basis that captures the majority of sensors. Extension points can support every imaginable extension required by specific communities. Typically a sensor's data sheet contains all public information about a sensor model. In a direct comparison of StarFL with SensorML the following advantages can be pointed out.

4.1.1. Semantics

In SensorML the concepts System, Component, ProcessModel and ProcessChain inherit from the abstract class Process. Those element values are not self-describing and their semantics can differ from application to application. To achieve interoperability, a vocabulary stating the role of an element or a profile has to be developed.

StarFL leaves out the inheriting relation of measurement process and instead defines clear semantic meaning of disjoint core concepts for platform, sensor (as device) and sensing (sensing process). A platform, such as a satellite, a plane or a measurement station mast is not understood to be a measurement process as in SensorML, but as a physical instance that aggregates sensor devices. A sensor is a device deployed in the field using a Deployment element and an active sensing process produces measurement results for an observed phenomenon.

4.1.2. Atomic process pattern

In terms of interoperability the concept of atomic physical components as applied in SensorML has its disadvantages. There are two cases where it does make sense to use atomic components. First, when there is a need to describe a sensor at a very high level of detail (which can be very onerous for every sensor instance). This requires access to detailed information from the sensor manufacturer with the assumption that the sensor description can be broken down further. However, the end user might not be interested in the atomic process. Second, if in a specific situation a given sensor needs to be described up to a certain level of detail, all modellers shall agree on what the atomic level of detail is. This, for example, could be either a wind speed sensor itself or its subcomponents: the chronometer and the device that counts the rotations of a cup anemometer. Thus, in many scenarios the same element can be a Component or a System, which leads to interoperability problems and general confusion.

For that reason the atomic element pattern is left out of StarFL and hierarchical component relations and measuring procedure chains are modelled each with only one class type of node (SensorCharacteristic and SensingProcedure, respectively). Two assumptions underpin that decision:

1. A sensor may be divided into more detailed components than given in the manufacturer's published data sheet.

2. All dynamic sensor descriptions reference the same encapsulated hierarchical description of a certain sensor model. The end user then decides while querying metadata of a certain level of detail which information is necessary for his/her application.

4.1.3. Observed property and measurement capabilities

One sensor device can observe one or many physical properties. The SensorML representation of the sensor device may model this behaviour with sensor outputs and their measurement capabilities at one hierarchical level in the document. An O&M observation instance references exactly one measurement process, which for instance might be a SensorML System element. The linkage between the observation and the metadata of its producing process is, therefore, complicated. The observed properties of both the observation and producing process must be compared to each other afterwards and the particular measurement capabilities must also be identified. Hence, logical encapsulation of a sensing process with only one observed property and its measurement capabilities is advantageous. A common profiled approach of process encapsulation is missing. One solution is to define a sensor to observe exactly one property in SensorML. This solution is not intuitive as it does not correlate to the physical device's dimension and leads to several problems. Physical properties of the sensor have to be repeated for every sub-sensor in the model or one device has to be divided into more than one in the model.

In contrast, StarFL implements a different pattern that is transferable to a SensorML profile. A Sensing element logically encapsulates its observed property, additionally covers measurement capabilities and therewith implements the procedure interface of O&M. Device-related data is encoded in Sensor or the SensorCharacteristic element. A mapping from StarFL to SensorML would re-interpret an sml:System element to be a physical sensor. Within its <sml:component> aggregation it would reference to its several sensing processes, which does observe only one property.

4.1.4. Snippet management

Modellers often complain that the description of a sensor is an interminable task. Capturing sensor metadata should not be the most time-consuming job of setting up a sensor network. The preferred approach is to reuse already described data by defining a Static and Dynamic Module.

Currently, there is no agreed or common approach to manage snippets in SensorML. Differentiating between a static and a Dynamic Module in StarFL presents an improved strategy to deal with code snippets. Once a static description is available, the user of a sensor only has to add sensor device specific spatial and temporal deployment and calibration data, if needed. It can be anticipated that manufacturers will provide static sensor data, as it only requires reformatting existing data sheets.

4.1.5. Dynamics of metadata documents

In practice sensors may get replaced, re-deployed in the environment or change their position. Such changes will require sensor descriptions to be easily updated. Whereas SensorML provides the history section to document deployment or calibration-related events, it does not encapsulate the appropriate attributes. Hence, all elements that might have changed, for example, the deployment location or relative position to the platform are distributed all over the document. StarFL, on the other hand, stores all attributes containing the deployment and redeployment in the distinct class Deployment. Linking sensors and modelling redeployments to a platform requires less effort to maintain and adjust descriptions. If a mobile platform is re-deployed only the PlatformDeployment description has to be updated. With removing a sensor device from the real world hosting platform the reference to the particular SensorDeployment is deleted. Attaching a new sensor is modelled by adding a new SensorDeployment element; the Static Module need not be changed.

4.1.6. Tool support

One advantage of SensorML is that already some tools are available supporting version 1.0 of the OGC standard. However, most of these work on a very basic description level and support only parts of the language. SensorML generators either remain on a very basic level, such as SmlMor³ or the sensor registry of the ESONET project (Delory et al. 2007), or they serve a very specialised purpose, such as the SID Creator (Bröring et al. 2011c), which is focused on the interface description of the sensor. For StarFL, though just published a little while ago, RESTful catalogues are under development and will be available soon.

In summary, StarFL is hard-typed mark-up language while SensorML is soft-typed and can hence serve more cases and can include a richer variety of sensor characteristics. However, StarFL is intentionally designed by providing a first set of metadata elements, which are sufficient for most cases of sensors (this even includes complex scientific scenarios). If a particular attribute is missing, StarFL supports the usage of extension elements. SensorML tackles this from a different angle by providing general attribute sections, wherein all imaginable characteristics of a sensor can be aligned. Thus to reach interoperability, the creation of profiles becomes mandatory. In this regard, StarFL can be seen as a restricted profile allowing for more specific usage. Applying a StarFL profile to SensorML, the main composite process elements (e.g. sml:System, sml:ProcessChain) have to be interpreted as the five main elements of StarFL using a semantic annotation technique. The corresponding attribute sets complement the profile regarding the interpretation of the root element. However, since SensorML defines its main elements as processes, the StarFL SensorCharacteristic element has to be re-interpreted and cannot be modelled in the intended manner. Further on, the proposal for code snippet management and the cooperation of sensor catalogues cannot be expressed using SensorML syntax.

4.2. SSNO

The following section summarises differences between StarFL and SSNO. SSNO aims to apply semantic web technologies to the Sensor Web, that is, to align SensorML, O&M and lately even foundational ontologies. It describes how parts of a sensing system fit in a sensing domain. The alignment of the SSNO with the ultra light version of the DOLCE foundational ontology makes it hard to reconcile SSNO with O&M, which follows a more conventional approach observation descriptions in physical and natural sciences. Though the SSNO could be seen as the main ancestor of StarFL, specific changes have been made in both the semantics and conceptual design to foster ease of use, tool support and general usability.

4.2.1. Interface implementation to O&M

The OGC and ISO standard O&M, currently published as version 2.0, captures the observational data model and encoding in the SWE suite of standards. SWE web service standards such as the Sensor Observation Service (SOS) make use of it. To fit into SWE, a sensor metadata language shall ensure two aspects: First, the seamless implementation of the OM:Observation interface, and second, the consistent usage of terms and concepts to facilitate semantic reasoning. SSNO interprets an Observation contrary to O&M by aligning it as a sub-concept of a DUL:Situation. O&M defines an Observation as an act of observing a property or phenomenon, a specialised event whose result is a data value (Cox 2010). Though the working group outlines that these two concepts perform a close match, a DUL:Situation and a DUL:Event are modelled as disjoint entities. Merged by force, problems regarding the semantic interpretations of elements can result. Observation is not the only concept defined differently in the SSNO, other elements may only be linked through closeMatch relations (Lefort et al. 2011). Table 1 gives an overview of respective elements.

Table 1. Close match relations from SSNO to O&M.

SSNO expression		O&M expression
Sensor	closeMatch	observationProcedure
SensorOutput	closeMatch	observationResult
ObservationResult	closeMatch	Result
ObservationValue	closeMatch	observationResult

SSNO, Semantic Sensor Network Ontology; O&M, Observations & Measurements.

Thus a seamless implementation of O&M is not given. A mapping between O&M and SSNO has to be performed before semantic tools can operate on any concept. As opposed to this, StarFL performs a clean alignment to O&M. Its definition of Sensing is a sub-concept of the observation procedure described in O&M. A Sensing object produces observations with an according observation result. These concepts are not modelled in StarFL but adopted from O&M. Like SensorML, a Sensing element, which represents a procedure/process, can be linked embedding the XLink technique in the procedure tag of an O&M observation instance.

4.2.2. Sensor and sensing

The core concept of SSNO, the relation between Sensor, Sensing and the linkage to the real world phenomena (observed property), is not solved satisfactory from a practical point of view. Thus, relations between core elements have been changed in StarFL. StarFL limits the definition of a sensor to a physical device, because they are the primary source in (semi-) automated Sensor Webs. To provide a solution for all types of sensors, SSNO is far more abstract and describes sensors to be physical devices, computational methods, a laboratory setup with a person following a method, or any other thing that can follow a sensing method to observe a property.

In SSNO, the observes relation between sensor and property effects the definition of a sensing device (Figure 9). Following this approach, components of a device, which are responsible to derive a certain property, are summarised to a single sensor/physical device. For each property that a system observes the components are rearranged and thus represent a different sensor. As outlined before, an easier and more intuitive way might be the one-to-one relation between a physical device and its sensor model and to encapsulate the sensing process in an additional class Sensing. A sensor model-orientated approach, as performed in StarFL but not expressible in SSNO, allows searching for certain instruments and not for sensor types. Due to their dependencies on observed properties a StarFL Sensing element has a close match to an SSNO Sensor. Hence, for a mapping between both models the StarFL Sensing element may be accordingly annotated.

Figure 9. SSNO sensor and sensing [based on (Lefort et al. 2011)].

The StarFL SensingProcedure is similar to SSNO:Sensing, which is a sub-concept of DUL:Process and has one input and several outputs. Changes were necessary due to the different interpretation of the process and device parts of StarFL and to support sensing chains. The self-aggregation pattern of StarFL:SensingProcedure makes it possible to describe procedure chains. The SensingProcedures can be seen as pre-procedures of other SensingProcedures that perform a basedOn relation to them.

4.2.3. Additional ontologies

By re-using ideas from SensorML, StarFL covers more elements, such as the direct integration of spatial and temporal values or calibration information, whereas SSNO must include secondary vocabularies, which involves the risk of interoperability issues due to misaligned or contradicting external secondary ontologies.

In summary StarFL has adopted some concepts of SSNO such as measurement properties or the interpretation of platform. While SSNO has the goal to align components in a sensor domain, StarFL aims for a more practical approach to model sensor metadata, with the primary goal to derive and qualify metadata for observation interpretation and sensor discovery processes. It does not orientate on the sensor's observed property and the sensor's type, respectively, but focuses on the model of a sensor. Thus, the StarFL representation can be modelled straightforward from the sensor's specification provided by the manufacturer.

Since StarFL has not been developed as an ontology, it is required to map it into a semantic representation in order to apply Semantic Web technologies, such as reasoning, and align StarFL to the SSNO. The mapping can be achieved by either translating the StarFL XML schema into an ontology representation or by annotating XML instances of StarFL with concepts of the SSNO that have the same semantic meaning.

5. Application

A sensor description can be viewed from two user perspectives. On the one hand, the responsible party for operating and maintaining a sensor or platform needs to maintain a sensor description. On the other hand, that metadata is obtained by users of sensor applications to get more information about an observation process or to discover sensors. To demonstrate the usage of StarFL for the first case, we apply it to the ifgicopter sensor platform (Rieke et al. 2011). The ifgicopter is an unmanned aerial vehicle enhanced with a standalone computing board to manage the interaction with additional sensors. In our use case the ifgicopter is equipped with a Sensirion SHT75 sensor to observe temperature and humidity. A request for the specific sensor model in a catalogue would return a StarFL document (Listing 1). The root element, SensorCharacteristic, contains or references its two provided SensingProcedures.

Listing 1. Sensor Characteristic

The SensingProcedures, humidity and temperature, derive measurement results for their specific phenomena. They are described further by attributes such as their qualifying measurement capabilities. Listing 2 demonstrates the encoding of accuracy.

Listing 2. Sensing Procedure

If the actual humidity is between 0 and 10%, the accuracy of the provided values has a maximum derivation of ±4%. Other conditions and measurement capabilities, such as resolution or drift are left out for formatting reasons but work similar to the given example. SWECommon2.0 does not provide a clear syntax for encoding conditions. Therefore, StarFL defines a class ComplexConditionalValue to express value dependencies.

StarFL interprets the ifgicopter to be a Platform. The platform is set up with a PlatformDeployment and references all attached sensors. In this particular use case the mobile platform is deployed at a point location for 10 minutes, as illustrated in Listing 3. The operational area is set up in context of a WGS84 system. The valid time attribute expresses the time interval wherein the platform is operating. In a next step the sensor deployment is described. Note that only the most basic attributes such as temporal and spatial data have to be considered. A detailed StarFL document, therefore, needs much less lines of code in comparison to SensorML to describe a sensor platform. The core connections are shown in Listing 4, where the sfl:characteristics attribute and the sfl:sensingProcedure link to their corresponding static descriptions. The encapsulation of these attributes provides the opportunity to easily re-mount sensors on platforms and therewith decreases the effort for updating a sensor document.

Listing 3. Platform

Listing 4. Sensor Deployment

Once published, the metadata might be obtained for several reasons. For instance, new devices should be deployed fitting certain requirements. A sensor metadata catalogue, similar to the Sensor Instance Registry service (Jirka et al. 2009) that stores StarFL descriptions can be filtered in order to obtain which sensor model fits best for requirements.

6. Conclusion and outlook

In this paper, we analyse and discuss the most prominent sensor metadata languages, SensorML as well as the SSNO, and come up with StarFL – an alternative sensor metadata language that re-uses concepts of both SensorML and the SSNO. Elements and patterns of SensorML and SSNO are reused where possible, adjusted and constrained where necessary. StarFL focuses on sensor devices and aims to support the majority of sensor models. These restrictions lead to a more interoperable model, which may serve as a suggested way of encoding sensor metadata in the Digital Earth environment and as a detailed SensorML profile leading to a straightforward creation of sensor metadata descriptions. Limitations of creational freedom may be overcome by using the extension point pattern of StarFL.

Furthermore, through its Static Module, StarFL introduces a mechanism for reusability that can easily be applied. Sensors can be designed from an intuitive point of view. This allows also non-professional sensor operators to define metadata about their sensor platforms, such as well-established home weather stations or upcoming participatory sensing devices, e.g. the air quality egg (http://airqualityegg.wikispaces.com). In the envisioned, ubiquitous the Internet of Things, the device owner only needs to reference a specific platform type or sensor model during the registration process. Then, applications could automatically complete the sensor description by obtaining the information stored in the Static Module. Furthermore, StarFL can facilitate in the future the creation of applications that make use of semantically aware sensor metadata descriptions, such as a mediation framework for sensor plug and play (Bröring et al. 2011b) or a RESTful web service for providing linked sensor data (Janowicz et al. 2011) is facilitated.

Modifications may be necessary to optimise usability and interoperability aspects of StarFL. Work on StarFL is still on-going, as minor issues have been reported by the user community and are as, yet, not satisfactorily resolved. For example, the question of relative spatial connection of a sensor to a platform with an according definition of a relative reference system remains open. At the time, tools are implemented to manage sensor descriptions of both the Static and the Dynamic Module. As the development of SensorML 2.0 is still in progress at the OGC, we are working on the integration of StarFL to SensorML 2.0 as a detailed semantically annotated profile, aiming to facilitate translation to an SSNO representation of sensor metadata.

Acknowledgements

This research was financially supported by the project Flexible and Efficient Integration of Sensors and Sensor Web Services funded by the ERDF program for NRW, contract no. N 114/2008 and the European Commission as part of the integrated project ‘Emergency Support System’ (ESS), contract number no. 217951. Initial development of StarFL was funded by the Australian Government through the Intelligent Island Program and CSIRO. The Intelligent Island Program is administered by the Tasmania Department of Economic Development, Tourism and the Arts.

Notes

1. COSM, formerly known as Pachube, is available from https://cosm.com.

2. The Hollow World environment is available from https://seegrid.csiro.au/wiki/AppSchemas/HollowWorld.

3. The SensorML generator is available from http://mmisw.org/smlmor.