[ssn] Generic Sensor API - SOSA Core alignment

Hi,


During TPAC I had a long conversation with Tobie Langel, co-editor of the Generic Sensor API (https://w3c.github.io/sensors/). The aim was that we get consistent naming (https://w3c.github.io/sensors/#naming) across W3C specifications. The main outcome was that he agreed to rename SensorReading<https://w3c.github.io/sensors/#sensorreading> to SensorObservation and potentially Observation. We will need to raise an issue in their Github to initiate this change.

There are several other things we may want to consider in terms of (re)naming and adding classes/properties in the SOSA core.

The spec talks about Sensor Hubs which are multiple sensors “fused” together. An example he gave was a motion sensor in a smartphone which “fuses” information from an Accelerometer, a Gyrometer and a Location Sensor together to determine forward/sideward/backward motion. Fusion can be on a hardware or software level. A “Sensor Hub” could be an alternative additional label for our “Platform” class.

SSN “Condition” is an important attribute for sensors in the Generic Sensor API. We may want to add that back to the SOSA core. The specification distinguishes between:
raw sensor readings<https://w3c.github.io/sensors/#raw-sensor-readings> and
Calibrated<https://w3c.github.io/sensors/#calibration> raw sensor readings<https://w3c.github.io/sensors/#raw-sensor-readings> which may have undergone calibration or sensor fusion. Calibration being performed because the sensor readings are off by some value, while sensor fusion is the process of combining several readings on the software or hardware layer to derive another value.

I think the SOSA core can model these use cases with the use of the “Procedure” class and the “Observation” and “Actuation” classes. Actuation, because some sensor calibration and fusion can be changed through API calls to the sensor, i.e. they act as Actuators. Although Tobie was pretty agnostic about our naming, he felt that Process (instead of Procedurs) would probably be a better term (and also more aligned with SSN). That would probably allow us to have a Superclass (even though we may not have a class hierarchy in the core) between Actuators and Sensors that Maxime was also proposing during the F2F and that we considered earlier in our SOSA core design.

The frequency at which a sensor/actuator can be polled or information is pushed is also important in the Generic Sensor API. Although it is a bit of an implementation detail, we may want to consider putting an attribute in the core that allows us to model that. After all, we want to be able to take all the information that the API is exposing and model it in the metadata.

I would be happy to take on action items from this discussion after we have come to an agreement.

Tobie is also looking for a thesaurus of types of Sensors and a Quality ontology, i.e. in combination to QUDT.

Kind regards,
Armin