Mirror Tasking and Sensing

[hylkevds]

Currently, a Datastream links to Thing, Sensor, ObservedProperty and Observations
A TakingCapability links to Thing, Actuator and Tasks

Datastream	TaskingCapability
Thing	Thing
Sensor	Actuator
Observations	Tasks
ObservedProperty	?

It may make sense to give an Actuator an optional many-to-many navigation property ControlledProperty, pointing to ObservedProperty. This would make it easier to discover the relation between the Task, and the Observations that show the effects of the Task, when a Thing has multiple Sensors and Actuators.

@alexrobin: Do you have some examples of SWE encoding of combinations of Sensors/Actuators that measure and control the same property? I think in OSH you also link Tasks to a FeatureOfInterest, right? What are the semantics behind that relation?

[alexrobin]

Yes, in OSH we can link tasks to FOIs. In that case, the FOI identifies the feature that the task has an impact on. The FOI is not necessarily the object that is being controlled. It can be other (often remote) entities as well. For example, we may want to identify an object that is tasked to be moved, an area that is tasked to be imaged, etc.

If the FOI that is affected by a task is the same as the FOI being observed, then you have a link like the one you are talking about above.

[hylkevds]

SOSA also mirrors Sensing into Tasking: https://w3c.github.io/sdw-sosa-ssn/ssn/#Actuations
The ObservedProperty is mirrored as ActuatableProperty
This would require us to rename the ObservedProperty class into just Property, and have ObservedProperty and ActuatableProperty as role names for the relations from Datastream and TaskingCapability.

sosa:Actuation seems to be our sta:Task
Interestingly, sosa:Actuation has a result, but not a "desired result" or command or so.

[hylkevds]

A first proposal for an update to the Tasking data model, illustrating the mirroring of Tasking and Sensing: