search

w3c / sdw-sosa-ssn

Repository of the Spatial Data on the Web Working Group for the SOSA/SSN vocabulary
7 stars 5 forks source link

Actuation questions #162

Closed hylkevds closed 5 months ago

hylkevds commented 5 months ago

As inspiration for the STA v2 Tasking model I was looking over the SOSA Actuation part and this raised some questions:

  1. The Procedure attached to the Actuator and Actuation has Input and Output, which I assume (the wording is rather ambiguous on this) are the descriptions of the input and output parameters. But where do the actual input values go? I would expect the Actuation (Or ProcedureExecution) to have something like hasInputValues and hasOutputValues. The example also doesn't have the information whether actuation/188 tried to open or close the window...
  2. Actuation has a Result, but what is this? Is this whether or not the Actuator considers the Actuation to be successful? Or the state of the ActuatableProperty at the end of the Actuation attempt? Or is this the target state of the ActuatableProperty? The Result of an Actuation is often a change in the physical world. To get the information on if the Actuation succeeded we'd need to look at the result of an Observation of a Sensor that measures this. In the case of a thermostat there is usually a significant delay between changing the set-point (of the Actuation) and a change in the system (changing temperature).
  3. Actuation has a resultTime, which is the time the Actuation was completed, but not the time the Actuation was created (createTime? taskingTime?). For some Actuations there may be a significant difference between the two, like an elevator being called to a certain floor. Knowing that an Actuation is currently in progress can be important information in those cases.
  4. Where is the current state of the Actuation? An Actuation may be created (not sent to Actuator yet), queued (elevator going to different floor first), rejected (set-point outside of acceptable range), in progress (elevator on its way), failed (window is stuck), finished (successfully). Currently there seems to be no standardised place to put this information.
  5. ActuatableProperty is the specific Property of the FeatureOfInterest that an Actuator operates on. But this same Property is generally also an ObservableProperty since in most cases where there is an Actuator, there is also an Observer. Which means that the fact that it is Actuatable and/or Observable is only the role of the PropertyInstance in the relation with an Actuator or Observer. So we could simplify the model by merging the two into a PropertyInstance class and making Actuatable/Observable the name of the relation. Or am I overlooking something?
dr-shorthair commented 5 months ago

See existing issues: #113 , #112 , #105

dr-shorthair commented 5 months ago

For 2. see #165 and the proposed additional comment on the Actuation definition.

dr-shorthair commented 5 months ago

Additional guidance on encapsulating complex properties in #178

dr-shorthair commented 5 months ago

On 5. I see no problem with a Property being classified as both ObservableProperty and ActuatableProperty. One of the beauties of the RDFS/OWL set-theory approach is that individuals can be members of more than one set.

dr-shorthair commented 5 months ago

Do you have a proposal on 4. (current state of an actuation)? Can that be managed through a relatedObservation?

I'd be hesitant to add new features if there is a pattern that can be applied using the existing feature-set. Can this be handled with a suitable pattern in the 'Common Modeling Patterns' section?

dr-shorthair commented 5 months ago

@hylkevds do you have a concrete proposal on 4. ?

If so, perhaps create a new, discrete, issue.

AFAICT all the other concerns have been addressed. If you agree can we close this issue?

hylkevds commented 5 months ago

I've not had time to work on 4 yet.