- From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
- Date: Wed, 07 Jun 2017 09:49:37 +0000
- To: Tobias Käfer <tobias.kaefer@kit.edu>, public-sdw-comments@w3.org
- Cc: Andreas Harth <harth@kit.edu>
- Message-ID: <CALsPASUhYkWF-C5AwbUsg427CSA+SAqME0Wpjz1wjcxJGRfNOw@mail.gmail.com>
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 > >
Received on Wednesday, 7 June 2017 09:50:24 UTC