[astro] Add semantic tags

[andrewfg]

This PR adds semantic tags.

Signed-off-by: Andrew Fiddian-Green software@whitebear.ch

[andrewfg]

@jimtng just pinging you on this because we may need more properties ;)

[jimtng]

TBH I am really not sure what semantic to assign to each of them, or whether we need to assign any tags here at all. So many things are swirling in mind, I apologise that I don't have a clear idea:

• We might as well add all the dimensions from https://www.openhab.org/docs/concepts/units-of-measurement.html - some of them are already part of semantic Properties (Energy, Power, Voltage (Electric Potential), etc).
• Illuminance is for lux, and without researching into this, I think it's for visible light and doesn't seem applicable to irradiance.
• Is it of any use to assign Timestamp to a whole bunch of those channels? Doing so seems to lose the usefulness of semantic.
• What's the difference between Measurement vs Status in this add-on. It seems that all the channels could be called "Status" too.

[lsiepel]

• What's the difference between Measurement vs Status in this add-on. It seems that all the channels could be called "Status" too.

I'm not sure if Status should be used for future (or historic) states. For other current channels it is fine i guess.

[jimtng]

This one is a bit "different" because these values are not "forecast/prediction". In a forecast, you don't know for sure that it will be so.

In the case of astro, I think they will be so in the future. It's not a matter of prediction, but a calculation (not "measurement"). Although we are not "there yet" in time, but we will eventually experience it. Nothing will change between now and then, the data will remain the same.

[andrewfg]

@jimtng apropos your questions: that is the reason why I chose this binding -- as a kind of sanity check for semantics overall..

[jimtng]

Do we need all the channels to have semantic tags?

I guess the question is:

Why do we need semantic tags, what are they for, and how would adding tags facilitate/fulfil that purpose?

[jimtng]

About the latest commit - none of should be tagged as Forecast. This isn't a prediction and it's not the same as weather forecast.

Furthermore, not all the channels will return future date. Some will return past date, depending on where you are in the cycle, so calling it forecast is wrong for this reason too.

The elevation / azimuth etc are all current data, so tagging them as forecast is wrong too.

[andrewfg]

none of should be tagged as Forecast.
This isn't a prediction and it's not the same as weather forecast.

It is a hard call. I suppose that all astro events in the past are measurements (observations), and all in the future are forecasts. A forecast is a prediction based on a calculation based on a model. The fact that our models and calculations are so good that the result is 99.999999% correct does not mean that the forecast is actually an observation.

.. it is quite a moot point for Islamic scholars where e.g. the start day of Ramadan is not fixed in advance based on a calculation; but rather the Islamic world must wait until the actual lunar observation will have been done ..

[jimtng]

A forecast is a prediction based on a calculation based on a model.

I'm not sure if Status should be used for future (or historic) states. For other current channels it is fine i guess.

I think the difference is that a forecast can change because its calculation is based on non-static factors (e.g. measurement of atmospheric pressures, wind direction, etc).

Whereas this binding will give you the exact same predictable result for the same lat/long and time. Hence why I don't think that this qualifies as "forecast" even though it does tell you when certain events will occur (or had occurred) in the future / past.

To me they're all status because when you want to know when sunset will be, you get the data you requested right there and then. It is not a prediction, based on possibly changing conditions.

Astro isn't going to suddenly return a different sunset time an hour later because "something is changing". This is unlike a forecast (e.g. weather) that may/can change.

it is quite a moot point for Islamic scholars where e.g. the start day of Ramadan is not fixed in advance based on a calculation; but rather the Islamic world must wait until the actual lunar observation will have been done ..

But we are not dealing with Ramadhan (AFAIK?) in this binding so this example doesn't apply. Astro's results are fixed in advance.

An example I can think of: Given an equation y = x, you know that when x = 5, y will be 5, and when x = 10, y will be 10. y will never be anything other than 10 given x = 10.
I don't think you can this a forecast even if x is the timeline.

[rkoshak]

A quick summary of my thoughts.

• Not all Channels need a tag. If it just can't make sense, don't include a tag. Asto in particular probably has few Channels that one would normally want to have exposed to the end users on the Overview tag. Those using semantic tags in other ways can apply the tags needed for their particular use case.

• Not all tagged Channels require both a Point and a Property. If there isn't a Property that makes sense, leave it out. However, I somewhat agree that Measurement doesn't make a lot of sense without there being something being measured.

• I don't think "Measurement" makes sense for any of the Channels. These are all calculated, not measured. But I can also see how things like Azimuth and Elevation are like other measurements.

• I have less of a problem using "Forecast" except for the fact that, for example, after Dawn that Channel will be in the past, not the future so it's not really a forecast anymore. However, if we used "Prediction", I don't think there would be any problem. Astro predicts the times of the events using a very accurate calculation. But the accuracy doesn't change the fact that it's a prediction. And once the time is past, it remains a prediction. Didn't we add "Prediction" or something like that already? I remember there being a discussion about that.

• If not "Timestamp" then what?

[andrewfg]

Didn't we add "Prediction" or something like that already?

We did :) .. But the consensus was that Forecast was a better word. So we adopted that. And now when I apply Forecast (in the sense of Prediction) you complain that it is too loose. And now when I apply Measurement (to be more precise) you complain that it is too precise.

At the very least let us add the word Prediction as a synonym of Forecast...

[andrewfg]

@rkoshak / @jlaur / @jimtng / @lsiepel -- how shall we proceed with this? It affects all bindings that are either a) astronomical in nature, or b) that have channels which are not exactly measurements in the normal sense. The decision that we make here would be a precedent to eventually apply to all such addons. There are two specific issues to resolve..

• Is an astronomical calculation a "measurement" or is it something else. Some would say astronomical calculations are universal truths; others would say that they are state of the art calculations based on the current known state of physics. However they certainly have rounding errors, and who knows, when the alien ships arrive, they may be wrong. So one proposal is to call them a Prediction rather than a Measurement. Another idea might be Calculation.

• The usage (and tagging) should reflect both the past and future tense. The tag Forecast might apply to an astro calculation that has not yet occurred. But would not apply to one from the past. Indeed the transition from future to past changes the nature of the data from "state of the art calculation" to "proven fact" (the alien ships evidently did not arrive).

So we have the following options:

1. Call them Measurement (which does not fit the future tense)
2. Call them Status (which does not fit the future tense)
3. Call them Forecast (which does not fit the past tense)
4. Call them Prediction (which has past/future tense ambiguity) -- requires definition a new Point tag
5. Call them Calculation -- requires definition a new Point tag
6. Don't tag such channels at all

=> So please cast your votes for 1. thru 6. above (personally I vote for 5.)..

[jimtng]

• If we must give them a tag, then Calculation seems the most apt name.
• I think it's a bit odd for astro's equipment tag to be WebService. To me, a Web Service is when the binding facilitates a communication channel with a web end point. I don't think that applies to astro. However, I am having a hard time finding an alternative Equipment tag out of the existing one for it. In fact, it is not even an "Equipment" of any sort, which is perhaps why we're having such trouble with this.

[lsiepel]

• o me, a Web Service is when the binding facilitates a communication channel with a web end point. I don't think that applies to astro. However, I am having a hard time finding an alternative Equipment tag out of the existing one for it. In fact, it is not even an "Equipment" of any sort, which is perhaps why we're having such trouble with this.

My thoughts exactly

[andrewfg]

not even an "Equipment" of any sort

Maybe Application ??

[rkoshak]

"Calculation" works for me.

But I also think that not tagging particularly thorny Channels should be an option.

"Application" is the best alternative equipment name I can think of.

[andrewfg]

I just opened a PR to add those tags to Core..

openhab/openhab-core#4745

[andrewfg]

@lsiepel / @rkoshak / @jimtng the core PR has been merged, so in principle this PR is now ready to go; however I noticed that this astro binding also got separately reviewed in #18585 and #18664 .. so I will take over any changes and comments from those PRs into this PR in order to avoid confusion and duplication.

[lsiepel]

Thanks, LGTM.
@jlaur you seem to have spend much more time on this topic. I'm trying to catch up, any comments?

[jlaur]

you seem to have spend much more time on this topic. I'm trying to catch up, any comments?

Not really, I'm also catching up, but at a slow pace. I don't quite understand the use-case behind the Status / Info combination which seems quite generic, but I think it was established for music metadata or something. Calculation seems quite harmless. Your review is for sure as good as mine. 😄

[lsiepel]

LGTM