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

" Are we ontologically happy with the idea of a sensor observing a
forecast?  "

Can't we define sensor as a subclass of a more general concept
"observingAgent" (ok Agent is overloaded... i apologise in advance)?
What makes a sensor different from a forecasting thingummy? if this can be
articulated then make it a specialised subclass - maybe its just an alias
name for a given community - and preserved for backwards compatibility ?

Rob

On Thu, 13 Oct 2016 at 04:34 Little, Chris <chris.little@metoffice.gov.uk>
wrote:

> Krzysztof, Kerry, et al.,
>
>
>
> In the context of trying to align O&M and SSN, I want to protect the
> current interpretation, and existing implementations worldwide, of O&M
> supporting estimates of observables in the future.
>
>
>
> I have no objection to other people inventing an ontology with a
> ‘forecast’ in it, but I am not going to.
>
>
>
> Using forecasts to produce ‘virtual observations’ and presenting forecasts
> and conventional observations with identical formats and appearance are
> ubiquitous.
>
>
>
> Such an ontology would probably have to include hind-casts and now-casts,
> as well as predictions, observations, analyses and verifying analyses. As a
> meteorologist, over the years, I have found that there is more benefit to
> be gained from treating these processes and artefacts as a continuum
> forwards and backwards in time, rather than categorically different things,
> which was the traditional, pre-computer, approach many years ago.
>
>
>
> If you all agree that an extra ‘time type’ can address the alignment, I
> will be happy.
>
>
>
> Chris
>
>
>
> PS To specify a single forecast fully, at least 7 different date/times are
> usually needed. Three is parsimonious! ;-)
>
> *From:* Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
> *Sent:* Wednesday, October 12, 2016 5:20 PM
> *To:* Kerry Taylor; Little, Chris; Simon.Cox@csiro.au;
> jlieberman@tumblingwalls.com
> *Cc:* public-sdw-wg@w3.org
> *Subject:* Re: Forecasts and observations - was I RE: SSN Thread for
> github issue 378 - Side effects of ssn:Observation being a kind of
> dul:Event instead of dul:Situation
>
>
>
> As I now  understand it now we need 3 different times to be attached to an
> observation: stimulus time , phenomenon time (which is called sampling time
> in ssn) , and observation result time.
>
>
> As stated before, I am fine with the 3 times.
>
>
> An ssn:observation is ssn: observedby a ssn:sensor (which is very similar
>  or  identical to a sensorml sensor).  Are we ontologically happy with the
> idea of a sensor observing a forecast?  I can live with it – I am no
> perfectionist.  A ssn:sensor  ssn:implements ssn:sensing – and as sensing
> already admits algorithms – no problem here. And it is
> backwardly-compatible.
>
>
> I think this is odd and the more we broaden the meaning of all these terms
> for the sake of being as inclusive as possible, the more we will lose
> meaning. This seems to be a very common problem/issue in ontology
> engineering. I would be in favor of introducing new concepts (such as
> forecast) instead of broadening existing concepts to a degree where they
> mean almost anything (and thus nothing).
>
> Best,
> Krzysztof
>
>
>
> On 10/12/2016 06:41 AM, Kerry Taylor wrote:
>
> As I now  understand it now we need 3 different times to be attached to an
> observation: stimulus time , phenomenon time (which is called sampling time
> in ssn) , and observation result time.
>
>
>
> All of which  need to be  (optional) properties of a single observation.
>   Right? Ssn already has the latter two, but not the first.
>
>
>
> An ssn:observation is ssn: observedby a ssn:sensor (which is very similar
>  or  identical to a sensorml sensor).  Are we ontologically happy with the
> idea of a sensor observing a forecast?  I can live with it – I am no
> perfectionist.  A ssn:sensor  ssn:implements ssn:sensing – and as sensing
> already admits algorithms – no problem here. And it is
> backwardly-compatible.
>
>
>
> Sensor in ssn: “A sensor can do (implements) sensing: that is, a sensor is
> any entity that can follow a sensing method and thus observe some Property
> of a FeatureOfInterest. Sensors may be physical devices, computational
> methods, a laboratory setup with a person following a method, or any other
> thing that can follow a Sensing Method to observe a Property."
>
>
>
> How can  a user be sure whether an observation is a forecast or a
> measurement – by careful analysis of the various times attached --- is that
> ok? Does it make a difference if the  phenomenon time of the forecast is
> already prior to current time? What if some are missing?  Should  we care?
>
>
>
> I think we can do this.   We would need one more property and we would
> need to satisfy implementation requirements, to go in  the standard.
>
> Maybe Josh and Chris could volunteer independent  implementations you have
> in the works?
>
>
>
> Alternatively we could add this as “non-normative” in the rec track
> document  (but it would probably have to sit in a different file and/or
> namespace to the main ssn to do this --- we are still working through those
> options).
>
>
>
> I have created issue-82 to track this identified  need for a stimulus time
> for forecast (which I don’t think btw is in our UCR!).
>
>
>
> This I think is entirely independent of the original ‘RE: SSN Thread for
> github issue  378 - Side effects of ssn:Observation  being a kind of
> dul:Event instead of  dul:Situation” as it works irrespective of whether an
> observation is an act or a something else.
>
>
>
>
>
> --Kerry
>
>
>
> *From:* Little, Chris [mailto:chris.little@metoffice.gov.uk
> <chris.little@metoffice.gov.uk>]
> *Sent:* Wednesday, 12 October 2016 10:30 PM
> *To:* Simon.Cox@csiro.au; Kerry Taylor <kerry.taylor@anu.edu.au>
> <kerry.taylor@anu.edu.au>; janowicz@ucsb.edu; jlieberman@tumblingwalls.com
> *Cc:* maxime.lefrancois.86@gmail.com; public-sdw-wg@w3.org
> *Subject:* 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
>
>
>
> Dear all,
>
>
>
> I would just like to add my support for Simon and Rob’s posts.
>
>
>
> Over the last few years, numerous people, national and international
> organisations have implemented O&M using the conceptual model for
> forecasts/predictions as another type of observation – an estimate of a
> value in the future. In particular, it has underpinned work in both
> meteorology and aviation.
>
>
>
> These regulatory systems are likely to be in place for decades rather than
> years.
>
>
>
> The prediction processes may be very heavyweight, using supercomputers for
> a long time, may be manual (recording deviations from expected) or may be
> lightweight, as in some automated instruments, such as thermometers on
> radio-sondes, using their calibration profiles and responsiveness/time lag
> parameters to actually provide a value assigned to a fraction or a few
> seconds in the future! The radio sonde is ascending at about 5m/sec, so the
> alignment of the temperature with other observations on the balloon is
> critical.
>
>
>
> I hope we can maintain this continuum of
> observations/estimates/predictions and deliver a compatible SSN by our
> deadline.
>
>
>
> Chris
>
>
>
> *From:* Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au <Simon.Cox@csiro.au>]
>
> *Sent:* Monday, October 10, 2016 9:54 AM
> *To:* kerry.taylor@anu.edu.au; janowicz@ucsb.edu;
> jlieberman@tumblingwalls.com
> *Cc:* maxime.lefrancois.86@gmail.com; public-sdw-wg@w3.org
> *Subject:* 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
>
>
>
> Kerry –
>
>
>
> I think we are making progress here. Was not meaning to imply that anyone
> was going to take their bat and go home, was only trying to lay out the
> options. (BTW – while O&M v2.0 was officially published in 2010 by OGC and
> 2011 by ISO, most of those definitions had been stable through public
> drafts and earlier versions. Sorry if I confused things by using ‘act’ and
> ‘activity’ as approximate synonyms. I guess the former is a verb and the
> latter a noun?)
>
>
>
> As far as ‘sampling-time’ vs ‘phenomenon-time’ vs ‘stimulus-time’ goes,
> the additional insight that emerged in the last week (thanks Josh) is that
> the latter two are not necessarily the same! And that by separating them we
> can indeed reconcile the various use-cases, in particular allowing us to
> include forecasts and predictions alongside the other cases. This is
> incredibly useful, and seems rather elegant. But it does emphasize the need
> to be very careful in the terminology and definitions.
>
>
>
> I’m watching all this carefully as you can tell, since there is a
> scheduled review of ISO O&M due next year, so there is the opportunity to
> bring all these things into alignment. The statutory world, who are heavy
> users of O&M, also have an interest in terminological stability. In this
> context, I should point out that the term ‘sampling-time’ is already in the
> sampling-features part of O&M. It refers to the time when the sample is
> created, which is not necessarily the same as either the stimulus-time or
> phenomenon-time, so it would be preferable if we could leave it there, and
> not see it used with inconsistent semantics.
>
>
>
> I’m aware that this all does imply potentially renaming some properties
> and clarifying some class definitions relative to what was in the 2011
> version of SSN, and I trust this is still on the table for the SDWWG work,
> though it might push us into using a new RDF namespace.
>
>
>
> Simon
>
>
>
> *From:* Kerry Taylor [mailto:kerry.taylor@anu.edu.au
> <kerry.taylor@anu.edu.au>]
> *Sent:* Monday, 10 October 2016 1:50 PM
> *To:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; janowicz@ucsb.edu;
> jlieberman@tumblingwalls.com
> *Cc:* maxime.lefrancois.86@gmail.com; public-sdw-wg@w3.org
> *Subject:* 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
>
>
>
> Sorry – to be more specific, following this suggestion,
>
>
>
> Ø  if the stimulus-time is omitted it is assumed to be the same as
> phenomenon-time?
>
>
>
> I thought that, given ssn has  both
> http://www.w3.org/ns/ssn/observationSamplingTime (and noting its own
>  comment “Rebadged as phenomenon time in [O&M].”) and
> http://www.w3.org/ns/ssn/observationResultTime  then those two properties
> are strictly enough. Are they?
>
>
>
> I favour the minimal change approach only so that we can actually get to a
> result.
>
>
>
> Adding one more property, if that solves it,  also seems possible provided
> we can get suitable implementations. Can we? I have no resources to
> volunteer that but some others do.  Changing rdfs:comment stuff, especially
> when only broadening,  I expect (unconfirmed!) we can get away without
> needing new implementations at all. Changing the name of existing ssn terms
> to something else we certainly cannot do without implementations and close
> attention. How will that implementation be achieved?
>
>
>
>
>
> Ø  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’.
>
>
>
>  As you know, ssn already covers observations at least reasonably well.
>  Arguably not perfectly.  If it is not good enough then “then those of us
> interested in the more general case” have every right to work with SDW to
> make it better. Why not?  The only reason for  why not could be actually
> failing to deliver. And  we have a plan to deliver a non-rec track
> alignment to O&M anyway (see FPWD) --- there is no reason I can think of
> (other than resources/effort) to deliver that and without the same
> implementation  and oversight requirements.
>
>
>
> Alternatively, we can follow Rob’s suggestion  of taking  some of the
> perfect out of the standardisation discussion and parking it as a note. No
> implementations required. Suits  me well enough. I admit, I would certainly
> prefer to deliver the “scope/usefulness/completeness/consistency of its
> content” in the rec track but that seems to be vanishingly unlikely at
> this stage.
>
>
>
> I had hoped the O&M alignment (and btw the DUL alignment too, and
> critically importantly perhaps the SOSA-core alignment is forced to go
> there too) )would go in rec track doc  as non-normative --  some people
> would have missed that discussion at the F2F. I will remind Phil to check
> our options here.  Alternatively this could be (should be?) the same Note
> that Rob is suggesting.
>
>
>
> And another apology – I really wanted to talk through these options and
> test our implementation capability at the last ssn meeting, but it got
> sidelined. With one objection (not sure it was a -1 though) , I heard that
> the group confirmed that we intend to publish a standard.  Right now we
> have very, very little progress to show towards the really necessary
> components for  that goal.
>
>
>
> -Kerry
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au <Simon.Cox@csiro.au>]
>
> *Sent:* Monday, 10 October 2016 9:54 AM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>; janowicz@ucsb.edu;
> jlieberman@tumblingwalls.com
> *Cc:* maxime.lefrancois.86@gmail.com; public-sdw-wg@w3.org
> *Subject:* 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
>
>
>
> Ø  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
> <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
>
>
>
>
>
> --
>
> 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
>
>