- From: Kathi Schleidt via GitHub <sysbot+gh@w3.org>
- Date: Fri, 11 Jun 2021 11:44:32 +0000
- To: public-sdwig@w3.org
One bit that's been long bothering me in SOSA is that, at least in the examples, the ObservableProperty is somehow munched up with the FoI instance it pertains to. While I get the fact that I can then traverse the associations to discover that `sosa:observedProperty <tree/124#height>` has something to do with the `ssn:Property height`, I've never found reference to this more generic height property within the examples. On a practical level, I see more need for this generic height property to allow for comparison of the heights of `tree/124` vs `tree/125` The way @rob-metalinkage has done the cat fluffyness, it makes a great deal more sense to me, whereby I'd start with a generic fluffyness property, then specialize this to cat_fluffyness (other beasties also be fluffy!), thus allowing me to apply it to my `Mitzi` and Rob's `Mog` and do a comparative fluffyness study. The approach of linking the property with the class of the FoI is also more in line with the approach being taken by the [I-ADOPT Group in RDA](https://www.rd-alliance.org/groups/interoperable-descriptions-observable-property-terminology-wg-i-adopt-wg), where as far as I've understood, the `ContextObject` indicates the class the FoI is an instance of. Now getting to the heart of this thread, where to put the UoM. I tried something related during our rework of O&M to V3, proposed making it possible to indicate the UoM within the Observation itself (especially for dealing with time series. In O&M, we don't need to create an Observation for each value of a timeseries, one Observation can serve as the head for the entire series as long as the same observational metainformation pertains to all values. Would also ease alignment with the SensorThings API that has pulled the UoM up to the Datastream), but was voted down as the rest of the group preferred to keep the [UoM closer to the result](https://github.com/opengeospatial/om-swg/issues/133). Conceptually, to my view, it should be possible to shift the UoM up and down the chain from Result to Observation to ObsProp as required (these are very conceptual models we're dealing with here!) Pragmatically, I'd say it depends on the use case, e.g. is there potential for including Observations with nonstandard UoM, and would these be of benefit. Getting data in the wrong units is an eternal problem, but closing the door on potentially valuable data only due to the units its provided in would be a waste of good data (assuming the units can be converted) And yes, what this entire conundrum really needs are good stable tested examples!!! -- GitHub Notification of comment by KathiSchleidt Please view or discuss this issue at https://github.com/w3c/sdw/issues/1267#issuecomment-859523071 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 11 June 2021 11:45:10 UTC