- From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
- Date: Tue, 14 Feb 2017 19:41:14 +0000
- To: Krzysztof Janowicz <jano@geog.ucsb.edu>, Armin Haller <armin.haller@anu.edu.au>, Krzysztof Janowicz <janowicz@ucsb.edu>
- Cc: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Message-ID: <CALsPASV1-+AwZz2S-T_m0SN25vpiy9gYiDvgHh3jKLm8AMqPGg@mail.gmail.com>
Hi, I added some content to the wiki page 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> 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/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 > <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> 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 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 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> 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> > 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 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] > Sent: Monday, 13 February, 2017 10:50 > To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; > armin.haller@anu.edu.au; 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 > > > > >
Received on Tuesday, 14 February 2017 19:42:00 UTC