Re: Actuation and Actuators in SOSA (issue-91)

Dear all,

I have prepared a wiki page with the comparison between SSN and the 
Thing Description model that is being defined in the WoT Interest Group [1]:

https://www.w3.org/2015/spatial/wiki/Comparison_between_SSN_and_WoT_TD

It is a lightweight comparison at the conceptual level (the Thing 
Description model does not have an OWL implementation yet), and in both 
groups this is work under development.

But surely the document can help people from each group to understand 
what people from the other group are doing. And maybe it can help us in 
some of our discussions.

Since the interested audience can come from both groups, I have tried to 
abstract the document from the current discussions in the group (e.g., I 
mention SSN Core so other people can read it, but it does not entail 
anything against naming SOSA to such core). Furthermore, the idea is not 
to add fuel to our current discussions and because of that I use the 
term "comparison" instead of "alignment", and things like that. In 
summary, see the page as it is, not as a position for some of our issues.

Well, there is some potential issue (the last paragraph in the Sensors 
and Actuators section) that may require a deeper analysis and further 
discussion. But I think that it still is not related to any of our open 
issues.

Feel free to comment on the document (or even to extend it with more 
details).

[1] 
http://w3c.github.io/wot/current-practices/wot-practices.html#thing-description

Kind regards,

El 16/2/17 a las 8:52, Raúl García Castro escribió:
> Hi Kerry,
>
> As you mention, the use cases and requirements are different.
> Nevertheless, I  take the action of analysing the similarities and
> differences among the models and of including them in a wiki page so we
> can take them into account.
>
> Kind regards,
>
> El 16/2/17 a las 3:14, Kerry Taylor escribió:
>> Raul,
>> This seems to be richer than anything we have discussed yet. I wonder
>> whether you would be interested in proposing how to model this in ssn
>> that can afford to be that rich? I don’t' think anyone in the group
>> is working on that already. But Maxime might have started on it. We
>> have our own use  cases of course, but straying into the WoT uses
>> cases as well could certainly help us too.
>>
>> Danh is also working with the WoT group   -- maybe Danh could help
>> with this?
>>
>>> We can align with their terminology using: Actuator, Action,
>>> ActionableProperty.
>>
>> Suits me.
>>
>> And if we have something to offer we should make sure we communicate
>> that back with the WoT group.
>>
>> Thanks very much for doing this background work.
>>
>> Kerry
>> -----Original Message-----
>> From: Raúl García Castro [mailto:rgarcia@fi.upm.es]
>> Sent: Wednesday, 15 February 2017 5:44 PM
>> To: public-sdw-wg@w3.org
>> Cc: public-sdw-wg@w3.org
>> Subject: Re: Actuation and Actuators in SOSA (issue-91)
>>
>> Hi,
>>
>> In the Web of Things IG, three interaction patterns (involving data
>> interchanges) have been defined (not in any specification):
>> https://w3c.github.io/wot/current-practices/wot-practices.html#interaction-patterns
>>
>>
>> * Property (readable and/or writeable data)
>> * Action (changes or processes on a Thing that take a certain time to
>> complete)
>> * Event (mechanisms to be notified by a Thing on a certain condition)
>>
>> We can align with their terminology using: Actuator, Action,
>> ActionableProperty.
>>
>> Also, related to the discussion on what is the result of an Actuation,
>> such result will depend on how the interaction is designed. I quote
>> from the same document: "Usually, invoking an Action results in a
>> response that indicates a new (sub-)resource, where the started Task
>> can be monitored and also controlled".
>>
>> Kind regards,
>>
>> El 15/2/17 a las 0:00, Armin Haller escribió:
>>> Actuatable as suggested by Josh earlier seems to be a widely-used
>>> term, even included in some dictionaries (not “yet” Oxford/Cambridge)
>>> and results in close to a million hits on Google:
>>> https://www.google.com.au/?gws_rd=ssl#q=actuatable
>>>
>>>
>>>
>>>
>>>
>>> *From: *Kerry Taylor <kerry.taylor@anu.edu.au>
>>> *Date: *Wednesday, 15 February 2017 at 9:35 am
>>> *To: *Armin Haller <armin.haller@anu.edu.au>, "Simon.Cox@csiro.au"
>>> <Simon.Cox@csiro.au>, "maxime.lefrancois@emse.fr"
>>> <maxime.lefrancois@emse.fr>, "jano@geog.ucsb.edu"
>>> <jano@geog.ucsb.edu>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>
>>> *Cc: *"public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
>>> *Subject: *RE: Actuation and Actuators in SOSA (issue-91)
>>>
>>>
>>>
>>> My apologies. No offence intended.  Just lazy word selection on my
>>> part before my morning coffee.
>>>
>>>
>>>
>>> Rephrasing:
>>>
>>> And giving the deliberate impression  they are the same by making up
>>> non-English  names to make them “look” the same at the surface level
>>>   does not make any sense to me.
>>>
>>>
>>>
>>> Someone has suggested “Actionable” and someone else “Actuatable”
>>> --these are both very much preferable IMHO (with the first much better
>>> than the second).
>>>
>>> -Kerry
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:*Armin Haller
>>> *Sent:* Wednesday, 15 February 2017 7:54 AM
>>> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>; Simon.Cox@csiro.au;
>>> maxime.lefrancois@emse.fr; jano@geog.ucsb.edu; janowicz@ucsb.edu
>>> *Cc:* public-sdw-wg@w3.org
>>> *Subject:* Re: Actuation and Actuators in SOSA (issue-91)
>>>
>>>
>>>
>>> Please, Kerry, you need to stop using words like “silly”. Group
>>> members are offended by this.
>>>
>>>
>>>
>>> *From: *Kerry Taylor <kerry.taylor@anu.edu.au
>>> <mailto:kerry.taylor@anu.edu.au>>
>>> *Date: *Wednesday, 15 February 2017 at 7:48 am
>>> *To: *"Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>"
>>> <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>,
>>> "maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>"
>>> <maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>>,
>>> "jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>" <jano@geog.ucsb.edu
>>> <mailto:jano@geog.ucsb.edu>>, Armin Haller <armin.haller@anu.edu.au
>>> <mailto:armin.haller@anu.edu.au>>, "janowicz@ucsb.edu
>>> <mailto:janowicz@ucsb.edu>" <janowicz@ucsb.edu
>>> <mailto:janowicz@ucsb.edu>>
>>> *Cc: *"public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>"
>>> <public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>>
>>> *Subject: *RE: Actuation and Actuators in SOSA (issue-91)
>>>
>>>
>>>
>>> I’m sorry I have to disagree with making up a new word (and such an ugly
>>> one – although I admit that is totally a personal reaction).   There are
>>> plenty of good English words out there for what we are trying to
>>> explain here. We are doing no service to anyone to invent such a
>>> meaningless new term.  What is wrong with looking at previous work in
>>> this area? What is wrong with a nice useful word like “affects” that
>>> seems to carry the right idea (I suppose, assuming I ‘get’ the right
>>> idea).
>>>
>>>
>>>
>>> Ø  We need similar concepts for actuation.
>>>
>>>
>>> Not sure…. Could we please see  an explanation for this idea, and some
>>> worked examples ? Most ideally with reference to our own use cases!
>>>
>>>
>>>
>>> Let’s not get too carried away with the idea actuation is just like
>>> observation –that might be true at a surface level but certainly is
>>> not with deeper analysis. And “pretending” they are the same by
>>> making up
>>> silly names to make them “look” the same at the surface level   does not
>>> make any sense to me.
>>>
>>>
>>>
>>> Of course, SENSORML also has something to say in this area. Should we
>>> ignore it? And if so, why?
>>>
>>>
>>>
>>> -Kerry
>>>
>>>
>>>
>>> *From:*Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>
>>> [mailto:Simon.Cox@csiro.au]
>>> *Sent:* Wednesday, 15 February 2017 6:55 AM
>>> *To:* maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>;
>>> jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>; Armin Haller
>>> <armin.haller@anu.edu.au <mailto:armin.haller@anu.edu.au>>;
>>> janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>
>>> *Cc:* Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>;
>>> public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>
>>> *Subject:* RE: Actuation and Actuators in SOSA (issue-91)
>>>
>>>
>>>
>>>> Kerry: ActuableProperty is also not English. What is meant here?
>>>> Perhaps an explanation of the concept would help to choose the term.
>>>> SEAS uses "Property" which suits me, but I guess we are stuck in a
>>>> pattern since we have "ObservableProperty
>>> elsewhere. SAN uses ImpactedProperty which is certainly better, and
>>> that would also suggest actuatedProperty could be 'impacts'. Or,
>>> better still (becuase impacts is too forceful, in general) how about
>>> "affects" and "AffectedProperty"
>>>
>>> In all this we need to preserve the distinction between the class name
>>> and definition, and the associated property name and definition. For
>>> observations we distinguish Observable Properties - i.e. potentially
>>> observable by sensors - from observed properties - i.e. actually
>>> observed in an observation. A set of *observable* properties might be
>>> published in a list or register, for re-use in multiple observation
>>> instances, where their role becomes *observed*.
>>>
>>> We need similar concepts for actuation.
>>>
>>> And yes, "actuable" is a new word, but is clearly related to existing
>>> English and new coinages for specific purposes are nothing new in
>>> technical contexts. Actionable may be an acceptable alternative,
>>> though to me it does not carry quite the same meaning.
>>>
>>> Simon
>>>
>>> ----------------------------------------------------------------------
>>> --
>>>
>>> *From:*Maxime Lefrançois <maxime.lefrancois@emse.fr
>>> <mailto:maxime.lefrancois@emse.fr>>
>>> *Sent:* Tuesday, 14 February 2017 7:01:44 PM
>>> *To:* Krzysztof Janowicz; Armin Haller; Krzysztof Janowicz
>>> *Cc:* Cox, Simon (L&W, Clayton); public-sdw-wg@w3.org
>>> <mailto:public-sdw-wg@w3.org>
>>> *Subject:* Re: Actuation and Actuators in SOSA (issue-91)
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> I added some answers to Kerry's questions in the wiki page
>>> https://www.w3.org/2015/spatial/wiki/Actuation
>>>
>>>
>>>
>>>
>>>
>>> These are copied here:
>>>
>>>
>>>
>>> /Kerry: can we reconsider the names please? "actsOnProperty" (from
>>> SEAS) instead of "actuatedProperty" (does not follow active property
>>> naming convention, is not English)/
>>>
>>> /- Maxime: +1 for "sosa:actsOnProperty/sosa:isActedOnBy" and
>>> "sosa:observesProperty/sosa:isObservedBy", for the sake of having
>>> consistent naming conventions./
>>>
>>> /Kerry: ActuableProperty is also not English. What is meant here?
>>> Perhaps an explanation of the concept would help to choose the term.
>>> SEAS uses "Property" which suits me, but I guess we are stuck in a
>>> pattern since we have "ObservableProperty elsewhere. SAN uses
>>> ImpactedProperty which is certainly better, and that would also
>>> suggest actuatedProperty could be 'impacts'. Or, better still (becuase
>>> impacts is too forceful, in general) how about "affects" and
>>> "AffectedProperty"/
>>>
>>> /- Maxime: related emails in the
>>> list:
>>> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0335.htmlht
>>> tps://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0338.html
>>> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0339.html
>>> ./
>>>
>>> /- Maxime: propose: "sosa:ActionableProperty"/
>>>
>>> /Kerry: What is a Phenomenontime in this context? As distinct from a
>>> ResultTime? Why do we need it?/
>>>
>>> /- Maxime: AFAIK, resultTime can be later than phenomenonTime. As an
>>> example in the spec, maybe we could use the example of an astronomical
>>> telescope that outputs today some phenomenon that occurred many years
>>> ago?/
>>>
>>> /Kerry: What is the impact on SSN?/
>>>
>>> /- Maxime: should we duplicate any axiom that exists for Observation
>>> and adapt it for Actuation?/
>>>
>>> /- Maxime: should we decide which of the MeasurementProperty can also
>>> apply to Actuators? As a first guess, I would say Accuracy,
>>> ActuationLimit, Drift, Frequency, Latency, Precision, Resolution,
>>> ResponseTime, all apply to Actuation/
>>>
>>> /- Maxime: I believe all of the OperatingProperties also apply to
>>> Actuators./
>>>
>>>
>>>
>>>
>>>
>>> Best,
>>>
>>> Maxime
>>>
>>>
>>>
>>> Le lun. 13 févr. 2017 à 10:55, Maxime Lefrançois
>>> <maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>> a écrit :
>>>
>>>     Dear Simon, all,
>>>
>>>
>>>
>>>     From my side, it's 'yes' to your second question.
>>>
>>>
>>>
>>>      - if requirement 5.27 [1]  is sufficient to motivate the addition
>>>     of actuator/actuation, then requirement 5.16 may be sufficient to
>>>     motivate the addition of the Samping side of the system.
>>>
>>>      - as far as I know, not all of GoodRelations has been swallowed by
>>>     schema.org <http://schema.org> anyways, and this is managed by the
>>>     W3C Schema.org Community Group [2]. So it's not a 'all or nothing'
>>>     matter there. If Samping is is SOSA and the schema.org
>>>     <http://schema.org> community doesn't want sampling, then it won't
>>>     make them reject Actuation.
>>>
>>>
>>>
>>>     +1 for Simon to create a wiki page with turtle snippets that explain
>>>     your proposal, (potentially multiple options) ?
>>>
>>>
>>>
>>>     @Jano, could you also write turtle snippets for your proposed
>>>     alternative in the Wiki ?
>>>
>>>
>>>
>>>     Kind regards,
>>>
>>>     Maxime
>>>
>>>
>>>
>>>
>>>
>>>     [1] - https://www.w3.org/TR/sdw-ucr/#ExSituSampling
>>>
>>>     [2] - https://github.com/schemaorg/schemaorg
>>>
>>>
>>>
>>>     Le lun. 13 févr. 2017 à 08:14, Krzysztof Janowicz
>>>     <jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>> a écrit :
>>>
>>>         Hi Simon, Armin, all,
>>>
>>>         I fully agree with keeping SOSA as minimalistic as possible.
>>>         This is a key design goal. The changes I proposed are a reaction
>>>         to issue-91 and other change requests and they are minimal in
>>>         nature by only introducing one class and one property. They are
>>>         also in line with other work on actuators. The fact, that such
>>>         minimal changes were sufficient to address the outstanding
>>>         issues shows that by now SOSA seems to stabilize and is well
>>>         designed. One could even fix these issues by an even more
>>>         minimalistic change, I will implement this tomorrow as
>>> alternative.
>>>
>>>         As far as sampling is concerned, I absolutely agree that Sample
>>>         needs to be in SOSA. Whether it is of equal importance compared
>>>         to observations and actuations is difficult to say. Simon, may I
>>>         suggest that you create a similar example for sampling? If all
>>>         we need would be just one or two more classes, then I would
>>>         support to add it. Otherwise, we could leave Sample in there as
>>>         stub and add more axioms to the new SSN.
>>>
>>>         More generally speaking (and leaving the sampling issue aside),
>>>         my big concern is that we will start doing this for 10 more
>>>         cases, thereby ruining the entire idea of a lightweight SOSA. To
>>>         be very clear about this, I created this proposal because I was
>>>         tasked to do so. I believe that SOSA will be fine with said
>>>         changes (as they are minimal) to better support actuation but
>>>         that SOSA would also remain valuable without these changes. If
>>>         this opens the flood gates to tons of change requests for new
>>>         classes and properties, I would strongly prefer to leave SOSA as
>>>         is. SOSA was never designed to capture all use cases and all
>>>         details in a balanced way as this is the task of the SSN.
>>>
>>>
>>>         Cheers,
>>>
>>>         Jano
>>>
>>>
>>>
>>>         On Sun, Feb 12, 2017 at 10:11 PM, Armin Haller
>>>         <armin.haller@anu.edu.au <mailto:armin.haller@anu.edu.au>>
>>> wrote:
>>>
>>>             I will raise the question of Sampling in the core in the
>>>             discussion around Actuation in our next telco.
>>>
>>>             In terms of Actuation we have several use cases that require
>>>             actuation: https://www.w3.org/TR/sdw-ucr/#ModelActuation I
>>>             believe we need to have a strong argument why to not include
>>>             it in the core.
>>>
>>>             Personally, I think Actuation should be in SOSA as many IoT
>>>             applications on the Web will include Actuation. Even many of
>>>             the IoT home devices available in Apple Stores include
>>>             actuation (turning light on, recording your favourite show
>>>             over Siri, Cortana, Amazon Echo, changing the thermostat
>>> etc.).
>>>
>>>             On 13/2/17, 11:50 am, "Simon.Cox@csiro.au
>>>             <mailto:Simon.Cox@csiro.au>" <Simon.Cox@csiro.au
>>>             <mailto:Simon.Cox@csiro.au>> wrote:
>>>
>>>                 Thanks Jano.
>>>
>>>                 The proposal is exactly in line with expectations.
>>>
>>>                 However, I am concerned that we should clarify the scope
>>>             (and size) of SOSA. Specifically,
>>>                 1. do the requirements for SOSA include a basic
>>>             actuation model?
>>>
>>>                 If that is the case then
>>>                 2. should the Sampling side of the system also need to
>>>             be fleshed out?
>>>                 I could make a proposal for this, but had been holding
>>>             back because I had assumed that was probably out of scope
>>>             for most SOSA users, and should rather be the subject of a
>>>             vertical (richer axiomatization) + horizontal (additional
>>>             scope) extension to SOSA.
>>>
>>>                 In developing SOSA until now we have generally leaned
>>>             towards parsimony - lets minimise the number of concepts in
>>>             SOSA to a core that might be useful to schema.org
>>>             <http://schema.org> folk.
>>>
>>>                 BTW - I'm OK with the answers to these two questions
>>>             being 1. Yes, and 2. No, but wanted to put the issue on the
>>>             table so we are all clear about what is being ruled in, and
>>>             what is out.
>>>
>>>                 And just in case there is any question, even if it is
>>>             "2. No", Sample still belongs in SOSA, as it is critical for
>>>             many (most?) observations.
>>>                 It would just be sampling and sample preparation that
>>>             would be delegated elsewhere.
>>>
>>>                 Simon
>>>
>>>                 -----Original Message-----
>>>                 From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu
>>>             <mailto:janowicz@ucsb.edu>]
>>>                 Sent: Monday, 13 February, 2017 10:50
>>>                 To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au
>>>             <mailto:Simon.Cox@csiro.au>>; armin.haller@anu.edu.au
>>>             <mailto:armin.haller@anu.edu.au>; public-sdw-wg@w3.org
>>>             <mailto:public-sdw-wg@w3.org>
>>>                 Subject: Actuation and Actuators in SOSA (issue-91)
>>>
>>>                 Dear all,
>>>
>>>                 I added a wiki pages that shows a concept map for the
>>>             changes to be made on the Actuator and Actuation side of
>>>             SOSA. The proposed changes address some shortcomings of the
>>>             current model and are also in preparation for a deeper
>>>             axiomatization in SSN.
>>>
>>>                 There are two major (but in no sense dramatic changes)
>>>             to SOSA, namely a proposal to add the SOSA:actuatedProperty
>>>             role and a class called SOSA:ActuableProperty.  These are in
>>>             line with previous work and requests made on this list.
>>>
>>>                 I hope you can look at the concept map and the notes on
>>>             the wiki page as I hope we can get this resolved during our
>>>             next teleconference. Please keep in mind that everything
>>>             that is not shown in a dashed style is already part of SOSA.
>>>
>>>                 https://www.w3.org/2015/spatial/wiki/Actuation_in_SOSA
>>>
>>>                 Best,
>>>                 Jano
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>


-- 

Dr. Raúl García Castro
http://www.garcia-castro.com/

Ontology Engineering Group
Departamento de Inteligencia Artificial
Escuela Técnica Superior de Ingenieros Informáticos
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 65 96 - Fax: +34 91 352 48 19

Received on Tuesday, 21 February 2017 14:06:41 UTC