W3C home > Mailing lists > Public > public-sdw-wg@w3.org > October 2016

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

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Thu, 13 Oct 2016 09:09:27 -0700
To: Joshua Lieberman <jlieberman@tumblingwalls.com>, Chris Little <chris.little@metoffice.gov.uk>
Cc: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "kerry.taylor@anu.edu.au" <kerry.taylor@anu.edu.au>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Message-ID: <742e0c10-0ccf-5f46-21a9-6d2c0270cfdb@ucsb.edu>
This is my understanding of valid-time as well and personally I find it 
very useful.

On 10/13/2016 08:46 AM, Joshua Lieberman wrote:
> I’ve never been exactly sure what Valid-time meant. I thought it 
> referred to an interpretation of the time period over which an 
> observation might still legitimately estimate a present or future 
> observable property. For example, a water temperature measurement may 
> continue to reasonably estimate that property of a river for a few 
> hours, or a weather forecast may be valid until trends in its input 
> parameters invalidate it. I’ve never equated it directly with either 
> PhenomenonTime or a new StimulusTime.
>
> Josh
>
>> On Oct 13, 2016, at 11:12 AM, Little, Chris 
>> <chris.little@metoffice.gov.uk 
>> <mailto:chris.little@metoffice.gov.uk>> wrote:
>>
>> Simon,
>> Not sure of all the implications of what we are discussing, but:
>> Valid-time = Phenomenon-time
>> could distinguish a conventional sensing observation from a predicted ob?
>> Chris
>> *From:*Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au> 
>> [mailto:Simon.Cox@csiro.au]
>> *Sent:*Thursday, October 13, 2016 12:27 AM
>> *To:*Little, Chris; janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; 
>> kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>; 
>> jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>
>> *Cc:*public-sdw-wg@w3.org <mailto: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
>>
>> ØPS To specify a single forecast fully, at least 7 different 
>> date/times are usually needed. Three is parsimonious! ;-)
>>
>> Yeah – we had discussions in the O&M Editing Committee about this in 
>> the 2008-2010 timeframe. Given that some of these times related only 
>> to the relatively specialized ensemble simulation scenarios carried 
>> out in the forecasting applications, we cut this down to a subset of 
>> three times in O&M, being ones that clearly applied in multiple 
>> domains and practices, these being:
>> -Phenomenon-time
>> -Result-time
>> -Valid-time
>> As discussed in the last couple of weeks, the proposal is to add
>> -Stimulus-time
>> My hunch is that*only phenomenon-time is mandatory*(it’s the one that 
>> is most significant in the world and should apply in all cases). 
>> There are plausible defaults for the other ones
>> -Result-time = phenomenon-time if not explicitly provided
>> -Stimulus-time = phenomenon-time if not explicitly provided
>> -Valid-time = unbounded if not explicitly provided
>> I’m probably comfortable dropping valid-time from our work here, 
>> since arguably it operates at a different level from the others which 
>> are all related to things in the world and activities interacting 
>> with it. Chris and Jeremy might have a different opinion.
>> Simon
>> *From:*Little, Chris [mailto:chris.little@metoffice.gov.uk]
>> *Sent:*Thursday, 13 October 2016 4:34 AM
>> *To:*janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; Kerry Taylor 
>> <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>; Cox, 
>> Simon (L&W, Clayton) <Simon.Cox@csiro.au 
>> <mailto:Simon.Cox@csiro.au>>;jlieberman@tumblingwalls.com 
>> <mailto:jlieberman@tumblingwalls.com>
>> *Cc:*public-sdw-wg@w3.org <mailto: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
>> 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 
>> <mailto:Simon.Cox@csiro.au>;jlieberman@tumblingwalls.com 
>> <mailto:jlieberman@tumblingwalls.com>
>> *Cc:*public-sdw-wg@w3.org <mailto: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]
>>     *Sent:*Wednesday, 12 October 2016 10:30 PM
>>     *To:*Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>; Kerry
>>     Taylor<kerry.taylor@anu.edu.au>
>>     <mailto:kerry.taylor@anu.edu.au>;janowicz@ucsb.edu
>>     <mailto:janowicz@ucsb.edu>;jlieberman@tumblingwalls.com
>>     <mailto:jlieberman@tumblingwalls.com>
>>     *Cc:*maxime.lefrancois.86@gmail.com
>>     <mailto:maxime.lefrancois.86@gmail.com>;public-sdw-wg@w3.org
>>     <mailto: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>[mailto:Simon.Cox@csiro.au]
>>     *Sent:*Monday, October 10, 2016 9:54 AM
>>     *To:*kerry.taylor@anu.edu.au
>>     <mailto:kerry.taylor@anu.edu.au>;janowicz@ucsb.edu
>>     <mailto:janowicz@ucsb.edu>;jlieberman@tumblingwalls.com
>>     <mailto:jlieberman@tumblingwalls.com>
>>     *Cc:*maxime.lefrancois.86@gmail.com
>>     <mailto:maxime.lefrancois.86@gmail.com>;public-sdw-wg@w3.org
>>     <mailto: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]
>>     *Sent:*Monday, 10 October 2016 1:50 PM
>>     *To:*Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au
>>     <mailto:Simon.Cox@csiro.au>>;janowicz@ucsb.edu
>>     <mailto:janowicz@ucsb.edu>;jlieberman@tumblingwalls.com
>>     <mailto:jlieberman@tumblingwalls.com>
>>     *Cc:*maxime.lefrancois.86@gmail.com
>>     <mailto:maxime.lefrancois.86@gmail.com>;public-sdw-wg@w3.org
>>     <mailto: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
>>      bothhttp://www.w3.org/ns/ssn/observationSamplingTime(and noting
>>     its own  comment “Rebadged as phenomenon time in [O&M].”)
>>     andhttp://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>[mailto:Simon.Cox@csiro.au]
>>     *Sent:*Monday, 10 October 2016 9:54 AM
>>     *To:*Kerry Taylor <kerry.taylor@anu.edu.au
>>     <mailto:kerry.taylor@anu.edu.au>>;janowicz@ucsb.edu
>>     <mailto:janowicz@ucsb.edu>;jlieberman@tumblingwalls.com
>>     <mailto:jlieberman@tumblingwalls.com>
>>     *Cc:*maxime.lefrancois.86@gmail.com
>>     <mailto:maxime.lefrancois.86@gmail.com>;public-sdw-wg@w3.org
>>     <mailto: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]
>>     *Sent:*Sunday, 9 October 2016 12:35 PM
>>     *To:*Kerry Taylor <kerry.taylor@anu.edu.au
>>     <mailto:kerry.taylor@anu.edu.au>>;janowicz@ucsb.edu
>>     <mailto:janowicz@ucsb.edu>; Cox, Simon (L&W, Clayton)
>>     <Simon.Cox@csiro.au
>>     <mailto:Simon.Cox@csiro.au>>;jlieberman@tumblingwalls.com
>>     <mailto:jlieberman@tumblingwalls.com>
>>     *Cc:*maxime.lefrancois.86@gmail.com
>>     <mailto:maxime.lefrancois.86@gmail.com>;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
>>     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]
>>     *Sent:*Sunday, 9 October 2016 11:56 AM
>>     *To:*janowicz@ucsb.edu
>>     <mailto:janowicz@ucsb.edu>;Simon.Cox@csiro.au
>>     <mailto:Simon.Cox@csiro.au>;jlieberman@tumblingwalls.com
>>     <mailto:jlieberman@tumblingwalls.com>
>>     *Cc:*maxime.lefrancois.86@gmail.com
>>     <mailto:maxime.lefrancois.86@gmail.com>;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
>>     AFAIK we **can** introduce changes to ssn. But we MUST be
>>     backward-compatible (see recent info on namespaces, purl and
>>     implementations from
>>     Philhttps://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]
>>     *Sent:*Sunday, 9 October 2016 7:50 AM
>>     *To:*Simon.Cox@csiro.au
>>     <mailto:Simon.Cox@csiro.au>;jlieberman@tumblingwalls.com
>>     <mailto:jlieberman@tumblingwalls.com>
>>     *Cc:*Kerry Taylor <kerry.taylor@anu.edu.au
>>     <mailto:kerry.taylor@anu.edu.au>>;maxime.lefrancois.86@gmail.com
>>     <mailto:maxime.lefrancois.86@gmail.com>;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
>>
>>         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
>>     <mailto: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 <mailto:janowicz@ucsb.edu>
>>         *Cc:*Cox, Simon (L&W, Clayton)<Simon.Cox@csiro.au>
>>         <mailto:Simon.Cox@csiro.au>;kerry.taylor@anu.edu.au
>>         <mailto:kerry.taylor@anu.edu.au>;maxime.lefrancois.86@gmail.com
>>         <mailto:maxime.lefrancois.86@gmail.com>;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
>>         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 <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 <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 Thursday, 13 October 2016 16:10:08 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:26 UTC