STA V2.0 Design Draft

[humaidkidwai]

I designed a draft data model that addresses some of the concerns the community has had over the past couple of years and also attempts to align with OMS V3.

STA (1)

ObservationCollection In TC Singapore, perhaps this was debated as to whether or not is it really a collection of observations or just a Datastream renamed to ObservationCollection. [1] As per OMS, an ObservationCollection should be homogeneous or summarizing type. [2] Should ObservationCollection be allowed to contain different types of observations that may potentially violate the OBSC req set out by OMS? Will it help in addressing issues? [3] resultType is adopted as per SWE Common JSON schema (see #122 )

Deployment This entity describes the current state of observers (read Sensors) in their association with Host (Thing (?)) [1] position property may be used to describe geographic location of sensors for moving things?

ObservingProcedure See #160 Do we need it?

FeatureOfInterest In order to introduce sampling in STA, FoI can be specialized further to pFOI and uFOI as specified in OMS. This also allows to extend pFOI by introducing and linking Sampling entitites with it. pFOI may act as a Sample proxy in the design

Please feel free to critique and put forward your suggestions

edit: changed the out-dated in-line image to a link to avoid possible confusion

[hylkevds]

Core Model:

OM Extension

Adds Deployment and ObservingProcedure

Sampling Data Model:

Relations Data Model:

Tasking Data Model:

Tasking Data Model, illustrating the mirroring of Tasking and Sensing:

[humaidkidwai]

resultTime::Observation, time::PreparationStep needs to be of type TM_Instant. As described in #177 the way OData defines it is DateTimeOffset, this should be elaborated in the OData binding section of the standard and not in the data model.

[hylkevds]

I fixed the image.

[humaidkidwai]

Is the Deployment entity to be included in the Core Sensing Part of the document?

[hylkevds]

Updated images: observationType --> resultType deploymentTime --> time samplingTime --> time samplingLocation --> location Sampling/parameters --> properties Sampling/location type --> ANY

[hylkevds]

Changed Sampling -> Thing relation cardinality to 0..1. There is no need to require a Thing/Host for a Sampling, since the domain relation SampledFeature is mandatory.

[hylkevds]

I've created a prototype for testing with this data model:

https://ogc-demo.k8s.ilt-dmz.iosb.fraunhofer.de/FROST-MODELV2/

It has the V2 proposed data model with the v1.1 API.

[michcfr]

I've created a prototype for testing with this data model:

https://ogc-demo.k8s.ilt-dmz.iosb.fraunhofer.de/FROST-MODELV2/

It has the V2 proposed data model with the v1.1 API.

Hello, would it be possible to download the FROST-MODELV2 prototype from github?

[hylkevds]

Hello, would it be possible to download the FROST-MODELV2 prototype from github?

Yes, you can use the Docker images for it:

• http: frost-server-http:develop-dataModelV2-2.4.0-SNAPSHOT
• mqtt: frost-server-mqtt:develop-dataModelV2-2.4.0-SNAPSHOT
• All in one frost-server:develop-dataModelV2-2.4.0-SNAPSHOT

Or build it yourself from the develop-dataModelV2 branch

Enable the V2 model with the environment variables:

# Disable V1 model
plugins_coreModel_enable=false
# Enable model loader, needed for the v2 plugin
plugins_modelLoader_enable=true
# Enable V2 model
plugins_coreModelV2_enable=true
# Enable the (optional) OM model
plugins_modelOM_enable=true
# Enable the (optional) Sampling model
plugins_modelSampling_enable=true
# Enable the (optional) Relations model
plugins_modelRelations_enable=true

The database is currently not compatible with the V1 model, so don't put this over an existing V1.1 installation. Things may also break in the future...

[KathiSchleidt]

Shouldn't we have the core trinity (name, definition, description) of STA attributes on ALL Classes.

Somehow PreparationStepgot linkin place of definition, Sensor has never had a definition. Anything against doing this?

[hylkevds]

I've put the build of my latest draft at: https://hylkevds.github.io/23-019/23-019.html

[hylkevds]

Shouldn't we have the core trinity (name, definition, description) of STA attributes on ALL Classes.

Somehow PreparationStepgot linkin place of definition, Sensor has never had a definition. Anything against doing this?

I think adding a place for an external identifier is a good idea. That also makes it easier to link to other APIs. For Core this would be all classes except Observation and HistoricalLocation? Or should Observation also get one?

[humaidkidwai]

Shouldn't we have the core trinity (name, definition, description) of STA attributes on ALL Classes.

I agree. But wouldn't metadata be then redundant in Sensor entity if definition would essentially define the same?

For Core this would be all classes except Observation and HistoricalLocation? Or should Observation also get one?

I am of the view that Observation should be lean and lightweight for the sensors to push to the server and these attributes wouldn't be very useful. HistoricalLocation however may benefit from definition and shall be more helpful with description

[hylkevds]

definition is a link to an external reference. metadata is also meant to contain the actual SensorML description. There is overlap, since the definition could point to a sensorML description too, but in cases where people do not have an extra external definition server, having the data in the entity would be valuable.