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 Kerry Taylor on 2016-10-18 (public-sdw-wg@w3.org from October 2016)

From: Kerry Taylor <kerry.taylor@anu.edu.au>
Date: Tue, 18 Oct 2016 12:02:29 +0000
To: Joshua Lieberman <jlieberman@tumblingwalls.com>, Armin Haller <armin.haller@anu.edu.au>
CC: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Chris Little <chris.little@metoffice.gov.uk>, "rob@metalinkage.com.au" <rob@metalinkage.com.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Message-ID: <PS1PR06MB17403A3F02F25D1C49508CB4A4D30@PS1PR06MB1740.apcprd06.prod.outlook.com>
I think this discussion has gone well off track with   “Observations from the description about the observation ”. It is not another http-range-14 problem.  It is a question about whether we are modeling an act of observation (O&M-ish)  or  alternatively  modelling an observation as a construct that pulls together  lots of things that together constitute the concept of an observation (SSN)  . This latter  is exactly the meaning in ssn   (as defined by dolce, although that ain’t the point here either).

Yes, calling it a ‘record” is a helpful shortcut --- but  don’t be misled --- it has nothing to do with the real thing vs the description of the thing.  In both cases the real world-thing  would be equally  very, very hard to find.


Ø  An information resource consisting of an RDF graph for an observation is only useful to people when it clearly does describe something real and they can rely on that connection. .

Ø
Agreed --- but real in this context  has to be something  more abstract than a physical object  we can point to and touch –  irrespective of the way we go

-Kerry

From: Joshua Lieberman [mailto:jlieberman@tumblingwalls.com]
Sent: Tuesday, 18 October 2016 4:59 AM
To: Armin Haller <armin.haller@anu.edu.au>
Cc: Simon.Cox@csiro.au; Kerry Taylor <kerry.taylor@anu.edu.au>; Chris Little <chris.little@metoffice.gov.uk>; rob@metalinkage.com.au; janowicz@ucsb.edu; 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

I don’t think that we need to decide on one or the other, but we do need to decide how their relationship is defined and communicated. The efforts to represent explicit commitments to real world entities did not take hold because users did not feel the need for a separate step. They were easily enough able to follow an information resource to a real world entity because that relationship had already been defined by the terms used in the resource. For this to be the case with vocabularies we create, however, their terms must reference the real world entities first and then be used within information resources second. An information resource consisting of an RDF graph for an observation is only useful to people when it clearly does describe something real and they can rely on that connection.

Josh

On Oct 14, 2016, at 1:28 AM, Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>> wrote:

+1

Distinguishing the two (Observations from the description about the observation) in SSN is bound to confuse our audience. We need to decide on one or the other.

From: "Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>" <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>
Date: Friday, 14 October 2016 at 3:10 pm
To: "jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>" <jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>>
Cc: Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>, "chris.little@metoffice.gov.uk<mailto:chris.little@metoffice.gov.uk>" <chris.little@metoffice.gov.uk<mailto:chris.little@metoffice.gov.uk>>, "rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>" <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>>, "janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>" <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>>, "public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>" <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
Resent-From: <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Resent-Date: Friday, 14 October 2016 at 3:15 pm

Elsewhere on the SDWWG lists - concerning features/spatial-things - we discussed another case where the distinction between thing in the world, and the description of the thing, could be made, but experience has shown that to be a step beyond where our target community is interested in going. Elaborate URI and HTTP patterns (#/, 303) were developed around this a few years ago, but did not see strong uptake. I think we agreed that pragmatism would out? My own view is that any RDF graph is only a description, of the thing denoted by the URI in the subject position in the triples. So if we want to identify the description and not the thing in the world then we must use the URI for the graph and not the URI of the subject – Simon

From: Joshua Lieberman [mailto:jlieberman@tumblingwalls.com]
Sent: Friday, 14 October 2016 2:43 PM
To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>
Cc: kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>; Chris Little <chris.little@metoffice.gov.uk<mailto:chris.little@metoffice.gov.uk>>; rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>; janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; 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

Simon,

That’s interesting. I hadn’t really intended this role for stimulus-time when I proposed it, but at the same time I’ve been wondering how the start and end of an observation event might best be defined. It makes a lot of sense for it to start with the stimulus-time and end with the result-time. This does mean, however, that phenomenon-time and valid-time are different sorts of properties than s-time and r-time. They, along with result, constitute “outcomes” of the observation event rather than delineating it in time. All three properties could then presumably be interpreted as constituting a complex value of an observable property of the feature of interest, at least in the RDF metamodel.

It would conceivably be more elegant for p-time and v-time to be properties of result rather than observation, but I agree that at some point the tail-devouring complexity of a model needs to be constrained for usability.

From this point of view I can also see how Kerry may feel that the diversity of different properties makes it easier to recognize observation as an information record rather than a physical event. These are not necessarily incompatible viewpoints.  The ontology design approach that I think we are following involves modeling entities embedded in time and space that we can discern and discuss. The models then serve as templates for building information resources to describe those entities. So an identified observation event may also identify one or more information resources that describe it and its characteristics and that we are using to represent and communicate the “real” occurrence of the observation.

Josh

On Oct 13, 2016, at 9:10 PM, simon.cox@csiro.au<mailto:simon.cox@csiro.au> wrote:

Thanks Kerry – that’s very helpful to understand the real source of your concerns.
I think I can see where you are coming from.

I have tried to emphasize that ‘result-time’ is the clincher – this is the essential property that makes Observation an activity/act/event: before the observation there is no result, after the observation is completed there is a result. I think this is consistent with your analysis below.

If this is OK, the question is how or whether we can explain how the other time properties relate to the ‘event’.

The proposed stimulus-time seems also to be properly bound into the event-ness of an observation. The stimulus kicks off the event, and the generation of the result completes it. This proposed name is also consistent with the SSO model that was introduced to support the SSN ontology work. It’s great if we have had a convergence here.

So far so good, I hope.

The phenomenon-time is not necessarily within the event – definitely not for forecasts, and also not for observations relating to properties in the past*. This time is not a direct property of the observation event. It is a property of the phenomenon being ‘observed’ – or strictly of the relationship of the property-value with the feature-of-interest.

My thinking is that you can draw a line between every pair of classes in a diagram of an ontology or information model, and can often come up with a name for a property that each line represents. The art and science of information modelling or ontology development is to make a choice of which subset of classes and properties to include, usually to support some desired application or use-case. Some of the properties might be thought of as ‘convenience’ properties, providing a shortcut to information which might also be associated with a longer property-path, and perhaps removing the need to clutter the model with some intermediate classes that aren’t used for anything else. But provided the semantics of each property or relationship are clear, don’t overlap with other properties and do not induce inappropriate inferences, then it is OK to include them.

In this case I guess a complete model must consider the feature-of-interest, and have temporally-scoped properties for it. The phenomenon-time is strictly the time-stamp on an association of the property-value with the feature. That gets into meta-modeling and is probably beyond the scope of what we would want to include normatively here, but would certainly be good documentation. We know that in any technical analysis or actual use of observation data it is probably the most important time property, so it seems worthwhile to make it a first-class part of the model. The idea was that by giving it a clear name (“phenomenonTime”) it could be include as a local property of the observation. But I don’t see that associating it with the observation undermines the essential event-ness of the activity that generates the result.

Finally valid-time is about recommended use of the result. Again, I agree that this time does not describe the observation event per se, though it is related to the procedure used and the context. It was proposed by the simulation and forecasting people. In particular there is a 1:1 relationship between the time of validity of the result, and the observation-event that generated it, so it looked like it made sense to add it as a (optional) property of the observation. Again, since the semantics are clear and shouldn’t lead to any incorrect inferences, I don’t see that associating it with the observation undermines the essential event-ness of the activity that generates the result.

Does this help?

Simon

* e.g. estimate of a property like pressure or temperature during formation of some feature of a rock – still legitimate observation results, but definitely not contemporary with the observation.

From: Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
Sent: Friday, 14 October 2016 11:17 AM
To: Little, Chris <chris.little@metoffice.gov.uk<mailto:chris.little@metoffice.gov.uk>>; Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.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: 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

On sensors forecasting
--------------------------------

Chris, the existence of  such a box that also spews out forecasts, for me, makes an argument to permit  a “sensor” to  include forecasting capability.  Like  Krzysztof below, I am not entirely happy, but otoh it seems good enough to me.

The "observingAgent" is fine but remember that every single new term we introduce also introduces an implementation obligation on that term and also on  any  Implied effects on other pre-existing terms (at least in some cases, maybe not always). Unless we make such new terms non-normative.

Broadening the interpretation of an existing term may have no required implementation obligation (I suppose).

Narrowing the interpretation of an existing term *does* affect the user base and probably requires an implementation obligation (I expect).

So I’m into minimal  but necessary change supported by a plan for implementation.

On observation as an act or event
-------------------------------------------

And, btw, all this conversation about observations having “valid-time” , “result time” , “phenomenon time”, “stimulus time” etc sounds very horribly to me like an observation is *not* an “act” nor “event”  at all – it is exactly the idea of a “dul:situation”  as ssn traditionally defines an ssn:observation. That is (getting to the crunchy bit) an  ‘entity’ or ‘record’ of some things.     How on earth can the “act”  or “event” of observation have a “valid time” property as we understand it here,  and still  make any sense?

And I know I am harping on here ---  but this inconsistency  is already evident in the language (and it is only language) of the current O&M spec.  It does not matter there because it is only language. But it does matter here where we are forced to model that context more precisely (e.g. for provenance, even if you don’t care about dul). And then there is the even finer question about which it is – is it an “act” or “event” or “activity” ? Easy answer – none of the above.

-Kerry




From: Little, Chris [mailto:chris.little@metoffice.gov.uk]
Sent: Friday, 14 October 2016 2:09 AM
To: Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>>; janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>; 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

If we stick an old idea of a physical instrument with mercury in it, or similar, a ‘sensor’ does not look like a weather forecasting system.

However, most modern observing instruments (incorporating sensors somewhere within) are powered ‘black boxes’ spewing out numbers, such as wind speed in three dimensions every 0.1 sec. there is a lot of hardware, software, algorithms etc inside the box.

Maybe I have just made an argument for your Agent entity.

Chris

-------------------------------------------
From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Wednesday, October 12, 2016 9:53 PM
To: Little, Chris; janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; Kerry Taylor; 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

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

Rob

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

In the context of trying to align O&M and SSN, I want to protect the current interpretation, and existing implementations worldwide, of O&M supporting estimates of observables in the future.

I have no objection to other people inventing an ontology with a ‘forecast’ in it, but I am not going to.

Using forecasts to produce ‘virtual observations’ and presenting forecasts and conventional observations with identical formats and appearance are ubiquitous.

Such an ontology would probably have to include hind-casts and now-casts, as well as predictions, observations, analyses and verifying analyses. As a meteorologist, over the years, I have found that there is more benefit to be gained from treating these processes and artefacts as a continuum forwards and backwards in time, rather than categorically different things, which was the traditional, pre-computer, approach many years ago.

If you all agree that an extra ‘time type’ can address the alignment, I will be happy.

Chris

PS To specify a single forecast fully, at least 7 different date/times are usually needed. Three is parsimonious! ;-)
From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu<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  both http://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 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/<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<http://www.semantic-web-journal.net/>
Received on Tuesday, 18 October 2016 12:03:22 UTC