Database Reference
In-Depth Information
geometry property if the entity is requested through the “FeaturesOfInterest”
interface. For moving entities this mapping does cause problems, since the cur-
rent SensorThings API data model for Feature of Interest does not support
moving FoIs. This means that when a moving entity is requested through the
“FeaturesOfInterest” interface only one of its locations can be encoded in the
geometry field of the returned entity and all observations that have this entity
as Feature of Interest would appear to be made in this location.
One feature that can not be supported using the standard OpenIoT ontology
is having the feature of interest of an observation to be different from the thing
that is associated with the observation. The observation in OpenIoT is only
linked to a sensor, a property and a feature of interest, not to other things.
In the SensorThings API the observation is also linked to a thing, though a
datastream entity.
3.4 Datastream
In the SensorThings API the concept “Datastream” is used to group related
observations together:
“A datastream groups a collection of observations that are related in
some way. The one constraint is that the observations in a datastream
must measure the same observed property (i.e., one phenomenon).”
A datastream in the SensorThings API links a set of observations that have
the same observed property, to a thing. In OpenIoT the concept “data stream-
ing” is used in the context of getting continuously generated data from point A to
point B in a continuous way that does not involve separate HTTP GET requests.
As such, these similar sounding concepts in the two systems have nothing to do
with each other.
In SSN each observation has a direct link to its Sensor, its Feature of Interest
and its observed property and there is no further way to group observations.
There is no concept in SSN that could be mapped to the SensorThings API
concept datastream.
A SensorThings API implementation based on OpenIoT could offer virtual
datastreams based on a SPARQL query. Several interesting queries would be
possible:
- All observations for 1 observed property and 1 thing/feature of interest.
- All observations for 1 observed property and 1 sensor.
- All observations for 1 observed property, 1 sensor and 1 thing/feature of
interest.
Of course a more advanced solution where a user can specify the query to be
used for each individual datastream is also possible, as long as all observations
returned by the query measure the same observed property. This would allow
for even more powerful filtering since it can make use of the custom ontology
Search WWH ::




Custom Search