- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Sat, 8 Oct 2016 13:49:59 -0700
- To: Simon.Cox@csiro.au, jlieberman@tumblingwalls.com
- Cc: kerry.taylor@anu.edu.au, maxime.lefrancois.86@gmail.com, public-sdw-wg@w3.org
- Message-ID: <bbbaffde-db30-a1a4-ca1d-0d7463b6b87f@ucsb.edu>
> I like that. I think it addresses my original concern nicely. > > Though I think I would adjust the naming to ‘stimulusTime’ vs > ‘phenomenonTime’ (the latter is still the time that most users care > about and preserves the current semantics). > > if the stimulus-time is omitted it is assumed to be the same as > phenomenon-time? I like the idea as well. But where is this all going a revised SSN? So are we introducing changes after all? > 1) I think you mean manometer, which depends on the density of > mercury, not its compressibility. Different stimulus. Thanks. On 10/06/2016 11:50 PM, Simon.Cox@csiro.au wrote: > > I like that. I think it addresses my original concern nicely. > > Though I think I would adjust the naming to ‘stimulusTime’ vs > ‘phenomenonTime’ (the latter is still the time that most users care > about and preserves the current semantics). > > if the stimulus-time is omitted it is assumed to be the same as > phenomenon-time? > > *From:*Joshua Lieberman [mailto:jlieberman@tumblingwalls.com] > *Sent:* Thursday, 6 October 2016 9:02 PM > *To:* janowicz@ucsb.edu > *Cc:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; > kerry.taylor@anu.edu.au; maxime.lefrancois.86@gmail.com; > public-sdw-wg@w3.org > *Subject:* Re: SSN Thread for github issue 378 - Side effects of > ssn:Observation being a kind of dul:Event instead of dul:Situation > > Jano, > > 1) I think you mean manometer, which depends on the density of > mercury, not its compressibility. Different stimulus. > > 2) As long as it is clear that the stimulus time has to overlap the > measurement time at least in part. > > 3) Pondering further, I think it makes more sense for a prediction to > estimate an observable property in the future based on present > stimulus / stimuli (related to that property by a model). This does > carry the implication that some other, more contemporaneous stimulus > would also occur in the future if appropriate, but that stimulus would > not be a result of the predictive observation. Instead it would be the > stimulus for another observation that also takes place in the future > and results in another, validating estimate of the observable > property. This should work pretty well to represent both present and > future estimates, however, it will take some elaboration of the time > parameters, namely differentiation of PhenomenonTime from > ObservablePropertyTime. > > Josh > > On Oct 5, 2016, at 5:46 PM, Krzysztof Janowicz <janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>> wrote: > > IMHO, /Stimulus/ is best conceptualized as detectable changes in > the environment that trigger the observation process. In 2010 (for > the SSO) Michael and I wrote: > > "Stimuli are detectable changes in the environment, i.e., in the > physical world. They are the starting point of each measurement as > they act as triggers for sensors. Stimuli can either be directly > or indirectly related to observable properties and, therefore, to > features of interest. They can also be actively produced by a > sensor to perform observations. The same types of stimulus can > trigger different kinds of sensors and be used to reason about > different properties. Nevertheless, a stimulus may only be usable > as proxy for a specific region of an observed property. Examples > for stimuli include the expansion of liquids or sound waves > emitted by a sonar. The expansion of mercury can be used to draw > conclusions about the temperature of a surface that is in close > contact. While the expansion is unspecific with respect to the > kind of surface, e.g., water versus skin, the usage as stimulus is > limited by its melting and boiling points. Moreover, mercury is > not restricted to thermometers but e.g., also used in nanometers. > Note, that the stimulus is the expansion of mercury, not mercury > as such.” > > 1) > > > The last sentence (and assuming this definition is still > valid/acceptable for our current work), is the most important one. > A stimulus is an event (if we really, really, really want to use > these terms). The stimulus also has to start before the > observation can take place. Multiple possible temporal relations > can hold between the two. for instance, the mercury in the text > above will shrink after an measurement procedure (resulting in an > observation) is executed. This will (or will not) keep triggering > a sensor but we stopped caring because we arrived at the > observation we anted to archive. > > 2) > > > I like Josh's idea about predicting future stimuli but would > suggest not to mix this with the notion of an observation. > Predictions about the future are not observations in the sense we > use in the SSN; if they are, they are predictions based on > observations which in turn are based on stimuli that we consider > good proxies for the stimulus we want to predict :-). > > 3) > > > Best, > Jano > > > > On 10/03/2016 08:36 PM, Joshua Lieberman wrote: > > I do mean (topologically not logically) disjoint in time, i.e. > non-overlapping. If “isPostConditionOf” carries a strict > temporal meaning, then it breaks the relationship between > stimulus and observation. You can’t measure a temperature if > the temperature has gone away before you measure it. If the > meaning is only consequential, in the sense of observation > O→stimulus S, then it would be a reasonable predicate. Still > tricky for prediction, i.e. to assert that a stimulus in the > future is a consequence of a prediction in the present. I > suppose one could indicate in some way that it's a weaker > consequence. > > One could also argue that an observation that overlaps its > stimulus in time is a measurement, while an observation that > doesn’t overlap its stimulus is a prediction. A model > procedure can predict the past, the present, or the future, or > none of the above if the model conditions are hypothetical. It > is going to require some more thought, though, to figure out > how to apply the SSN / O&M terms to this situation. Is a > prediction just another procedure within an observation, or is > a prediction a different type of event (e.g. a model run) that > generates an imaginary / potential observation? > > —Josh > > On Oct 3, 2016, at 1:31 PM, simon.cox@csiro.au > <mailto:simon.cox@csiro.au> wrote: > > Weighing in maybe a little late: > > One of the motivations for the term ‘result’ in O&M was > clarification of the post-condition of the observation, > understood as an event. > > And (as Josh has pointed out) the concepts of > phenomenon-time and result-time were also a part of this > story. But O&M also included interpretation, numerical > modelling, and forecasting (i.e. when the phenomenon-time > is later than the result-time), so we need to be careful > here. Perhaps there is a useful taxonomy of observation > types on the basis of the relationship between > stimuls/phenomenon-time/result-time … > > The notion of ‘stimulus’ was a very important contribution > from SSN - George Percivall was on my case about this > early in the story of SWE, but it didn’t get formalized in > the O&M model. But while it is relatively straightforward > how it applies to the classical notion of sensing, I need > some help to understand what the ‘stimulus’ is for a forecast. > > Simon > > *From:*Kerry Taylor [mailto:kerry.taylor@anu.edu.au] > *Sent:*Monday, 3 October 2016 5:05 PM > *To:*Joshua Lieberman <jlieberman@tumblingwalls.com > <mailto:jlieberman@tumblingwalls.com>> > *Cc:*Maxime Lefrançois <maxime.lefrancois.86@gmail.com > <mailto:maxime.lefrancois.86@gmail.com>>; SDW WG Public > List <public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>> > *Subject:*RE: SSN Thread for github issue 378 - Side > effects of ssn:Observation being a kind of dul:Event > instead of dul:Situation > > Hi Josh, > > I am not sure I follow – because I am not clear what you > mean by “disjoint” here. For me, I meant it as “something > cannot be both of those things”, > > but perhaps you mean something about non-overlapping time > intervals? > > If we can’t live with “isPostconditionOf” (and I cannot > find any other alternative in dolce myself, but I would be > very grateful if someone can) then I can see only 3 other > options. > > 1) is to disconnect the observation from the stimulus – > which seems pretty dumb to me and if so then I would > suggest we go even further and just drop stimulus entirely > ( or it could remain connected to a sensor, but if a > sensor could respond to multiple stimuli we would have no > idea which one provoked this observation. Which gives > another option I suppose – insist that each sensor can > have at most one stimulus and then the stimulus could be > retrived with the observation by following the sensor – > but this is yet another change). > > 2) Make up a new term in ssn for the purpose --- but I am > not keen to introduce new terms without a really strong > reason. > > 3)Make up a new term in the alignment (in a new namespace) > but not in ssn proper --- I can’t see much value in that > for anyone. > > I think I can live with “isPostconditionOf” > > Maxime, did you spot any other problems with changing > observation this way? > > --Kerry > > *From:*Joshua Lieberman [mailto:jlieberman@tumblingwalls.com] > *Sent:*Thursday, 29 September 2016 3:59 AM > *To:*Kerry Taylor <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>> > *Cc:*Maxime Lefrançois <maxime.lefrancois.86@gmail.com > <mailto:maxime.lefrancois.86@gmail.com>>; SDW WG Public > List <public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>> > *Subject:*Re: SSN Thread for github issue 378 - Side > effects of ssn:Observation being a kind of dul:Event > instead of dul:Situation > > This seems to be another consequence of the distinction > between Observation as record and Observation as event. It > makes sense that a record be disjoint with and later in > time than a Stimulus (ResultTime vs PhenomenonTime) but if > the event of sensing is disjoint with the Stimulus being > sensed, there generally isn’t going to be any result. > Therefore, if om:Observation is to be adopted, > isPostconditionOf will not be the appropriate relationship > between Stimulus and Observation. > > —Josh > > On Sep 28, 2016, at 9:23 AM, Kerry Taylor > <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>> wrote: > > Maxime, > > Thank you so much for following up on this. > > isPostconditionOf looks ok to me because > > -(1) its rdfs:comment annotation says “ Direct > succession applied to situations. E.g., 'Taking some > rest is a postcondition of my search for a hotel'.” > > -(2) and another reference says ‘"Direct succession > applied to situations. E.g., 'A postcondition of our > Plan is to have things settled'."” > > -(3) it seems to capture the intended relationship > between a stimulus event and an observation. Certainly > we would not want that a stimulus causes an > observation, nor that an observation is a necessary > consequence of a stimulus, but I think we are ok here. > It does say that the stimulus comes first, and then > the observation, but that seems quite ok too. > > Note that the domain and range of isPostconditionOf > are both the union of Event and Situation, so no > problem there. includesEvent had a range of Event, so > this expansion of the range to Event or Situation is > not going to get existing implementations in to > additional trouble (ie beyond the trouble already > implied by the descision to change Observation). > > It is a subproperty of directlyFollows (an > intransitive ordering relation) and an inverse of > hasPostcondition. While these may not have been > intended by the original includesEvent (in which the > situation of observation just includes the Stimulus > event), I cannot see any problem in using > isPostconditionOf, and indeed it looks to me like the > difference in meaning is only the necessary difference > that arises to the move of Observation to an Event. > > So I’d vote for isPostconditionOf, being the closest > match possible to the previous. > > --Kerry > > *From:*Maxime Lefrançois > [mailto:maxime.lefrancois.86@gmail.com] > *Sent:*Wednesday, 28 September 2016 6:53 PM > *To:*SDW WG Public List <public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>> > *Subject:*SSN Thread for github issue 378 - Side > effects of ssn:Observation being a kind of dul:Event > instead of dul:Situation > > Dear all, > > If each github issue shall have its own thread on the > SDW list, this is the one for issue 378 - > https://github.com/w3c/sdw/issues/378 : > > if|ssn:Observation| > <http://www.w3.org/ns/ssn/Observation>is a kind > of|dul:Event| > <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Event>instead > of a|dul:Situation| > > there is an immediate side effect to resolve: > > /axiom:/ > > |ssn:Observation rdfs:subClassOf [ owl:onProperty > dul:includesEvent ; owl:someValuesFrom ssn:Stimulus ] .| > > /context axioms:/ > > |ssn:Stimulus rdfs:subClassOf dul:Event .| > > |dul:includesEvent rdfs:domain dul:Situation ; > rdfs:range dul:Event .| > > /solution to solve the side effect:/ > > replace the mention of|dul:includesEvent|in axiom by a > property that has for domain and range|dul:Event| > > the only such DUL properties > are:|dul:isPreconditionOf|, and|dul:isPostconditionOf|. > > Neither of them seem to fit, > so, should this axiom be simply deleted from the > SSN-DUL alignment ? > > Kind regards > > Maxime Lefrançois > > -- > > 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/ <http://geog.ucsb.edu/%7Ejano/> > > Semantic Web Journal:http://www.semantic-web-journal.net > <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 Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Saturday, 8 October 2016 20:50:38 UTC