- From: Kerry Taylor <kerry.taylor@anu.edu.au>
- Date: Mon, 10 Oct 2016 03:51:27 +0000
- To: Rob Atkinson <rob@metalinkage.com.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, "jlieberman@tumblingwalls.com" <jlieberman@tumblingwalls.com>
- CC: "maxime.lefrancois.86@gmail.com" <maxime.lefrancois.86@gmail.com>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Message-ID: <PS1PR06MB1740D409C4DD8CF31E14E79FA4DB0@PS1PR06MB1740.apcprd06.prod.outlook.com>
Your solution is a good one afaiac, --- but noting that ssn *does* address observation already and there are *plenty* of implementations out there in the wild. In my mind the real question is how much we can and should *modify ssn towards perfection* in the SDW *and* still deliver it within the standard.
We *can* push through changes in the standard but we *must* satisfy obligations to do so. Maybe my judgement is over-conservative because I feel a greater pressure to deliver than maybe some others do. Or maybe there are some rabbits in hats that I am just unaware of!
Following your lead, would it help to split the discussion into clear expectations about what is in the standard and what is in a note?
Kerry
From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Monday, 10 October 2016 11:09 AM
To: Simon.Cox@csiro.au; Kerry Taylor <kerry.taylor@anu.edu.au>; janowicz@ucsb.edu; jlieberman@tumblingwalls.com
Cc: maxime.lefrancois.86@gmail.com; public-sdw-wg@w3.org
Subject: Re: Forecasts and observations - was RE: SSN Thread for github issue 378 - Side effects of ssn:Observation being a kind of dul:Event instead of dul:Situation
Struggling to reconcile the underlying goal with the details here...and throw myself into the fray as someone who really doesnt have a vested interest in any specific outcome, but a strong desire for a good one that can be a game changer :-)
my perspective -
1) a concept of sensors without observations - i.e. describing sensor characteristics, not outputs, would be quite useful
2) a generalised approach to observations including a canonical approach to describing the relationship of sensors to observations is much harder to achieve but much more useful
3) a model for sensors with an incomplete model of observations that need to be reconciled with other idosyncratic models of observations would be painful in a context where sensors are but one part of a system.
4) evidence of implementation to demonstrate need and effectiveness is one perspective - evidence of need based on incompatible implementation of ad-hoc alternatives is another viable view
The question is perhaps whether the status of the document is more important than the scope/usefulness/completeness/consistency of its content? That perhaps is a value judgement? If it were possible to extract the subset of SSN (with implementation record) that does not address observation acts, but publish alongside a more general applicable, but less mature, guidance note on observations, and show how it may be used in that context, that would feel like quite a good achievement.
From a "implement a system tomorrow" perspective, I'd choose a complete treatment as a Note, over yet another fragmentary solution I have to try to work out how to fit it together in a consistent way. I feel there is enough interested brain power at the table to make a good stab at that,
Rob Atkinson
On Mon, 10 Oct 2016 at 09:53 <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>> wrote:
> And btw this cannot be done if an ssn:observation becomes an “act”.
I don’t understand this comment.
The ‘act-ness’ of observation is emerges from the ‘result-time’ property – this was why result-time was included in O&M, and why it is distinct from phenomenon-time (the time the value applies in the world).
Josh’s proposal (i.e. to also add a “stimulus-time” property) appears to reconcile all the requirements. A prediction or forecast is merely an observation whose stimulus time is usually prior to but may be contemporary with the result-time, and is prior to the phenomenon-time. The temporal logic is key, but requires multiple time properties.
> the only challenge I foresee is whether we can feel comfortable with the idea that a sensor ontology also sneaks forecasting in, and that “Sensing” includes forecasting and that a “sensor” implements forecasting.
Maybe the issue is around whether we consider this a ‘sensor’ ontology (indeed, that is in the SSN name) or an ‘observation’ ontology. If it is narrowly the former, then those of us interested in the more general case may have to go elsewhere. But I thought the group (and the UCR) was comfortable with dealing with ‘observations’.
Simon
From: Kerry Taylor [mailto:kerry.taylor@anu.edu.au<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 Phil https://lists.w3.org/Archives/Public/public-sdw-wg/2016Oct/0024.html). And we MUST have implementations. Here, we are now proposing to introduce a new incompatibility with the O&M spec, aren’t we? I am ok with that, but then what are we doing on the other hand changing ssn:Observation to be an activity/event/act only because it makes it more compatible with the O&M spec? The very same O&M spec we are now proposing to move away from here? What are we doing?
Personally, I would be very happy with this proposal as long as I can believe that implementations will appear in our timeframe and that the effect on other aspects of ssn is both clearly articulated and minimal and also demonstrated by multiple implementations. This should be our bar for every change to ssn. Personally, I am happy to give up on compatibility with the O&M spec. We might possibly expect the O&M spec to be revised to be closer to what we are doing here.
Kerry
From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
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 rangedul:Event
the only such DUL properties are: dul:isPreconditionOf, and dul:isPostconditionOf.
Neither of them seem to fit,
so, should this axiom be simply deleted from the SSN-DUL alignment ?
Kind regards
Maxime Lefrançois
--
Krzysztof Janowicz
Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060
Email: jano@geog.ucsb.edu<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/
Semantic Web Journal: http://www.semantic-web-journal.net
Received on Monday, 10 October 2016 03:52:05 UTC