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

Struggling to reconcile the underlying goal with the details here...and
throw myself into the fray as someone who really doesnt have a vested
interest in any specific outcome, but a strong desire for a good one that
can be a game changer :-)

my perspective -
1) a concept of sensors without observations - i.e. describing sensor
characteristics, not outputs, would be quite useful
2) a generalised approach to observations including a canonical approach to
describing the relationship of sensors to observations is much harder to
achieve but much more useful
3) a model for sensors with an incomplete model of observations that need
to be reconciled with other idosyncratic models of observations would be
painful in a context where sensors are but one part of a system.
4) evidence of implementation to demonstrate need and effectiveness is one
perspective - evidence of need based on incompatible implementation of
ad-hoc alternatives is another viable view

The question is perhaps whether the status of the document is more
important than the scope/usefulness/completeness/consistency of its
content? That perhaps is a value judgement?  If it were possible to extract
the subset of SSN (with implementation record) that does not address
observation acts, but publish alongside a more general applicable, but less
mature, guidance note on observations, and show how it may be used in that
context, that would feel like quite a good achievement.

>From a "implement a system tomorrow" perspective, I'd choose a complete
treatment as a Note, over yet another fragmentary solution I have to try to
work out how to fit it together in a consistent way.  I feel there is
enough interested brain power at the table to make a good stab at that,

Rob Atkinson




On Mon, 10 Oct 2016 at 09:53 <Simon.Cox@csiro.au> wrote:

> Ø  And btw this cannot be done if an ssn:observation becomes an “act”.
>
>
>
> I don’t understand this comment.
>
>
>
> The ‘act-ness’ of observation is emerges from the ‘result-time’ property –
> this was why result-time was included in O&M, and why it is distinct from
> phenomenon-time (the time the value applies in the world).
>
>
>
> Josh’s proposal (i.e. to also add a “stimulus-time” property) appears to
> reconcile all the requirements. A prediction or forecast is merely an
> observation whose stimulus time is usually prior to but may be contemporary
> with the result-time, and is prior to the phenomenon-time.  The temporal
> logic is key, but requires multiple time properties.
>
>
>
> Ø  the only challenge I foresee is whether we can feel comfortable with
> the idea that a  sensor ontology also sneaks forecasting in, and that
>  “Sensing” includes forecasting and that a “sensor” implements forecasting.
>
>
>
> Maybe the issue is around whether we consider this a ‘sensor’ ontology
> (indeed, that is in the SSN name) or an ‘observation’ ontology. If it is
> narrowly the former, then those of us interested in the more general case
> may have to go elsewhere. But I thought the group (and the UCR) was
> comfortable with dealing with ‘observations’.
>
>
>
> Simon
>
>
>
> *From:* Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
> *Sent:* Sunday, 9 October 2016 12:35 PM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>; janowicz@ucsb.edu; Cox,
> Simon (L&W, Clayton) <Simon.Cox@csiro.au>; jlieberman@tumblingwalls.com
> *Cc:* 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
>
>
>
> Btw, this discussion is a little confused. SSN has only an
> “observationResulttime” and an “observationSamplingtime”, copied here
> below. Simply expanding the scope of  “ssn:observationSamplingTime”  to
> include a stimulus  might be an easy, very low impact,  way to achieve this
> goal, if I understand it?
>
>
>
> I **think** josh’s goal to
>
> >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?
>
>
>
> Can also be achieved by the simple trick of changing the textual
>  description  of an ssn:observation, and a few other terms, with no nasty
> effect on backward compatibility – the only challenge I foresee is whether
> we can feel comfortable with the idea that a  sensor ontology also sneaks
> forecasting in, and that  “Sensing” includes forecasting and that a
> “sensor” implements forecasting. Not really our business?
>
>
>
> And btw this cannot be done if an ssn:observation becomes an “act”.
>
>
>
> -Kerry
>
>
>
> ###  http://www.w3.org/ns/ssn/observationResultTime
>
> ssn:observationResultTime rdf:type owl:ObjectProperty ;
>
>                           dc:source "
> http://www.opengeospatial.org/standards/om" ;
>
>                           rdfs:comment "The result time is the time when
> the procedure associated with the observation act was applied." ,
>
>                                        "The result time shall describe the
> time when the result became available, typically when the procedure
> associated with the observation was completed For some observations this is
> identical to the phenomenonTime. However, there are important cases where
> they differ.[O&M]" ;
>
>                           rdfs:isDefinedBy "http://www.w3.org/ns/ssn" ;
>
>                           rdfs:label "observation result time" ;
>
>                           rdfs:seeAlso "
> http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Observation#Observation" .
>
>
>
>
>
> ###  http://www.w3.org/ns/ssn/observationSamplingTime
>
> ssn:observationSamplingTime rdf:type owl:ObjectProperty ;
>
>                             dc:source "
> http://www.opengeospatial.org/standards/om" ;
>
>                             rdfs:comment "Rebadged as phenomenon time in
> [O&M]. The phenomenon time shall describe the time that the result applies
> to the property of the feature-of-interest. This is often the time of
> interaction by a sampling procedure or observation procedure with a
> real-world feature." ,
>
>                                          "The sampling time is the time
> that the result applies to the feature-of-interest. This is the time
> usually required for geospatial analysis of the result." ;
>
>                             rdfs:isDefinedBy "http://www.w3.org/ns/ssn" ;
>
>                             rdfs:label "observation sampling time" ;
>
>                             rdfs:seeAlso "
> http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Observation#Observation" .
>
>
>
> *From:* Kerry Taylor [mailto:kerry.taylor@anu.edu.au
> <kerry.taylor@anu.edu.au>]
> *Sent:* Sunday, 9 October 2016 11:56 AM
> *To:* janowicz@ucsb.edu; Simon.Cox@csiro.au; jlieberman@tumblingwalls.com
> *Cc:* 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
>
>
>
> AFAIK we **can** introduce changes to ssn. But we MUST be
> backward-compatible (see recent info on namespaces, purl and
> implementations from Phil
> https://lists.w3.org/Archives/Public/public-sdw-wg/2016Oct/0024.html).
> And we MUST have implementations. Here, we are now proposing to introduce
>  a new  incompatibility with the O&M spec, aren’t we? I am ok with that,
> but then what  are we doing  on the other hand changing  ssn:Observation
>  to be an activity/event/act   *only* because it makes it more compatible
> with the O&M spec?  The very same O&M spec we are now proposing to move
> away from here? What are we doing?
>
>
>
> Personally, I would be very  happy with this proposal as long as I can
> believe that implementations will appear in our timeframe and that the
> effect on other aspects of ssn is both clearly articulated and minimal and
> also demonstrated by multiple  implementations. This should be our bar for
> every change to ssn. Personally, I am  happy to give up on compatibility
> with the O&M spec. We might possibly  expect the O&M spec to be revised to
> be closer to what we are doing here.
>
>
>
> Kerry
>
>
>
> *From:* Krzysztof Janowicz [mailto:janowicz@ucsb.edu <janowicz@ucsb.edu>]
> *Sent:* Sunday, 9 October 2016 7:50 AM
> *To:* Simon.Cox@csiro.au; jlieberman@tumblingwalls.com
> *Cc:* Kerry Taylor <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
>
>
>
> 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
> <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> <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> 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 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
>
>
>
>
>
>
>
> --
>
> 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
>
>