Database Reference
In-Depth Information
In the Sensing Profile, each thing can have multiple “Datastream” objects
that are used to group observations together. The observations in a datastream
all have the same observed property, but they can be made by different sensors on
different features of interest. Each observation is associated with 1 datastream,
1 Sensor and 1 Feature of Interest.
The Sensor is what made the observation. It can be a hardware sensor, but also
a piece of software or even a human. Sensors can be in-situ sensors, like the ther-
mometer in an oven, or remote sensors, like a camera on a satellite. The Feature
of Interest is the object on which the observation was made. It can be the thing
itself, or any other identifiable object.
In the Tasking Profile part, each thing can have zero or more “Tasking Capa-
bilities” objects. These function as a bridge between Actuators and Tasks on
one side and the thing on the other. The OpenIoT platform currently does not
describe actuators, therefore we can focus on the sensing profile part of the
SensorThings API, and ignore the tasking profile.
3 Data Model Mapping
At first glance the data models of OpenIoT and the OGC SensorThings API
are very similar. The most important difference is that the OpenIoT data model
does not specify the concepts “Thing” and “Datastream”.
3.1 Thing
SensorThings API defines “Thing” as:
“a thing is an object of the physical world (physical things) or the infor-
mation world (virtual things) which is capable of being identified and
integrated into communication networks.”
Things in the SensorThings API have a Location, described as a geometry
object and a time, to support mobile things. Things also have a description and
any arbitrary metadata.
In the SSN ontology, and thus in OpenIoT, “Thing” is simply the top-level
concept for all that can be described. In SSN “Sensor” is a sub class of “Physical
Object”, which is a sub class of “Object”, which is a sub class of “Entity”, which
is a sub class of “Thing”. “Feature of Interest” is a direct sub class of “Thing” and
an “Observation” is also eventually a sub class of “Thing”. As a result, there is
no nice mapping from a concept in OpenIoT onto the SensorThings API concept
of Thing. OpenIoT does not define a class of “Things that can communicate”.
In the standard OpenIoT ontology the closest match for the SensorThings API
concept “Thing” is actually the SSN concept “Feature of Interest”. An advanced
version could also allow the administrator to define the queries used to fetch and
create things. This would allow for more freedom in the definition of things,
since it enables the use of the custom ontology extensions that are created for a
specific use case.
Search WWH ::
Custom Search