- From: Kerry Taylor <kerry.taylor@anu.edu.au>
- Date: Thu, 16 Feb 2017 02:14:30 +0000
- To: Rob Atkinson <rob@metalinkage.com.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, Raúl García Castro <rgarcia@fi.upm.es>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Message-ID: <SYXPR01MB15362806A2B1930B899F55EAA45A0@SYXPR01MB1536.ausprd01.prod.outlook.com>
Hi Rob, This is really interesting, as it speaks to what we should be trying to do in sosa for acutation– I don’t think that has been either asked or answered before this. -For ssn full – it makes a lot of sense to include actuation at least as a method the record device capability – this is a natural extension to ssn’s focus on sensor capability. And possibly more too (is it useful for after-the-fact recording of what happened, for example?). -For WoT it makes a lot of sense because they want to be able interrogate a registry of Things to ask something like “who can turn the temperature of this room down?” For this devices need to be able to express what they can do, and what they want to do. And then (I think) they want to talk to that device and ask it to turn the temperature down. For sosa: in its goal to be the simple markup for data on web pages (and other places too, I expect) I wonder what Actuation needs to do? Is it to report post-hoc processing ( e.g. After requesting the actuator to raise the temperature then the was observed to be 20 degrees)? In which case we need some use cases, and examples that show how these would work (and for this one don’t we need some quite complex modelling )? Does this use case require observable and “actuatable” (or whatever it is called) Properties to be distinguished? Probably not? OTOH I agree that since sosa is our “lightweight core” we *should* be having some “lightweight” capability to model actuation for “lightweight” devices. What is the use case for that capability? Is it the same as WoT use cases ? Can someone articulate this? Do we want sosa to be usable to actually actuate some device? Do we want ssn full to do this? Or does someone have another use case in mind that they could share? Even our own use cases --- how should they be served in sosa? Ø So +1 to having both actuation and samples in SOSA, and a suggestion that our prime focus for SOSA from here is to adequately visualise and explain how these pieces interact as guidance to users. I’m quite ok with that, but would you be able to speak a bit further for the Actuation context, in particular i.e. what it is it about Actuation that needs visualisation and explanation? -Kerry From: Rob Atkinson [mailto:rob@metalinkage.com.au] Sent: Wednesday, 15 February 2017 9:44 AM To: janowicz@ucsb.edu; Raúl García Castro <rgarcia@fi.upm.es>; public-sdw-wg@w3.org Subject: Re: Nine new questions for Actuation and Actuators. Was: Actuation and Actuators in SOSA (issue-91) A few thoughts on Actuation being included: again from a particular perspective of helping communities of practice try to interpret O&M, and more generally struggle with the biggest cause of woe in the spatial world: confusing geometry with identity and getting into a nightmare of non-unique naming and no way to resolve thins. Specifically, naming properties and identification of the actual feature of interest always seems to be at the nub (is it a sample, or what we are setting out to measure, and use of indirect properties - e.g. satellites do not observe vegetation cover directly.) Many communities of practice tend to conflate the samplingFeature and FeatureofInterest and the property being observed is assumed knowledge, and not explicitly documented sometimes. So, IMHO the most critical aspect here is the means to be specific about what is being observed, and without SOSA including the properties and their relationships to different types of features it probably cannot be used in consistent ways in practice. So +1 to having both actuation and samples in SOSA, and a suggestion that our prime focus for SOSA from here is to adequately visualise and explain how these pieces interact as guidance to users. We have diagrams for the established patterns of how a sensor relates to a property etc are easy to understand once one understands the nature of feature properties, and these are useful to show current naming proposals - but we are in a bind not having the same understanding how properties and reported results work. Rob On Wed, 15 Feb 2017 at 08:09 Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> wrote: > This afternoon, when taking a look at the wiki, I didn't even have > sure what we were going to vote, since in the figure a lot of things > appear beyond the basic discussion such as the relationship of > actuators with platforms or the time-related properties. Just for clarification, everything that was not dashed was/is in SOSA already. On 02/14/2017 12:32 PM, Raúl García Castro wrote: > Dear Krzysztof, > > I have to agree and disagree with you. > > I also think that we must take decisions one by one, and that is what > Maxime is trying to do by identifying the atomic decisions we have to > make. > > This afternoon, when taking a look at the wiki, I didn't even have > sure what we were going to vote, since in the figure a lot of things > appear beyond the basic discussion such as the relationship of > actuators with platforms or the time-related properties. > > Besides, being SOSA the core module of SSN, it is a need to put any > decision in the broad context of SSN (even if taking decisions on SSN > come later in the backlog. > > Kind regards, > > El 14/2/17 a las 20:50, Krzysztof Janowicz escribió: >> Maxime, >> >> Thanks a LOT for doing all this, but you are moving a bit too fast :-). >> The idea was to discuss and take decisions step-by-step, if we combine >> different topics into larger and larger bundles, it will be difficult to >> make decisions. Let's keep the individual issues and proposed solutions >> as atomic as possible :-). See also my mail about feature creep. The >> wiki page was only designed for the SOSA part. We can (and probably >> should) add more on actuators and actuation into SSN, but we should not >> try to add all of this into SOSA. >> >> Cheers, >> Jano >> >> On 02/14/2017 11:41 AM, Maxime Lefrançois wrote: >>> Hi, >>> >>> I added some content to the wiki >>> page >>> <https://www.w3.org/2015/spatial/wiki/Actuation>https://www.w3.org/2015/spatial/wiki/Actuation >>> : >>> >>> nine questions and the currently proposed options. I think we can vote >>> for some today, but there is obviously some things one need to agree >>> on quite urgently. >>> >>> Question 1: ok for a complete actuator/actuation/xxxProperty model in >>> sosa? ok to reflect this in snn? >>> Question 2: naming of xxxProperty >>> Question 3: naming of the link between Actuation and xxxProperty >>> Question 4: naming of invoked/invokedBy vs madeObservation/?? >>> Question 5: Result and Command ? >>> Question 6: phenomenonTime and resultTime >>> Question 7: axioms in SSN >>> Question 8: measurement properties in SSN >>> Question 9: operating properties in SSN >>> >>> For now there is currently no turtle snippet or pull request for each >>> of the proposed options, so I believe we can only vote for Question 1 >>> today. >>> >>> Kind regards, >>> Maxime >>> >>> Le mar. 14 févr. 2017 à 20:01, Maxime Lefrançois >>> <maxime.lefrancois@emse.fr<mailto:maxime.lefrancois@emse.fr> <mailto:maxime.lefrancois@emse.fr<mailto:maxime.lefrancois@emse.fr>>> a >>> écrit : >>> >>> 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.html<https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0338.html>https://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> <mailto: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> <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> <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 >>> <<mailto:jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>>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 >>> <<mailto:armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>>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>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> <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:<mailto:janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>>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>>; >>> <mailto:armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>>armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>; >>> public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org> <mailto: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<mailto:jano@geog.ucsb.edu> >> Webpage: http://geog.ucsb.edu/~jano/ >> Semantic Web Journal: http://www.semantic-web-journal.net >> > > -- Krzysztof Janowicz Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu> Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Thursday, 16 February 2017 02:15:55 UTC