ISO 19156 ‘Observations and measurements’ provides a conceptual schema for observations and the features involved in sampling when making observations, and specifically designed to support the exchange of information describing both the observing event and the results of the observation between different scientific and technical communities.<br /></p><p><br /></p><p>Whilst the name of the model invokes a particular concept to meteorologists (e.g. ‘observation’, the measurement of physical phenomena with an instrument or sensor – disjoint from the concept of ‘forecast’) it is important to consider the semantics of the model. The class OM_Observation is defined as ‘an estimate of the value of some property of some Thing using some specified Process’. The process may be an instrument/sensor (directly) measuring some physical parameter or a numerical simulation predicting future values. Thus the ‘Observations and measurements’ conceptual model may be used to represent both observations and forecasts.<br /></p><p><br /></p><p>Meteorological observations or forecasts clearly relate to the real world. For example, we may observe the weather for Exeter or provide a weather forecast for the ‘North Atlantic European’ area. However, there is a level of abstraction to resolve:<br /></p><p>- An observation of the weather for the city of Exeter happens at some representative location within the city or some representative locale nearby; or<br /></p><p>- The forecast domain for ‘North Atlantic European’ is specified so that it covers the areas for which a forecast is required<br /></p><p><br /></p><p>In each case, the ‘observation’ event relates to some sampling regime that is a proxy for the real entity of interest (e.g. the site of the weather station, or the extent of the forecast domain). The observation or forecast is not directly related to real-world entities.<br /></p><p><br /></p><p>ISO 19156 ‘Observations and measurements’ provides a conceptual model for describing this layer of indirection: Sampling Features. Further specialisations of Sampling Feature are provided based on spatial topology (SF_SpatialSamplingFeature and sub-types thereof).<br /></p><p><br /></p><p>In all cases identified thus far in meteorology, it appears useful to describe an observation, measurement or forecast with respect to the sampling regime (e.g. the Sampling Feature) and indirectly refer to the real-world entity for which the Sampling Feature is a proxy.<br /></p><p><br /></p><p>Spatial Sampling Features are considered an essential part of WMO METCE: all observations, measurements and forecasts of meteorological phenomena shall define the ‘featureOfInterest’ as a concrete sub-type of SF_SpatialSamplingFeature.<br /></p><p><br /></p><p>Class 'OM_Process' (related to OM_Observation via the 'Procedure' Association) is used to define the process(es) involved in generating an observation. In order to ensure a consistent implementation of the abstract OM_Process class, *ALL* Application Schema based on WMO METCE shall use the WMO Process class (or sub-class thereof) to describe the observation procedure.<br /></p><p><br /></p><p>WMO METCE provides three specialised types of OM_Observation; each of which enforce the constraints that 'featureOfInterest' shall refer to an entity of type SF_SpatialSamplingFeature (from ISO 19156), or subclass thereof, and 'procedure' shall refer to an entity of type Process (from WMO METCE), or subclass thereof.<br /></p><p>- SamplingObservation: subclass of OM_Observation providing a general purpose observation type;<br /></p><p>- ComplexSamplingMeasurement: subclass of OM_ComplexObservation for use where the observation event is concerned with the evaluation of multiple measurands at a specified location and time instant or duration - the result of this observation type shall refer to an entity of type Record (from ISO 19103), or subclass thereof; and<br /></p><p>- SamplingCoverageMeasurement: subclass of OM_DiscreteCoverageObservation for use where the observation is concerned with the evaluation of measurands that vary with respect to space and/or time - the result of this observation type shall refer to an entity of type CV_DiscreteCoverage (from ISO 19123).<br /></p><p><br /></p><p>---<br /></p><p><br /></p><p><i>A note on the application of OM_Observation/observedProperty:</i><br /></p><p><br /></p><p>If one looks at the examples in ISO 19156 and Sensor Observation Service specification, examples of observedProperty include 'mass', 'salinity', 'water height' and 'effective temperature'. In the case of the third and fourth example, these are drawn from the NASA SWEET ontology. Using the terminology from the International vocabulary of metrology [1] these are 'Quantities'. <br /></p><p><br /></p><p>Although observedProperty is specified in ISO 19156 as type GF_PropertyType (from ISO 19109), the behaviour inferred from the examples indicates that observedProperty is used to refer to specific entities rather than the relationships between entities. The General Feature Model (as defined in ISO 19109) specifies instances of a «metaclass» (e.g. GF_PropertyType) as UML Classes. In contrast, the rules for Application Schema require that properties are implemented as attributes, association roles and operations resulting in a contradicting duality of 'classes-that-are-properties'. <br /></p><p><br /></p><p>However, given that observedProperty is implemented in GML as gml:ReferenceType, observedProperty can only refer to its target value via xlink:href (e.g. using HTTP URI). No type checking of the xlink target is implied. Thus we can *ASSUME* that the observedProperty behaves like an instance of a Class without adverse side effects, thus matching the behaviour we see in the examples. We don't need to get too hung up with ensuring that the entities referenced by observedProperty are faithful implementations of GF_PropertyType (e.g. FC_PropertyType); we can reference definitions of Quantities from external thesauri, ontologies or feature type catalogues that meet the desired semantics.<br /></p><p><br /></p><p>In some cases the Quantity referenced via observedProperty *MAY* genuinely be GF_PropertyType that is used in the Feature Type specification of a domain feature; for example GF_PropertyType 'salinity' may be an attribute of a WaterBody «FeatureType». Alternatively, one may publish a definition of «FeatureType» WaterBody and the associated GF_AttributeType 'salinity' in a Feature Type Catalogue and the assert that GF_AttributeType WaterBody.salinity is equivalent to an existing definition of salinity Quantity (e.g. http://sweet.jpl.nasa.gov/2.3/propChemical.owl#Salinity) that is used as the value of observedProperty in observation datasets. This would allow one to reconcile these 'properties' and match domain feature to observation result.<br /></p><p><br /></p><p>However, we must note that the observedProperty is only meant to provide a metadata hook to find observations associated with a given quantity. Previously, the role of observedProperty has been over interpreted: it is not a binding mechanism between domain feature and observation result - just metadata describing the quantity observed.<br /></p><p><br /></p><p>As an aside, note that within the Sensor Observation Service, the observedProperty is a key used within the query API to select observations. This is why observedProperty is implemented as gml:ReferenceType: the identifier is used as the well-known key to extract appropriate data.<br /></p><p><br /></p><p>It is not uncommon for an observation or measurement event to evaluate multiple measurands. For example: <br /></p><p>- a 'water quality' measurement may evaluate properties such as salinity, nitrate, dissolved oxygen, pH and turbidity;<br /></p><p>- a weather forecast produced from a numerical simulation may simultaneously evaluate dozens of parameters. <br /></p><p><br /></p><p>One of the most useful 'discovery paths' for finding observation data is anticipated to use the observed physical phenomenon; "find me all the Observations that include 'air-temperature' data". Crucially, the Observation provides metadata about the resultant datasets, mitigating the need for a data-consumer to parse the data-payload to discover physical phenomena are included. This is especially important for coverage datasets where it is not unusual for the data-payload may be many gigabytes in size - or larger!<br /></p><p><br /></p><p>OM_Observation/observedProperty provides one such mechanism to discover Observations. However, observedProperty is specified with cardinality of one; only a single property can be referenced. Thus in the example above, observedProperty can only be used to reference an aggregate property such as 'water quality'. To discover observations based on the individual quantities (e.g. salinity, nitrate, dissolved oxygen, pH or turbidity) the observedProperty must be supplemented.<br /></p><p><br /></p><p>One option is to put the physical property information in the OM_Observation/procedure/OM_Process. The 'procedure' may include a description of the set of measured phenomena. However, as the OM_Process object will typically be re-used across a number of Observation events, it is likely that the object will be published as a separate entity that is _REFERENCED_ from the Observation. Finding specific Observations that include measurements of a given physical phenomenon would require the OM_Process object to be fully resolved for indexing to support search. <br /></p><p><br /></p><p>Two options are proposed:<br /></p><p><br /></p><p>i) External definition of aggregate property:<br /></p><p>- An external definition of 'water quality' may be provided that aggregates 'salinity', 'nitrate', 'dissolved oxygen', 'pH' and 'turbidity'. <br /></p><p>- A user searching for data on 'turbidity' would first search those external definitions for references to property 'turbidity', resulting in the property 'water quality' being discovered. <br /></p><p>- Subsequently, the user would search for observations with observedProperty specified as 'turbidity' -OR- 'water quality'.<br /></p><p><br /></p><p>ii) Internal definition of aggregate property using Observable Property model:<br /></p><p>- The individual properties 'salinity', 'nitrate', 'dissolved oxygen', 'pH' and 'turbidity' may be specified via OM_Observation/parameter using the soft-typed NamedValue class.<br /></p><p>- The appropriate semantics are found in the GF_AssociationRole 'property' within the Observable Property model; the valueType is specified as AbstractObservableProperty enabling an instance of either CompositeObservableProperty -OR- ObservableProperty to be referenced. <br /></p><p>- NamedValue/name is specified as Type 'GenericName'. To enable software systems to identify the ObservedProperty entities when parsing the observation, 'name' must be specified consistently.<br /></p><p>- Assuming that the Observed Property model is published within a Feature Type Catalogue as part of WMO METCE as an instance of FC_AssociationRole, GF_AssociationRole 'property' will be identified with the HTTP URI http://data.wmo.int/def/observable-property/property.<br /></p><p>- NamedValue/value is specified as Type 'Any'; in this case, 'value' shall be defined as an instance of CompositeObservableProperty enabling each of the individual physical properties to be specified within the composite.<br /></p><p>- Data management systems can be configured to index observation instances based on the Observable Property.<br /></p><p><br /></p><p>Use of the Observable Property model also enables a data publisher to explicitly specify any constraints or qualifications associated with the observed physical properties. Please refer to the Observed Property model for more details.<br /></p><p><br /></p><p><br /></p><p>[1] http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf<br /></p>