search

opengeospatial / om-swg

10 stars 6 forks source link

Observation Types #114

Closed KathiSchleidt closed 3 months ago

KathiSchleidt commented 3 years ago

OGC Comment

  1. Evaluator: Robin Huisman SIKB - Stichting Infrastructuur Kwaliteitsborging Bodembeheer - Soil data management and exchange / TerraIndex robin@terraindex.com
  1. Requirement: AbstractObservationTypeCodelistValue is not clear
  2. Implementation Specification Section number: 9.2.3 Attribute observationType
  3. Criticality: Minor
  4. Comments/justifications for changes: It's not clear how to use the AbstractObservationTypeCodelistValue and other codeLists. Can we get more description of how this should be used by defining your own lists and an example of how to do this?
KathiSchleidt commented 3 years ago

Add information on how to deal with the Observation Types in Annex B

KathiSchleidt commented 3 years ago

Spatial Sampling Feature Types are members of Observation Types, this is not correct

http://defs.opengis.net/elda-common/ogc-def/resource?uri=http://www.opengis.net/def/observationType&_format=ttl vs imported defs-dev.opengis.net/static/definitions/conceptschemes/om.ttl Issue seems to be from line 418, http://www.opengis.net/def/ogc-om/ owl:sameAs http://www.opengis.net/def/observationType/OGC-OM/2.0/ , http://www.opengis.net/def/ogc-om/ ; add member samplingSolid etc

sgrellet commented 3 years ago

Indeed, working on the V2 <-> V3 mapping, we land on ObservationTypes as currently defined in OGC definition Server.

Looking at http://defs.opengis.net/elda-common/ogc-def/resource?uri=http://www.opengis.net/def/observationType&_format=ttl we don't understand why things such as http://www.opengis.net/def/sampling-feature-type/ogc-om/2.0/sf_sampling-solid are in scheme of skos:inScheme http://www.opengis.net/def/observationType

The initial source is claimed to be (http://defs-dev.opengis.net/static/definitions/conceptschemes/om.ttl)

http://www.opengis.net/def/ogc-om/ owl:sameAs http://www.opengis.net/def/observationType/OGC-OM/2.0/ , http://www.opengis.net/def/ogc-om/

this leads SamplingFeatures types to be listed as ObservationTypes

KathiSchleidt commented 3 years ago

AbstractObservationTypeCodeListValue must be defined (add 9.10 Codelists) provide reference to annex C part

Add subclause to Annex C providing mapping from obstypes (see v2) to codelists (what OGC currently has, where missing TBD)

KathiSchleidt commented 3 years ago

Also pertains to other codelists:

KathiSchleidt commented 3 years ago

@ilkkarinne Why do we have a concrete CollectionTypeByMemberCharacteristicsSemantics normatively while all the other codelists are only abstract at the normative level, the other codelist realizations only informative?

I'd expect either concrete realizations for all in the normative model, or dropping the CollectionTypeByMemberCharacteristicsSemantics from the normative level (would prefer first option)

KathiSchleidt commented 3 years ago

Further - I'm at a bit of a loss as to how to formulate the req for the abstract codelists, currently failing at 10.12.1 AbstractObservationCollectionTypeCodeListValue

Topic for discussion tomorrow

ilkkarinne commented 3 years ago

The idea of the abstract codelists is to provide a place for classifying Observations, ObservationCollections, Samples etc. in any way that feels natural in the various application domain models without requiring or defining particular classification schemes in the spec. We did not want to (or did not know how to) provide normative classification schemes for Observations, Samples or Samplers, thus there are no concrete code list realisations for those in the normative UML packages. I have added a couple of them in the informative Codelist realizations package as examples on how it can be done, but the intention was newer to include them as requirements (or any other normative content) in the spec.

If I recall correctly the WG members felt that the ObservationCollection classification scheme based on the interpretation of the member characteristics associated with it was too important to be left out of the normative specification content, thus the codelist realisation for it (with the suggestion of providing at least the homogenous and summarizing codelist values) was added to the normative package and to the specification as requirements. This is a bit inconsistent to me, but I understand that leaving this classification scheme out of the spec would probably make it more difficult to reach interoperability in exchanging OM&S ObservationCollections between different implementations.

It is important to note that even if the CollectionTypeByMemberCharacteristicsSemantics codelist is provided in a normative package, any other realisations of AbstractObservationCollectionTypeCodeListValue can also be used to classify ObservationCollections in application domain models, even for the same ObservationCollection instance.

A clean way would be move the CollectionTypeByMemberCharacteristicsSemantics codelist into the informative Codelist realizations package with the other concrete codelists, but this would also mean stripping the homogenous/summarizing classification from the spec requirements. Somehow I don't think we want to do this kind of change at this point of the process, especially as there have been no review comments suggesting this.

ilkkarinne commented 3 years ago

The ObservationTypeByResultType codelist was moved from the informative Codelist realizations package into the Basic Observations package, and thus made normative. As per resolution defined in the issue https://github.com/opengeospatial/om-swg/issues/123#issuecomment-857534640, I have how added the following new constraints in the UML:

The following constraints shall be applied to the value of the result association of the Observation based on the codelist value used:

  • If the value "measurement" is used, the value of the result shall be of type Measure.
  • If the value "category-observation" is used the value of the result shall be of type ScopedName.
  • If the value "truth-observation" is used, the value of result shall be a truth value.
  • If the value "count-observation" is used, the value of the result shall be of type Integer.
  • If the value "temporal-observation" is used, the value of the result shall be of type TM_Object.
  • If the value "geometry-observation" is used, the value of the result shall be of type Geometry
  • If the value "complex-observation" is used, the value of the result shall be of type Record.
  • If the value "discrete-coverage-observation" is used, the value of the result shall be of type DiscreteCoverage.
  • If the value "discrete-point-coverage" is used, the value of the result shall be of type DiscretePointCoverage.
  • If the value "timeseries-observation" is used, the value of the result shall be a timeseries (a sequence of data values which are ordered in time) constrained by the phenomenonTime.

If the text above seems ok, I can copy it as the value of the new requirement /req/obs-basic/ObservationTypeByResultType-con is the specification

KathiSchleidt commented 2 years ago

Rephrased as follows:

If information on the type of Observation is provided, the constraints defined in the referenced codelist SHALL be used.

KathiSchleidt commented 2 years ago

Added Requirement

/req/obs-core/AbstractObservationType/AbstractObservationType-sem

A codelist detailing the semantics of observation types. A concrete realization must be created for the application.

sgrellet commented 2 years ago

MUST VS SHALL discussion -> 'In discussion'

dr-shorthair commented 2 years ago

'SHALL' is a requirement in this document. 'MUST' is a requirement inherited from a dependency.

KathiSchleidt commented 2 years ago

'MUST' is a requirement inherited from a dependency. is what I tried to indicate - if an application wants to use values from this abstract codelist, they first must create a concrete codelist

Same as in #140 - but there Scott has stated "MUST" is not permitted in OGC Standards.

My issue with Ilkka's reformulation there of Concrete realizations are used by applications. is that we'll be faced by the eternal question of where this codelist is. In reality, somebody MUST create such a codelist.

dr-shorthair commented 2 years ago

Scott has stated "MUST" is not permitted in OGC Standards.

Yeah - I saw that, and am confused/concerned. I learned the definitions of SHALL, MUST, SHOULD, MAY and NOT from my work on OGC and ISO standards. @ogcscotts can you clarify when MUST got outlawed?

ilkkarinne commented 2 years ago

Let's try to avoid the MUST, we have to get this and a bunch of things resolved in three days. My feeling is that the MUST may also get us pushed back in the DIS Ballot at the latest.

A new try:

Requirement /req/obs-core/AbstractObservationType/AbstractObservationType-sem An empty extension point for providing various classification schemes for Observations. If Observation classification schemes are used in the implementing application schemas, the codelists defining the classifications SHALL be derived from this codelist.

KathiSchleidt commented 2 years ago

Why not:

A codelist detailing the semantics of observation types. A concrete realization SHALL be created for the application.

KathiSchleidt commented 2 years ago

An empty extension point for providing various classification schemes for Observations. If Observation classification schemes are used in the implementing application schemas, a concrete realization SHALL be created for the application.

KathiSchleidt commented 2 years ago

Accepted

hylkevds commented 2 years ago

All requirements that have a "must":

KathiSchleidt commented 2 years ago