Re: [sdw] modeling units on properties instead of results [SOSA/SSN] (#1267)

I get the feeling that at least part of this dilemma is us protecting our users from themselves. To my view, the classic case is avoiding the conflagration of PbConcentration in PPM as in the examples above with other measurement expressed in µg/m³.
At the same time, most users looking for PbConcentration in PPM will also be happy with measurements expressed in µg/m³, will do the necessary transformation - if the UoM gets mixed into the ObsProp one would need to search for all possible combinations.

I think it also depends on if your Observations only pertain to one single result as common in SOSA (though could also envision a time-value array as a result here - has anybody tried this?), or could also pertain to a timeseries as common in O&M. In most systems I've encountered, when time series are provided, the values tend to have a consistent UoM; to my view this indicates that the UoM can be stored with the Observation, does not need to be repeated for each result value.

My current impression is that its almost more an encoding issue, various attempts to avoid redundancy :

- If I'm providing very atomic SOSA observations, shifting the UoM to the ObsProp saves me having to repeat this each time (while creating other issues, e.g. the multiple ObsProps by UoM)
- If I'm providing time series, shifting the UoM to the Observation saves me having to repeat this each time
- If I want to assure that one result value taken out of context can still be correctly interpreted, I probably have to pack everything on the result value (but that can also then get pretty silly, where do I stop, I need more than the UoM... ;) )

-- 
GitHub Notification of comment by KathiSchleidt
Please view or discuss this issue at https://github.com/w3c/sdw/issues/1267#issuecomment-869545615 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 28 June 2021 09:54:42 UTC