Re: SSN Thread for github issue 378 - Side effects of ssn:Observation being a kind of dul:Event instead of dul:Situation

The answer to Rob’s question is — Yes. Almost any observation involves a model that connects one or more measurable phenomena to a feature property. That model may be functional and involve a physical theory. It may be statistical, or purely heuristic, in that the model relationship is verified in some way, or even completely fanciful (astrology) but it is still a model. 

From this point of view, “stimulus” has a very specific meaning. It is the occurrence of a measurable phenomenon that models a feature property we are interested in estimating. If color is a feature property, then light scattered or emitted by the feature is a stimulus that can be captured and its spectrum deconvolved by a sensor. It “stimulates” the sensor, which responds in some way that can be interpreted (voltage, neuron firing, etc.). The word “stimulus” is obviously used in many other ways, but this is my understanding (today) of the SSN concept.

The directness of the model may vary.  The color of something can be measured fairly directly: light coming off the object -> light impinging on a sensor. Other properties, such as ocean water primary productivity, involve a bunch of measurements of different phenomena over a time period, related to the target property by partly functional, partly heuristic models.

All models “predict” an output based on inputs. Whether that output is before, during, or after the inputs is just one more model parameter. The big difference between a future prediction and other model configurations is that we usually have to wait until the time of the future output to validate the result.  As Chris points out, the most direct, instantaneous stimuli from some properties are so difficult or impossible to observe directly that models relying on indirect, time-shifted, and/or time-integrated inputs may actually be more accurate. 

This leads to a question about SSN and theories of observation. If SSN covers all of the activity stages from the occurrence of stimuli to the resulting property estimation, then it had better cover future (as well as past and present) predictions. If SSN only wants to cover some arbitrarily direct path from stimulus to sensor response, then it won’t be nearly as useful for representing the ways in which sensors are used to observe the world.

Josh

> On Oct 6, 2016, at 11:58 AM, Little, Chris <chris.little@metoffice.gov.uk> wrote:
> 
> HI All,
>  
> Weighing in a little late too.
>  
> From my point of view, the stimulus for a prediction, or estimate of a measurable quantity for some time in the future, is just the need or decision to initiate the prediction for the estimate. Someone  pressing a button.
>  
> There is a relationship between the prediction and an actual observation made later, in that the observation verifies, and validates, the prediction.
>  
> Some predictions, for some parameters and timescales, are so accurate that they are actually, on average, more accurate than an actual observation.
>  
> Or is that hopelessly naïve?
>  
> Chris
>  
> PS In the 1850s, FitzRoy invented the word ‘forecast’ because he thought that the word ‘prediction’ had implications of too much precision!
>  
> From: Rob Atkinson [mailto:rob@metalinkage.com.au] 
> Sent: Thursday, October 06, 2016 12:18 AM
> To: janowicz@ucsb.edu; Joshua Lieberman; simon.cox@csiro.au
> Cc: 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
>  
>  
> 
> Is there a requirement that the nature of the stimulus can be modelled with respect to the property being observed - or is it an arbitrary implicit relationship?
> 
>  
> 
> So is a stimulus a clock interacting with an observing schedule, or a "sensor planning" event? AFAICT his would handle forecasts, satellite imaging etc
> 
>  
> 
> rob
> 
>  
> 
> On Thu, 6 Oct 2016 at 08:46 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."
> 
> 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. 
> 
> 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 :-).
> 
> 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 <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 <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 <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 <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 rangedul: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/~jano/>
> Semantic Web Journal: http://www.semantic-web-journal.net <http://www.semantic-web-journal.net/>