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> 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 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
> <kerry.taylor@anu.edu.au>]
> *Sent:* Monday, 3 October 2016 5:05 PM
> *To:* Joshua Lieberman <jlieberman@tumblingwalls.com>
> *Cc:* Maxime Lefrançois <maxime.lefrancois.86@gmail.com>; SDW WG Public
> List <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
> <jlieberman@tumblingwalls.com>]
> *Sent:* Thursday, 29 September 2016 3:59 AM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>
> *Cc:* Maxime Lefrançois <maxime.lefrancois.86@gmail.com>; SDW WG Public
> List <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> 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
> <maxime.lefrancois.86@gmail.com>]
> *Sent:* Wednesday, 28 September 2016 6:53 PM
> *To:* SDW WG Public List <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 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
> Webpage: http://geog.ucsb.edu/~jano/
> Semantic Web Journal: http://www.semantic-web-journal.net
>
>