RE: ssn resultQuality thoughts.

Ø  Observations can be Features too

Observations are Features.

At least that’s what O&M / OMS are saying by typing them FeatureType in their logical models



Ø  Do we know what is supposed to go "into" resultQuality? A second set of observable properties?

Indeed as RobA suggest, I’d be tented to fragment this into various relatedObservation(s)

That’s also what we suggested for WaterQuality data where, in order to assess the resultQuality of waterquality Observation (ex : turbidity, suspended materials, …) extra Obs are taken at the same time (ex : weather).



Documenting these patterns is a must have but sure we’ll land in a ‘that depends on your UseCase situation’.

-          In some cases we’ll advise Observation via hasResultQuality to provide some Quality tags (‘raw data’, ‘expert validated’, …)

-          In some other cases

o   relating to other Observations provide information about « « quality » » of the First Observation the other are related to

o   the hasResultQuality info could also be modelled by an Obs : so which way to follow ? use both the hasResultQuality/relatedObservation to point to the same one ?

Maybe we should put all this in an issue

A bientôt

Sylvain



De : Rob Atkinson <ratkinson@ogc.org>
Envoyé : mercredi 27 mars 2024 01:34
À : Robert Warren <warren@glengarryag.com>
Cc : SDW WG <public-sdw-wg@w3.org>; kathi <Kathi@datacove.eu>
Objet : Re: ssn resultQuality thoughts.

The way I look at it Observations can be Features too (located in time !)

so a chain of observations such as various data quality measures can have additional metadata using the existing patterns - we should describe this.

the "simple" hasResultQuality  would rely on external metadata describing its procedure etc - e.g. part of the (unspecified) procedure model, or possibly the observedProperty model. or its range could be a complex object.....

IMHO it will be chaos if we dont provide canonical patterns - any number of complex result formats and no interoperability

rechartering will allow us to bottom this out with good examples, entailment rules, API for navigation of canonical patterns (at least as testing of the model with implementations - if not formally specified APIs)


Rob Atkinson
Senior Research Engineer  | Open Geospatial Consortium (OGC)
Mobile: +61 419 202973
ratkinson@ogc.org<mailto:ratkinson@ogc.org> | ogc.org<https://urldefense.com/v3/__http:/ogc.org/__;!!KbSiYrE!lJF3fMCrXhoySf4pZQqHRWEXggTnK-VQKuKMs4_D1cWPN-TJ3-1HS68GI8ZH7tbZoUxfwg2mjn3rLFlbIA$> | @opengeospatial


[https://portal.ogc.org/files/?artifact_id=99287]
Sign up for OGC News<https://urldefense.com/v3/__https:/ogc.us4.list-manage.com/subscribe?u=704e02f81107a6caab1568067&id=4e4528fd9d__;!!KbSiYrE!lJF3fMCrXhoySf4pZQqHRWEXggTnK-VQKuKMs4_D1cWPN-TJ3-1HS68GI8ZH7tbZoUxfwg2mjn3lFF7yWA$>


On Wed, Mar 27, 2024 at 6:28 AM Robert Warren <warren@glengarryag.com<mailto:warren@glengarryag.com>> wrote:
I'm writhing this to follow up to a few brief comments on last week's teleconference.

One of the corner cases of Sosa is that some sensors return result quality / precision data along with the result. The sosa examples we have so far are focused on nominal or static measurement errors.

In the case of GPS units and other "smart" sensor, the result is accompanied by performance data such as HVOP, Circular Error Probable or rms95. The GPS sensor reports point data as a result, but the actual location is within the area of an ellipse.

Do we know what is supposed to go "into" resultQuality? A second set of observable properties?

All my best,
Rob Warren



[https://portal.ogc.org/files/?artifact_id=99287]
Sign up for OGC News<https://urldefense.com/v3/__https:/ogc.us4.list-manage.com/subscribe?u=704e02f81107a6caab1568067&id=4e4528fd9d__;!!KbSiYrE!lJF3fMCrXhoySf4pZQqHRWEXggTnK-VQKuKMs4_D1cWPN-TJ3-1HS68GI8ZH7tbZoUxfwg2mjn3lFF7yWA$>