W3C home > Mailing lists > Public > public-sdw-wg@w3.org > September 2016

Re: [ssn] Generic Sensor API - SOSA Core alignment

From: Joshua Lieberman <jlieberman@tumblingwalls.com>
Date: Fri, 30 Sep 2016 09:44:21 -0400
Cc: SDW WG Public List <public-sdw-wg@w3.org>
Message-Id: <A748CEEC-2B69-4334-B1B7-6C38E148D8A5@tumblingwalls.com>
To: Armin Haller <armin.haller@anu.edu.au>
Just a note that OGC is also developing Sensor Hub (S-Hub) as a component concept and potential standard. It has a broader defined function than just grouping sensors. Essentially it serves as the bridge or mapper between local sensor protocols and OGC SWE-IoT services. A side effect may be to group sensors and derive higher-level observations from their readings. Several software Sensor Hub implementations are now available, including Open Sensor Hub (opensensorhub.org <http://opensensorhub.org/>). The harmonization issues around sensors and sensing are not getting any easier.

Josh

Joshua Lieberman, Ph.D
Principal, Tumbling Walls
jlieberman*tumblingwalls.com
+1 617 431 6431

> On Sep 30, 2016, at 6:19 AM, Armin Haller <armin.haller@anu.edu.au> wrote:
> 
> Hi,
>  
> During TPAC I had a long conversation with Tobie Langel, co-editor of the Generic Sensor API (https://w3c.github.io/sensors/) <https://w3c.github.io/sensors/)>. The aim was that we get consistent naming (https://w3c.github.io/sensors/#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


Received on Friday, 30 September 2016 13:45:13 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:26 UTC