- 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