What is the result of an actuation ?

[maximelefrancois86]

An actuation can use a procedure, that is described in terms of input and output.

I can guess the output of an observation procedure is a description of the expected result. I can guess the input of an actuation procedure is a description of the expected parameters of the actuation.

Now how does the 'input' of the procedure translates on the observation itself ? And what is the result of an actuation ? is it a resulting property value ? a response code ?

Wouldn't it be more appropriate to model the argument of an actuation ?

Proposal: clarify input/output in SSN, and model the arguments of an actuation (sosa:hasArgument)

[dr-shorthair]

Another way of thinking about it is in terms of state before and after the activity.

Observation: before=property value unassigned; after=property value assigned

Sampling: before=no sample ; after=sample exists

Actuation: property value=X ; property value=Y

Until now we had not made the prior state explicit, but perhaps it is important in the case of actuation

[dr-shorthair]

FWIW in many (most, all?) cases, sampling is a special case of actuation. The real world is different after the activity.

OTOH observation is a different thing. What we know about the world is the primary change.

[rob-metalinkage]

OK - Heisenberg aside, why not just have observations before and after and an optional property with the observed state of the actuation - i.e. the an observation on the result of the observation of the real world with a procedure specific to determine actuation completion. That way we need no special capability to describe "the state of the world before" above and beyond normal Observation.

[dr-shorthair]

@rob-metalinkage are you suggesting adding explicit links from Actuation to two Observations - one before and one after the resultTime?

Of course many real systems would have this built into the workflow. It is implicit in servo systems.

[dr-shorthair]

Re-engaging with this issue:

I always assumed that hasResult should indicate the intended value of the ActuatableProperty on completion of the Actuation, i.e. at the resultTime.

(hasInput and hasOutput are not related to the act-of-actuation directly, they are associated with the Procedure).

(Less clear to me is what phenomenonTime means in the context of an Actuation or Sampling.)

[hylkevds]

Some thoughts on that:

• An Actuator may influence several ActuatableProperties. How to differentiate the different Results?
• The ActuatableProperty may not reach its target value until long after the Actuation has completed. Unless, for example in the case of an Thermostat, the ActuatableProperty is only the set-point, and not the actual Temperature. But that would not be a very useful way to model things.
• It is an interesting idea for those cases where the inputs are only indirectly related to the desired value(s) of the ActuatablePropert(y|ies), since it would indicate the intent, but in other cases it would duplicate the values of the input.

Personally I see more value in having the result indicate the state of the Actuation itself. Did it succeed or fail, or was it rejected, or is it still being processed. Though a better name for that would be state, not result.

I would say that one can not directly record the result of an actuation, and one may need to make many Observations to witness the final result of the actuation. In many cases there may not be a "final" result, and one can only say that a certain ObservationCollection may contain Observations that show the influence the Actuation had on the ActuatablePropert(y|ies) For this reason I would remove result from Actuation, and add a way for a user to find those Observations.

[dr-shorthair]

@hylkevds I've made a concrete proposal to resolve this in #165 Could you formulate your alternative proposal in another branch perhaps?

(Note: We have an April deadline so by this stage our ruminations must be converted into concrete proposals quickly if they are to have any chance of making it into the new edition.)

[dr-shorthair]

See #105 for discussion of inputs and outputs

[dr-shorthair]

@hylkevds asked:

An Actuator may influence several ActuatableProperties. How to differentiate the different Results?

A general simplifying principle across SOSA is cardinality=1 for hasFeatureOfInterest, observedProperty/actsOnProperty, hasResult, usedProcedure, madeBySensor/madeByActuator/madeBySampler. If your application is more complex then either

• break the actions into parallel or sequential atoms which satisfy the cardinality constraint - you can then make these part of an ObservationCollection if required
• make the Property and Result a vector somehow - but this is something that must be handled by the domain or application, and is outside the scope of SOSA/SSN

Perhaps there is a need for an ActuationCollection ?

[hylkevds]

sosa:Actuation sosa:actsOnProperty MIN 1

That's not cardinality=1. If the design is for all those cardinalities to be MAX 1, then that needs to be specified explicitly, since otherwise things will break.

The simple solution would be to use the Result class to bind the value to the property.

[dr-shorthair]

Thanks - I had not noticed that. If I had I would have questioned it because it violates the pattern that was established since 20 years relating to Observations which we had intended to carry over to the other procedure executions.

The intention was always to put a boundary between the general model - where the cardinalities are all 1 - and any application specific specializations - where a domain might have a way to define and track compound or vector properties and results, but which is beyond the scope of the general model.

@maximelefrancois86 do your applications have multiple actuatable properties on an actuation? Could we tighten this up or would that break the legacy?

[hylkevds]

Regarding the example of a heating with only an on-off switch to control the temperature in a room. Technically the ActuatableProperty would be the state of the switch, but this is not really useful for users, since a user will want to change the temperature because he is feeling cold (or hot). So this user will look at the Temperature, and try to find an actuator to influence this temperature.

We may need an ultimateActuatableProperty and an ultimateResult, like we have ultimateFeatureOfInterest on Observation to signal that the FeatureOfInterest is only a sample. This would signal to the user that the Actuator only indirectly influences the Property... Though that may complicate things too much...

[dr-shorthair]

New issue on result cardinality here: #174

[dr-shorthair]

PR #165

[dr-shorthair]

Closed by #178