- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Sat, 8 Oct 2016 13:53:35 -0700
- To: Kerry Taylor <kerry.taylor@anu.edu.au>
- Cc: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Message-ID: <e7556016-8f0f-8011-488c-cdb81c4450e9@ucsb.edu>
Hi Kerry, Thanks for putting this together. I am not 100% sure where you are going with this. An act of measuring is an activity, right? Are you referring to the fact that we need to be more precise with the language we use? If so, I agree. Best, Krzysztof On 10/08/2016 09:22 AM, Kerry Taylor wrote: > > A FRESH IDEA TO SOLVE THIS > > Are we just being a little too precious here? > > Referring to the 2013 spec for O&M 10-004r3 copied in here – is this > the right one please? Note that it post-dates ssn. > > *4.11* > > *observation* > > act of measuring or otherwise determining the *value *of a *property* > > *4.12* > > *observation procedure* > > method, algorithm or instrument, or system of these, which may be used > in making an *observation* > > *4.13* > > *observation protocol* > > combination of a sampling strategy and an *observation procedure *used > in making an *observation* > > *4.14* > > *observation result* > > estimate of the *value *of a *property *determined through a known > observation procedure > > . > > . > > *4.17 sampling feature* > > *feature *which is involved in making *observations *concerning a > *domain feature* > > This is already self-inconsistent. It does say observation is an “act” > (but not an ‘activity’, nor an “event’). > > Further, a procedure is used in making an observation, that is, in > /making the act of measuring/. Really? > > And an observation protocol is also used in /making an act of > measuring. /Really? > > A sampling feature is involved in /making acts of measuring/? > > ** > > // > > Later, > > An observation is an act associated with a discrete time instant or > period through which a number, term or > > other symbol is assigned to a phenomenon [2]. It involves application > of a specified procedure, such as a > > sensor, instrument, algorithm or process chain. The procedure may be > applied /in-situ/, remotely, or /ex-situ /with > > respect to the sampling location. The result of an observation is an > estimate of the value of a property of some > > feature. > > Take away the word “act” and the same can be said of ssn:observation. > > It is uncoincidentally very similar to the definition of an > ssn:observation: > > An Observation is a Situation in which a Sensing method has been used > to estimate or calculate a value of a Property of a > FeatureOfInterest. Links to Sensing and Sensor describe what made the > Observation and how; links to Property and Feature detail what was > sensed; the result is the output of a Sensor; other metadata details > times etc. > > Back to the O&M spec: > > -This is a consequence of the fact that an observation is a kind of > ‘event’ so… > > -Aside from the result, the details of the observation event are…. > > -Observations focus on the data collection event. An act of > Observation serves to.. > > -An observation event is clearly… > > This kind of confusion is what you see without an upper ontology, and > it really doesn’t matter at all until you need an upper ontology. It > does O&M no harm. > > But ssn uses an upper ontology and **is** careful. > > *KEY POINT* > > I can see no formal/interoperability/implementation/codebase > difference whatsoever to the O&M spec if an Observation were not an > “act” but instead were some kind of object or information entity as > ssn sees an Observation. There is no reason at all why an O&M > observation has to be a prov:Activity which is, already different to > an “act” as in the spec. The already inconsistent English text in the > spec could be improved, though. > > ** > > *THEREFORE* > > We should indeed align ssn:observation with an o&m observation > concept, but do this by defining o&m:observation to be a record of > an event. This requires us to do nothing at all, there is no issue > with prov, no issue with the long-standing dul alignment, no > consequence for the SSN user base, no consequence for the O&M user > base. In our o&m alignment we can explain this choice. TOO EASY. > > ** > > *WHY NOT?* > > ** > > The only argument I am aware of against this solution is Jeremy’s > typing on the F2F IRC : > > I think ... For me, it seems natural to treat Observation as an > Activity ... it's something that's done at a particular time using a > specified process. It produces a some data (the result) ... the data, > an information resource, is an Entity. SSN seems unnecessarily complex > in splitting the problem into SensorOutput, Observation and > ActivityOfSensing; OM does this in two classes: Result and Observation.** > > ** > > Well, if it is “natural” then why is the spec so confused about > it?*“*unnecessarily complex”: is a furphy(!) – there is no > ActivityofSensing in ssn. Having said that, I expect Jeremy is not > alone in expecting an observation to be something like an activity. > > -Kerry > > // > > *From:*Kerry Taylor [mailto:kerry.taylor@anu.edu.au] > *Sent:* Saturday, 8 October 2016 11:22 PM > *To:* Simon.Cox@csiro.au > *Cc:* 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 > > So I missed some of these remarks in my reply a moment ago --- but I > still hear that we have no choice other than “isPostconditionOf” to > replace includesEvent. Remember that this is only in the dul > alignment, not in ssn proper, and is therefore non-normative. > > As a quite separate issue, I think I hear a call for expanding the > definition of ssn:Sensor” to include prediction ? Assuming we are > happy with the relationship to ssn:Stimulus, I can’t see any problem > with this as it would only affect annotation properties and is a > widening, rather than narrowing, of the concept. > > But I will not propose it --- I don’t have a need for it. > > -Kerry > > *From:*Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au> > [mailto:Simon.Cox@csiro.au] > *Sent:* Friday, 7 October 2016 5:50 PM > *To:* jlieberman@tumblingwalls.com > <mailto:jlieberman@tumblingwalls.com>; janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu> > *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? > > *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 Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Saturday, 8 October 2016 20:54:09 UTC