Database Reference
In-Depth Information
3.6 Sensors
The biggest difference in the data models regarding the sensor concept is that
OpenIoT has split the concept into sensor and sensor type, to ease the manage-
ment of large numbers of sensors. When requesting the properties of a sensor
through the SensorThings API the properties of the sensor type could be merged
into the properties of the sensor before the data is returned. However, when cre-
ating a new sensor through the SensorThings API this could create a problem,
since it would be hard to determine the sensor type from the merged data.
A better option could be to keep the sensor type as a separate, custom object
type in the OpenIot SensorThings API implementation. That way each sensor
can have a link to its sensor type.
4 Conclusions
In this paper we described the potential usage of the OGC candidate standard
SensorThing on top of the OpenIoT middleware. The central question was: how
can the simple REST-like API be mapped to the high-level semantic interfaces of
the OpenIoT middleware? The answer is, surprisingly well. Surprisingly, because
the data model of the SensorThing API is a very significant simplification of the
OpenIoT data model. The Semantic Sensor Network (SSN) ontology, as the Ope-
nIoT data model, is a quite powerful description framework of almost any kind
of sensor observation. Unfortunately this comes with a price the SSN is not espe-
cially easy to apply. It allows a very comprehensive description of context for the
“internet of things” which is required for the services the OpenIoT middleware is
supposed to support. For simpler applications this type of service is probably not
the best choice.
Fortunately the SensorThing data model is a very consistent and stringent
simplification of the observation and measurement concept behind the SSN ontol-
ogy. The naming of the concepts are not always a good indicator for the mapping
between the two models, as shown with the example of the “Thing” concept.
But looking at the meaning behind the names, it was always possible find an
appropriate paring concept. The described mapping will give a consistent view
to a subset of the OpenIoT data model. We believe that the implementation of
the SensorThing API will be a major improvement for the OpenIoT middleware.
It will give OpenIoT a standardized and truly easy to use interface to sensor val-
ues. This will complement the rich semantic reasoning services with a simple
resource based interface. And the consistent data model mapping gives both a
common context to describe the internet of things.
One notable proposed improvement of the OGC SensorThings API would
be the support for mobility for the Feature of Interest. The simplest way to
achieve this is to encode the geometry of the Feature of Interest in the same
way as the geometry of a thing, with a list of Location objects, each containing
a time and a geometry. That way any thing can be presented as a Feature of
Interest without having to recode its Location. Both the OGC SensorThings
Search WWH ::
Custom Search