RE: Naming the properties between FeatureOfInterest, xxxProperty, {Actuator/Sensor}, {Actuation/Observation} [SEC=UNCLASSIFIED]

Thanks Bruce -
Ø  We assume that the result of the observation, that is 'the estimate of the value' may well change during the observation lifecycle as it progresses through a range of QC/QA processes. Therefore there may be multiple states for contextual information that relates to 'the result' at a point in time (i.e. the yellow symbols)
Using the O&M view, these changes would be considered the results of subsequent observations –

-          A new (augmented) procedure (workflow)

-          A later result-time

-          the phenomenon-time remains the same (the time the estimate applies to the world)

-          there may be new stimulus-time (a new proposed property that came up in discussions a few months ago) which could record details of new inputs that lead to the changed estimate

This highlights the importance of the different time properties associated with Observations in O&M/SSN.

Simon
________________________________
From: Bruce Bannerman
Sent: Wednesday, 8 March 2017 3:10:49 PM
To: Armin Haller; Maxime Lefrançois; SDW WG Public List
Subject: Re: Naming the properties between FeatureOfInterest, xxxProperty, {Actuator/Sensor}, {Actuation/Observation} [SEC=UNCLASSIFIED]


​Thanks for including the diagram!



While I admit that most of the nuances of this 'discussion' have escaped me, the diagram certainly helps understand what you are trying to do.



As a cross check, you may be interested in some work that Denis Stuber from MetoFrance and I have been doing within the World Meteorological Organisation as part of our Climate Data Management Systems work.



We are trying to explain what we understand an observation to be, and have developed the conceptual diagram at [1]. This is a work in progress.



Points to note:

  *   ​We assume that the result of the observation, that is 'the estimate of the value' may well change during the observation lifecycle as it progresses through a range of QC/QA processes. Therefore there may be multiple states for contextual information that relates to 'the result' at a point in time (i.e. the yellow symbols)

  *   We don't assume that a sensor will be the source of the observation, and use 'Observation Process' in its place.

  *   ​The symbols and text from 11 o'clock to ~2 O'clock in the diagram may need to be revisited, as they are perhaps not quite right.

  *   ​The term WIGOS Observations Metadata refers to a wide range of contextual information that relates to how the observation was made, e.g. what observations process was used (manual, sensor etc), sensor calibration and maintenance details, algorithms used, etc.



This may, or may not help you. However it reflects many years of experience working with and managing observations and related data.



You'll see the influence of ISO 19156.



Bruce



[1] https://wiswiki.wmo.int/tiki-download_file.php?fileId=3214<https://wiswiki.wmo.int/tiki-download_file.php?fileId=3214&display>





________________________________
From: Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>>
Sent: Wednesday, 8 March 2017 2:22 PM
To: Maxime Lefrançois; SDW WG Public List
Subject: Re: Naming the properties between FeatureOfInterest, xxxProperty, {Actuator/Sensor}, {Actuation/Observation}

Hi Maxime,

Thanks for providing these illustrations!

I did fall in a trap today in the phone call in voting again on names at the end of the telco that we have already decided upon, i.e. see https://www.w3.org/2015/spatial/track/issues/108 and the illustration below by Kerry (with the implemented solution added in red). I.e. we do have the following relations:

madeObservation(Sensor, Observation)
madeBySensor(Observation, Sensor)
observes(Sensor, ObservableProperty)
isObservedBy(ObservableProperty, Sensor)

There are some naming inconsistencies if you want to follow a specific pattern, but considering the constraints we are living with, i.e. existing SSN relation names and names in the OGC (O&M and SensorML), the below graph shows the minimal changes that are required in SSN and that are already implemented: https://github.com/w3c/sdw/pull/591


Unless there are strong reasons for revisiting these decisions, I would propose to move to the next issue. In particular, as you point out in your proposed solution that has consistent naming, that observes/isObservedBy would have a different “domain” and “range” than in SSN, which is, in my opinion a too high price to pay for a consistent property naming convention.

[cid:image001.png@01D298B5.CF8A8530]


From: Maxime Lefrançois <maxime.lefrancois@emse.fr<mailto:maxime.lefrancois@emse.fr>>
Date: Wednesday, 8 March 2017 at 11:18 am
To: SDW WG Public List <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Subject: Naming the properties between FeatureOfInterest, xxxProperty, {Actuator/Sensor}, {Actuation/Observation}
Resent-From: <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Resent-Date: Wednesday, 8 March 2017 at 11:19 am

Dear all,

As a follow up to today's call, I created a simple figure that shows the old and current links between classes: FeatureOfInterest, xxxProperty, {Actuator/Sensor}, {Actuation/Observation}, as of 2017-03-08,

https://www.w3.org/2015/spatial/wiki/File:20170308-foi-property-object-event.png


I also produced another figure that illustrates an option where:
 1. naming is consistent between the ACT part and the SENSE part
 2. one can guess the name of the link between {Actuator, Actuation, Sensor, Observation} to xxxProperty by simply adding the string "Property" somewhere in the name of the link between  {Actuator, Actuation, Sensor, Observation} to FeatureOfInterest
 3. we rely on present or past to differentiate what is "potential" (i.e., links Actuator or Sensor), versus what is "done" (i.e., links {Actuation, Actuator}).

https://www.w3.org/2015/spatial/wiki/File:20170308-foi-property-object-event-maxime-would-be-happy-with.png


As you will understand, I am not 100% happy with this option neither:
  - it uses "observes" as the name of the link between Sensor and FeatureOfInterest, while in the old SSN the link "observes" was between a Sensor and a Property
  - it would imply that we reconsider the vote at https://www.w3.org/2015/spatial/wiki/Link_between_Actuation_and_Actuator



If anyone has a different proposal for the names, you can create a new option with the same "great style" using the pptx at the following URL:
 https://www.w3.org/2015/spatial/wiki/images/4/40/Foi-property-object-event.pptx



Also, now that we have a figure to evaluate all the links between classes FeatureOfInterest, xxxProperty, {Actuator/Sensor}, {Actuation/Observation}, it's clear to track the current progress of sosa/ssn, and identify the possible naming inconsistencies.

On the other hand, I absolutely don't have a clue on the best way to proceed to choose as a group each one of the names for the links as quickly as possible. If anyone has an idea about this, I'd be pleased to hear it.

Kind regards,
Maxime