Re: Using SSN/SOSA for Linked Data access to sensors/actuators

Dear Tobias, Andreas,

Thank you for this timely comment, I just created ACTION-374 to add an
example in the spec related to your questions.
See https://www.w3.org/2015/spatial/track/actions/374

I will keep you updated as soon as it is ready and accepted (probably after
the call next Tuesday)

Best,
Maxime Lefrançois

Le mer. 7 juin 2017 à 11:15, Tobias Käfer <tobias.kaefer@kit.edu> a écrit :

> Dear all,
>
> We have a number of IoT devices with sensors and actuators (eg.
> Raspberry PI with SenseHat, or Tessel 2 with corresponding modules) to
> which I am implementing Linked Data access with data described using
> SOSA/SSN [1,2]. The HTTP server directly runs on the device itself. The
> sensors include temperature (yielding degrees celsius), light and sound
> (yielding a number without dimension). The actuators include relays and
> LEDs. I want to describe the devices, sensors, and actuators, and their
> *current* readings/states using SOSA/SSN. In contrast to the examples in
> the SOSA document, I am less concerned with elaborately describing a set
> of observations and actuations that *have been* made and the
> circumstances, but with describing the *status quo* as responses to HTTP
> GET requests in a compact fashion (correspondingly, for actuators in PUT
> requests).
>
> Using SOSA, we got as far as the following (thanks to Maxime for his help):
> A HTTP GET request on /thermometer yields the current reading, eg.:
>
> > @prefix dcterms: <http://purl.org/dc/terms> .
> > @prefix qudt: <http://qudt.org/schema/qudt#> .
> > @prefix qudt-u: <http://qudt.org/vocab/unit#> .
> > @prefix sosa: <http://www.w3.org/ns/sosa/> .
> > <> dcterms:date "2017-05-28" .
> > <#id> a sosa:Sensor .
> > [] sosa:madeBySensor <#id> ;
> >   sosa:hasResult [ qudt:numericValue 20 ;
> >     qudt:hasUnit qudt-u:DegreeCelcius ] .
>
> Are there subclasses of sosa:Sensor? I think that in practice, there are
> a handful of common types, eg. thermometer, barometer, hygrometer,
> magnetometer where it would be great to have terms or examples for.
>
> For the overview of all sensors on a device, would I use rather
> sosa:Platform or ssn:System? What is the rule to decide when to use one
> or the other?
>
> > @prefix sosa: <http://www.w3.org/ns/sosa/> .
> > <#raspberryPi> a sosa:Platform ;
> >   sosa:hosts <#senseHat> .
> > <#senseHat> a sosa:Platform ;
> >   sosa:hosts <thermometer#id> , <ledMatrix#id> .
>
> When it comes to describing actuators and their state, I have the
> following questions:
>
> Are there terms in the vocabulary to state whether something is on or
> off? For instance, in case of a LED in a LED matrix, I currently use
> (excerpt from a response to a GET request):
>
> > <#led> <http://example.org/isOn> false .
>
> In a PUT request, I ignore all but this triple (treating the other
> triples in the spirit of the Linked Data Platform's server-managed
> triples [3]).
>
> Similarly, I have a relay, which can be turned on or off, currently
> modelled in the same manner:
>
> > <#relay> <http://example.org/isOn> false .
>
> Using the sosa:Actuation, I can state that something *has* acted on
> something else, eg., in the SOSA examples, the window closer has acted
> on the state of the window. But how would I say that the window closer
> *acts* on the window's state in general? Or, in my case, that the
> <#relay> acts on the state of a lamp that is plugged into a socket to
> which the relay is attached?
>
> Similarly to my speculated common types of sosa:Sensor's, I think there
> are common types for sosa:Actuator's, too.
>
> Cheers,
>
> Tobias
>
> [1] https://github.com/kaefer3000/t2-rest-relay-ambient
> [2] https://github.com/kaefer3000/t2-rest-leds
> [3] https://www.w3.org/TR/ldp/#dfn-ldp-server-managed-triples
>
>