Implement Procedure extension

[lieberjosh]

Sensor output may need to be processed in some way to yield useful observations. The procedure for such processing is currently not visible or definable in SensorThings. An extension that added a procedure entity aligned with sosa:Procedure could allow the procedure behind a datastream to be visible or even definable via a service call or supported scripting API. Alternately, additional datastreams could be added for a given sensor to provide refined results, such a moving average or functions of multiple readings such as temperature-corrected altitude.

[KathiSchleidt]

Hi Josh, could you clarify what the Input/Output from SSN would/could be? Could this be a different datastream? :?

[lieberjosh]

Hi Kathi,

Since sosa:Procedure is essentially a recipe that a sensor implements, the ssn:Input and ssn:Output describe what goes into and comes out of the recipe. For example, a thermocouple current or resistance goes into a temperature sensor, perhaps also a calibration curve, and a temperature comes out.

Presumably a STAPI datastream (=sosa:ObservationCollection) will hold not only the sensor constant but also the procedure that it implements and the values of parameter inputs (e.g. height above ground) constant. If parameters change between observations (e.g. some air termperatures measured at 2m height and others at 1m height), that should probably distinguish two datastreams.

Worth noting, though, that there isn’t a lot of detail about Procedures or how to encode them in either O&M or SOSA/SSN, nor clear guidance on where parts of a sensor description go between the Procedure and the Sensor itself, so work would need to be done on this for STAPI.

—Josh

On Nov 16, 2018, at 10:46 AM, KathiSchleidt notifications@github.com wrote:

Hi Josh, could you clarify what the Input/Output from SSN would/could be? Could this be a different datastream? :?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/sensorthings/issues/46#issuecomment-439434673, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhoeDqB5hVwuAgiB4faKQw_3z07gRks5uvt2-gaJpZM4TcEWz.

[KathiSchleidt]

Thanks Josh :) for further clarification - could I state that a sta:Datastream isA ssn:Input for the next Procedure down the processing chain?

[lieberjosh]

Now that gets a little tricky, because sosa:Procedure is a recipe, not a bakery. Might need to have some sort of an ssn:System, e.g. stapi:Process, that implements a Procedure which in turn has for inputs the datatypes of the Datastream elements of interest (e.g. result, time, observed area). Then one would configure that Process to draw from a particular Datastream.

On Nov 16, 2018, at 4:30 PM, KathiSchleidt notifications@github.com wrote:

Thanks Josh :) for further clarification - could I state that a sta:Datastream isA ssn:Input for the next Procedure down the processing chain?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/sensorthings/issues/46#issuecomment-439534693, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhhlz_aulHZI374BReMzqptc7uP3iks5uvy53gaJpZM4TcEWz.

[KathiSchleidt]

but that's where I appreciate STA's split of Datastream and Observations, to my view, the Datasteam becomes the ingredient description while the Observations are the actual ingredient :?

[lieberjosh]

I don’t think it’s exactly a split. A datastream is a convenient collection of observations, not the definition of them. A procedure (e.g. relative humidity) may use temperature measurement as an input, but more than one datastream may collect termperature measurements.

On Nov 16, 2018, at 4:47 PM, KathiSchleidt notifications@github.com wrote:

but that's where I appreciate STA's split of Datastream and Observations, to my view, the Datasteam becomes the ingredient description while the Observations are the actual ingredient :?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/sensorthings/issues/46#issuecomment-439539384, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhh434SheMsv5bojn98BlyZ5J5nclks5uvzJ5gaJpZM4TcEWz.

[KathiSchleidt]

Sorry, my bad, I have the bad habit of doing the procedure per sensor, not per methodology However, for a processed value, you'd need a link on both levels:

• Input as in SSN, providing the abstract input type
• A link to other Datastreams providing the values used for calculation :?

[hylkevds]

A sensor does not have to be modelled as an individual sensor. It can also be a sensor type. In that case you can store the procedure information with the sensor. If you model each sensor you can also do that, but you'd get some duplication.

[KathiSchleidt]

Wait - now we're back to the old argument of if the procedure/Sensor is the class or the instance Under O&M I'd adjusted to the fact that it should be the class of measurement devices, any specific parameterization should be provided in the Observation parameter Is this formally specified in STA, or just devolved from O&M?

[lieberjosh]

There may be some metalevel ambiguities in O&M and SOSA/SSN, particularly with regard to ObservedProperty, but I don’t think this is one of them. Sensor is a class, as are any of the other concepts in the model / ontology. One defines a specific instance of the class to represent observation data. However, that instance may be generic, e.g. all such thermocouple products are reasonably indistinguishable, or it may be specific, e.g. each specific thermocouple has a unique calibration curve and service history. Specificity also affects traceability, e.g. if a Sensor instance is generic, it won’t be possible to ask which specific sensors are mounted on a specific platform. That’s a modeling choice, but not a metalevel issue.

It still leaves open what parameters are recorded in a Procedure, what in a Sensor (is a System), what in a putative Process (is also a System) and what in an Observation. The general principle would be to record them where they are likely to remain most constant, but there is definitely room for modeling choice here as well. STAPI makes some specific choices and not others.

On Nov 17, 2018, at 7:14 AM, KathiSchleidt notifications@github.com wrote:

Wait - now we're back to the old argument of if the procedure/Sensor is the class or the instance Under O&M I'd adjusted to the fact that it should be the class of measurement devices, any specific parameterization should be provided in the Observation parameter Is this formally specified in STA, or just devolved from O&M?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/sensorthings/issues/46#issuecomment-439612324, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhorVwS8nW9gpie_-MNSc-EEDaViMks5uv_26gaJpZM4TcEWz.