W3C home > Mailing lists > Public > public-sdw-wg@w3.org > February 2017

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

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Tue, 14 Feb 2017 11:59:48 -0800
To: Simon.Cox@csiro.au, maxime.lefrancois@emse.fr, jano@geog.ucsb.edu, armin.haller@anu.edu.au
Cc: public-sdw-wg@w3.org
Message-ID: <8ee63dfd-6a72-a471-a432-67f13652849b@ucsb.edu>
On 02/14/2017 11:54 AM, Simon.Cox@csiro.au wrote:
> > 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.

And language is fluid; we introduce new terms (out of old terms) all the 
time such as 'triplification'.


> Simon
> ------------------------------------------------------------------------
> *From:* Maxime Lefrançois <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
> *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 
> <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.htmlhttps://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0338.htmlhttps://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"
>             <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>;
>             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

Krzysztof Janowicz

Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net
Received on Tuesday, 14 February 2017 20:00:23 UTC

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