RE: ACTION-282: Draft a note on forecasting to address issue-82.

Not sure it is wise to draw attention to not-yet-implemented ideas, especially if we don’t explain how it is better.

A ‘standard’ is stronger if one and only one way to solve each problem is provided.

So, while I don’t disagree that it would be possible to follow the pattern to derive a Forecast class, it seems to be a distraction to include the extra paragraph here. The document is a ‘recommendation’, not a discursive paper.

Simon

From: Maxime Lefrançois [mailto:maxime.lefrancois@emse.fr]
Sent: Wednesday, 29 March, 2017 06:40
To: w3c/sdw <reply+00ae32b891c30e16cc8664d84846f52cc921a4d8f3f3f65692cf0000000114f1b8d692a16>; SDW WG Public List <public-sdw-wg@w3.org>
Cc: Author <author@noreply.github.com>
Subject: Re: ACTION-282: Draft a note on forecasting to address issue-82.

Dear all,

Based on the reviewers comments, I added a new commit to the separate branch: https://github.com/w3c/sdw/compare/action-282-forecasting . I did not issue any pull request for this branch.

The notes I propose now read like:

One may represent forecasts as observations if the value of <code>sosa:phenomenonTime</code> is later in time than the <code>sosa:resultTime</code>. Given the definition of these terms, it means that: <em>The time when the Observation act was completed is before the time that the Result of the observation applies to the FeatureOfInterest.</em> <br/>
      Note however that there are other means to represent forecasts. For example one could  derive the SSN <em>Sensing/Sensor/Observation</em> pattern and define some Forecasting/Forecaster/Forecast classes.


and a second note reads like:


Describing a plan for some actuation or observation in the future is not covered by this specification.



I would like us to base our discussions on this version in agenda iteam 1 of the call today.

Best,
Maxime