- From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
- Date: Tue, 14 Feb 2017 19:01:44 +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: <CALsPASUCjrdA3LcviFcF5fFv1UfQc4oMLw7o8YoEYVx=6-wMBg@mail.gmail.com>
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:02:31 UTC