Observation Collection Characteristics Types

[KathiSchleidt]

Code lists has the following values initially:

• homogenousObservationCollection: if an attribute value is provided within the ObservationCharacteristics, this value applies to all contained observations (note: the observations need not contain this attribute as supplied via the ObservationCharacteristics).

  • attribute = nil - no observation within the collection provides this attribute
  • attribute = empty - values may be provided by the observations but is not provided at this level
  • attribute = value - this value applies to all observations within the collection
  • attribute = value set/range - this value set/range applies to all observations within the collection

• summarizingObservationCollection: if multiple values for an attribute are available in the contained observations, ALL values for this attribute (or the range of values contained in all Observations) are provided in the ObservationCharacteristics. An attribute may also be empty in the ObservationCharacteristics - in this case any value can be provided for this attribute within the contained Observations.

  • attribute = nil - no observation within the collection provides this attribute
  • attribute = empty - values may be provided by the observations but is not provided at this level
  • attribute = value - this value applies to all observations within the collection
  • attribute = value set/range - all observations provide a value within this set/range

• observingCapability: information about potential observations. Parallel to summarizingObservationCollection, with the caveat that values for not yet existent observations may be provided

  • attribute = nil
  • attribute = empty
  • attribute = value
  • attribute = value set

Note: check OGC nil - http://defs.opengis.net/elda-common/ogc-def/resource?uri=http://www.opengis.net/def/nil/OGC/0/&_format=html https://data.geoscience.fr/ncl/MissInfo

[KathiSchleidt]

Note: the constraints on Observation may need to be revisited based on these definitions

[ilkkarinne]

Firstly: I have started wondering if we want to define the nil/missing semantics at the conceptual level standard at all? If we do we probably have to leave defining the special value "nil" to the implementations anyway, as there may not be a nil mechanism available to other than GML encodings. As an example in JSON we probably would like to map the validTime into a string type with "date-time" format. How would be provide and "nil" value for this attribute in O&M JSON?

If yes, then how do we determine (automatically from an ObservationCharacterics instance) if an attribute has a value set/range or a single value? Thinking specifically time periods, which should be judged as ranges, I suppose, but still only have a single attribute value?

Also the term "empty" is not fully unambiguous here IMHO: we probably mean that the ObservationCharacterics does not contain any value for this attribute or there is no association given with the given role name.

[hylkevds]

JSON has the explicit null value that can be used for this. In SensorThings it is already used for this. The resultTime has to be provided when returning an Observation, either as an ISO time string, or the explicit null value.

If yes, then how do we determine (automatically from an ObservationCharacterics instance) if an attribute has a value set/range or a single value? Thinking specifically time periods, which should be judged as ranges, I suppose, but still only have a single attribute value?

I don't know what you mean exactly, but from an summarizingObservationCollection you can not determine the exact type of a property of a contained Observation, if the Collection supplies a (set of) range(s). Only that whatever the value is for the Observation, it falls in the given range(s). You should probably be able to look that up from the sensor or procedure, if it is given at the Collection level. This is also already the case in SensorThings. Datastream/phenomenonTime is always a range, but Observation/phenomenonTime can be a range of an instant.

[ilkkarinne]

@hylkevds: Ok, good to know that a solution exists for JSON. However, I'm still afraid we may enter too deeply into encoding domain here with these semantics.

I would suggest we bring this issue up in 19156 as an informative note, something like the following:

Note: While the attributes and associations of an ObservationCharacteristics instance may be used to describe characteristics of the members of an ObservationCollection, it is not required or even recommended in most cases to describe all of these member properties at the collection level. Cases where no value is provided for the ObservationCharacteristics attribute or association may lead into ambiguous interpretations, as it is not obvious if a missing property value in ObservationCharacteristics means that the member Observations have or may have no value for this property, or if the values of this member property is not described or bound at all by the memberCharacteristics association of the ObservationCollection (and thus the member Observations may contain any value for this property).

This ambiguity may be solved by defining special attribute or association values with "missing" of "null" semantics and using these values in cases where no value for the given property exists or is allowed in any of the member Observation instances. An example of such mechanism applicable to XML encodings is declaring an element as nillable and using the xsi:nil attribute with value "true" in XML Schema. Similarly the JSON null value may be declared as an indication of the "no member value" semantics in JSON implementations.

Implementations should clearly define a suitable mechanism for interpreting the semantics of the missing ObservationCharacteristics property values to solve the ambiguity described above.

[hylkevds]

I agree that the details would be better moved to the encoding packages. That informative note is fine.