OMS provides the relevant concepts for the structured description of observations, including the sampling structure often essential for true understanding of the nature of the observations being provided. As data provision mechanisms are transitioning towards highly distributed linked approaches, the model structure and packaging has been significantly abstracted. This approach allows implementers to explicitly select the concepts to be supported based on their requirements, while clearly stating to which requirements and Conformance Classes their implementation complies. Both the Observation and Sample sections of this model have been structured using the following layering of packages.

a) Conceptual: Within the Conceptual Model Packages, only Interfaces are provided. These models provide a very abstract view of the individual concepts they contain without reference to specific implementations. This approach allows for the inclusion of semantically aligned objects from external sources, which, although they have not been created under the OMS model, do provide concepts sharing the same semantic meaning as the concepts from the Conceptual models.

b) Abstract Core: Within the Abstract Core Model Packages, only abstract featureTypes are provided following the semantic structure of the Conceptual model (i.e. realizing the interfaces provided by the Conceptual Model Packages). A consistent approach to metadata provision is introduced. All associations from the abstract featureTypes reference the conceptual interfaces for greater implementation flexibility. The Abstract Core Model Packages are foreseen for the creation of domain models providing an Abstract Core ready for Extension.

c) Basic: Within the Basic Packages, simple concrete featureTypes (specializing the abstract ones from the Abstract Core model) have been defined with some basic utility attributes added for rapid out-of-the-box deployment. A few additional concepts pertaining to collections and potential observations are introduced at this level.

Some model elements used in the schema are defined in other International Standards. Table 7 lists the dependencies between the UML packages defined in this document and other International Standards, and Figure 1 shows the dependencies of the entire OMS UML model package to the other International Standards in a graphical form.

Properties of a feature fall into two basic categories.

1) Value (e.g. name, price, legal boundary) assigned by some authority. These are exact.

2) Value (e.g. height, classification, colour) determined by application of an observation procedure. These are estimates, with a finite error associated with the value.

The observation error typically has a systematic component, which is similar for all estimates made using the same procedure, and a random component, associated with the particular application instance of the observation procedure. If potential errors in a property value are important in the context of a data analysis or processing application, then the details of the act of observation which provided the estimate of the value are required.

An observation is an act associated with a discrete time instant or period through which a number, term or other symbol is assigned to a characteristic. This act involves application of a specified procedure, such as a sensor, instrument, algorithm or process chain. The procedure may be applied in situ, remotely, or ex situ with respect to the sampling location. The result of an observation is an estimate of the value of a property of a given feature; an observation is a property-value-provider for a feature-of-interest. Use of a common model allows observation data using different procedures to be combined unambiguously.

In conventional measurement theory (e.g. References [11], [14], [15], [16], [18], [23]) the term “measurement” is used. However, a distinction between measurement and category-observation has been adopted in more recent work^{[12],[17],[24]} so the term “observation” is used here for the general concept. “Measurement” may be reserved for cases where the result is a numerical quantity.

The observation itself is also a feature, since it has properties and identity.

Observation details are important for data discovery and for data quality estimation.

The observation could be considered to carry “property-level” instance metadata, which complements the dataset-level and feature-level metadata commonly provided via catalogue services (e.g. the ISO 19115 series or another community agreed one).

An observation results in a value being assigned to a characteristic. The characteristic is a property of a feature, the latter being the feature-of-interest of the observation. The observation uses a specified procedure performed by an observer, which is often an instrument or sensor^[11],[12] but may be a process chain, human observer, an algorithm, a computation or a simulator. The key idea is that the observation result is an estimate of the value of some quality (property, characteristic) of the feature-of-interest, and the other properties of the observation provide context or metadata to support evaluation, interpretation and use of the result. Figure 2 (based on representation work done under INSPIRE^[29]) provides a visual overview of this.

The relationship between the properties of an observation and those of its feature-of-interest is key to the semantics of the data model elaborated in this document. This is further elaborated in Clause D.3.

The principal location of interest of an observation is usually associated with the ultimate feature-of-interest.

However, the location of the feature-of-interest can potentially not be readily available. For example, in remote sensing applications, a complex processing chain is required to geolocate the scene or swath. In feature-detection applications, the initial observation can be made on a scene, but the entity to be detected, which is the ultimate feature-of-interest, occupies some location within it. The distinction between the proximate and ultimate feature-of-interest is a key consideration in these cases. The proximate feature-of-interest is the object upon which the measurement is directly performed, whereas the ultimate feature-of-interest is the object for which this measurement is ultimately seen as representative of.

Other locations may be relevant in various scenarios. Sub-sampling at locations within the feature-of-interest may occur. The procedure may involve a sensor located remotely from the ultimate feature-of-interest such as in remote sensing, or where specimens are removed from their sampling location and observations made ex-situ (the sampling schema description below elaborates on this). Furthermore, the location of the feature-of-interest may be time-dependent.

The model is generic. The geospatial location of the feature-of-interest may be of little or no interest for some observations (e.g. live specimens, observations made on non-located things like chemical species).

For these reasons, a generic Observation class does not have an inherent location property. Relevant location information should be provided by the feature-of-interest, by the sampling procedure, or by the observation procedure, according to the specific scenario.

Observation results may have many datatypes, including primitive types like category or measure, but may also have more complex types such as time, location and geometry. Complex results are obtained when the observed property requires multiple components for its encoding. Furthermore, if the property varies on the feature-of-interest, then the result is a coverage, whose domain extent is the extent of the feature. In reality, the result will typically be sampled discretely on the domain and may be represented as a discrete coverage.

Building on this, specialized observation types can be defined by communities to describe the type of result provided, expressed using a terminology common to that community.

The observation model takes a data-user-centric viewpoint, emphasizing the semantics of the feature-of-interest and its properties. This contrasts with sensor-oriented models, which take a process- and thus a provider-centric viewpoint.

The digital representation of an observation is a property-value-provider for a feature-of-interest. Aside from the result, the details of the observation event are primarily of interest in applications where an evaluation of errors in the estimate of the value of a property is of concern. The observation could be considered to carry “property-level” instance metadata, complementing the dataset-level and feature-level metadata that have been conventionally considered (e.g. ISO 19115-1).

Additional discussion of the application of the observation and sample models, and nuances within these, is provided in Annex D.

A sample may act as a proxy for the ultimate feature-of-interest of an observation, and be associated with this observation by the role feature-of-interest. In this case the sampled-feature association of the sample would point upwards in the chain of sampled features leading to the ultimate feature-of-interest of the observation. The sample may also be associated with observations, both those being made directly on the sample as well as observations on other samples.

Samples are artefacts of an observational strategy and have no significant function outside of their role in the observation process. The physical characteristics of the samples themselves are of little interest, except perhaps to the manager of a sampling campaign.

EXAMPLE 1 In various countries/domains, terms like “site” and station” are encountered. These usually correspond to an identifiable locality where a monitoring facility (host, platform, etc.) has been established, or sensors or other measurement devices (observers) have been deployed to acquire observations on a given observable property applying a specific procedure. In the context of the observation model, the spatial sample (both proximate and ultimate) connotes the world in the vicinity of the observer/sampler, so the observed properties relate to the physical medium at the observer/sampler described by the sample, and not to any physical artefact such as a mooring, buoy, benchmark, monument, well, and so forth that are potentially described by the Host.

EXAMPLE 2 In some domains, elements are taken from their natural environment (ex situ), curated and preserved for the purpose of keeping a trace of their existence. Examples include biodiversity studies, crop seed preservation, etc. In those cases, the material samples considered are called specimen. It is for this reason that the class named "SF_Specimen" in the previous edition of this document has been renamed "MaterialSample" in this edition.

EXAMPLE 3 Statistical samples usually apply to populations or other sets, of which a certain subset can be of specific interest.

A sample is intended to sample some object in an application domain. However, in some cases the identity, and even the exact type, of the sampled object is not known when observations are made using the sample.

Understanding the process by which samples are obtained is often essential to understanding the context of subsequent measurements on this object (feature-of-interest). Different sampling strategies can provide vastly different samples, in turn leading to different result values in observations pertaining to these samples.

A sample is created through the act of sampling, whereby a sampler follows a defined procedure in order to identify and/or extract representative samples from the ultimate feature-of-interest.

The nature of the sampler varies by sampling strategy; at one end of the spectrum the sampler can be a sensor or other automated measurement device; at the other end of the spectrum the sampler can be a human being providing observations or taking part in a biodiversity survey campaign.

As a dependence on the sampling strategy, a sampling procedure appropriate to the sampling act to be performed needs to be selected and defined. For the provision of fine-grained information pertaining to the sampling process, multiple sampling procedures can be applied to one sampling act. Multiple sampling procedures can also be required for the case where one sampling process classifies samples in accordance with multiple criteria.

EXAMPLE 1 When performing observations on populations, these can potentially first be sampled by gender and age. Sampling procedures describing the criteria utilized for gender and age classification can be provided individually.

A sampling event can involve very different samples, whereby some of these samples can serve purely to provide contextual information pertaining to the sampling event.

EXAMPLE 2 When sampling water from a river, information on the meteorology at the time of sampling can be relevant for the interpretation of measurements obtained on the water sample.

A small number of common sampling patterns, similar across domains, provide a basis for processing and portrayal tools, and depend particularly on the geometry of the sample design. These provide a basis for processing and portrayal tools which are similar across domains, and depend particularly on the geometry of the sample design. Common names for sampling features include specimen, sample, site, profile, transect, path, swath and scene.

Spatial sampling is classified primarily by the topological dimension. Material samples can provide information on their original source location, but are more often characterized by their size and storage location.

In addition, various preparation steps may be performed on samples both before and after observations are performed on the sample.

Additional information on provenance, curation and methods of archiving a sample has been delegated to external standards that may be referenced via the ‘metadata’ association that can be provided for all types contained within the Sampling model.

The type of the feature-of-interest is defined in an application schema (ISO 19109). This may be part of a domain model, or may be from a cross-domain model, such as Sample (Clause 11). The feature type defines its set of characteristics as properties. For consistency, the feature-of-interest shall carry the observed property as part of the definition of its type (e.g. Figure 3).

EXAMPLE A pallet with the characteristic mass is to be described via a feature model. In the simplest form, an interface “Pallet” can be defined as having the attribute “mass” of type “Measure” describing the mass characteristic of the pallet being described (Figure 3). However, when using this direct approach, no further measurement metadata is available; only the numeric mass is provided together with the unit of measurement.

Alternatively, through utilization of the OMS model, an observation providing the value of this property for the feature being investigated may be utilized to fulfil the data requirements ensuing from the Pallet Interface. This approach makes it possible for the information system to ‘describe’ how the result (here mass value) was obtained together with the relevant value.

For this purpose, the observation shall have observedProperty “mass”, the result shall be of the type “Measure” and the scale (unit of measure) shall be suitable for mass measurements. Thus, the requirements ensuing from the Pallet Interface are fulfilled, while additional relevant measurement meta-information is also provided; model consistency has been ensured. This approach is illustrated in Figure 4.

Figure 5 shows a complete representation of a mass observation. In addition to the basic information provided with the observation in Figure 4, information on the specific measurement device used is provided together with information on where this device was deployed as the observation was performed.

An attribute from within the conceptual model can be instantiated as an Observation in the concrete realization. The attributes that have been defined for the domain feature within the interface, in the example “mass” and “uom”, can be realized through the association of an Observation carrying this information. Formally, these two representations both realize the defined interface.

Based on the use case, when modelling, it is necessary to decide whether solely providing information of type "Measure" with UoM is sufficient for the domain considered. In some cases, the full OMS model is required to actually discover, exchange and reuse data properly. For example, a single attribute "lake surface" will be sufficient for most mapping agency needs, whereas a more thorough observation description of how that surface was measured and when (e.g. dam empty/full, rainfall observation, etc.) is important for water management needs.

A Sample feature is established in order to make observations concerning some domain feature. The association “sampledFeature” links the Sample feature to the feature which this Sample feature was designed to sample. The target of this association is usually a real-world feature from an application domain (see Figure 6).

EXAMPLE A profile typically samples a water- or atmospheric-column; a well samples the water in an aquifer; a tissue specimen samples a part of an organism.

Both the Sample feature and the domain feature can potentially appear as the feature-of-interest. If a Sample feature is involved, it samples a feature of a type defined in a domain model.

Any domain object can be a featureOfInterest of an Observation.

The more refined example described in Figure 7 further explains how both Sample and Observation from the OMS model can interact with a domain model.

In this example, Well, Aquifer and FluidBody are modelled outside the OMS model (in OGC:GWML2 respectively under GW_Well, GW_Aquifer and GW_FluidBody) but:

a) the Well also conforms to the Sample requirements;

b) instances from the domain model are the proximate and ultimate features of interest of the WaterSalinity observation.

The Well that samples the Aquifer acts as a proxy to the Aquifer in the observation act. The Well is thus considered as the proximateFeatureOfInterest of the Observation. The sampledFeature (the aquifer) of the Well is the ultimateFeatureOfInterest.

Depending on the use case, it is advisable to push the modelling choice a step further and instantiate a FluidBody in the system according to the semantics of the domain model (Well, Aquifer, FluidBody). The example is further refined accordingly in Figure 8. Then, depending on the viewpoint considered, either the instance of the Aquifer and/or the instance of the fluidBody can be considered as the ultimateFeatureOfInterest of the Observation. The Well remains the proximateFeatureOfInterest.

The Conceptual Observation schema is described as a class diagram in Figure 9. The schema is fully described in 8.1.2.

EXAMPLE 1 The resultTime typically corresponds to when the Procedure associated with the Observation was completed. For some observations this is identical to the phenomenonTime. However, there are important cases where they differ.

EXAMPLE 2 Where a measurement is made on a specimen in a laboratory, the phenomenonTime is the time the specimen was retrieved from its host, while the resultTime is the time the laboratory procedure was applied.

EXAMPLE 3 The resultTime also supports disambiguation of repeat measurements made of the same property of a feature using the same procedure.

EXAMPLE 4 Where sensor observation results are post-processed, the resultTime is the post-processing time, while the phenomenonTime is the time of initial interaction with the world.

EXAMPLE 5 Simulations can be used to estimate the values for phenomena in the future or past. The phenomenonTime is the time to which the result applies, while the resultTime is the time at which the simulation was executed.

EXAMPLE 1 An instance of a feature modelled in a specific domain model (Borehole according to OGC GeoSciML).

EXAMPLE 2 The bubble of air around the intake of an air quality monitoring station.

EXAMPLE 3 An existing well being used for water quality measurements.

EXAMPLE Observed radiance wavelength is determined by the response characteristics of the sensor.

A description of the observation procedure provides or implies an indication of the reliability or quality of the observation result.

EXAMPLE 1 The height of a tree, the depth of a water body, or the temperature of a surface are examples of observable properties, while the value of a classic car is not (directly) observable but asserted.

EXAMPLE 2 Groundwater Level.

On a groundwater well, the:

a) Groundwater Level (1 observable property)

is monitored

b) with an automated probe (that remains in the ground all year, constituting 1 procedure).

In addition, the groundwater well is revisited in the context of physical campaigns, where the:

c) Groundwater Level (still the same observable property as above)

is measured, but

d) with a manual probe (this is a different procedure than used above).

This allows for checking whether the probe needs recalibration.

EXAMPLE An instance of Procedure is a description of the process utilized by an observer. This could be a chemical analysis method, a protocol for measuring an object, but could also be a checklist utilized by a human observer during a biodiversity campaign. Procedure could further describe the algorithms behind simulators or models used to generate a result from other inputs.

An Observer responds to a stimulus (e.g. a change in the environment or input data composed from the results of prior Observations) and generates a result.

EXAMPLE Accelerometers, gyroscopes, barometers, magnetometers, etc. are Observers that are typically mounted on a modern smartphone (which acts as Host). Other examples of sensors include the human eyes.

EXAMPLE 1 Information regarding a sensor being attached to a pole.

EXAMPLE 2 The monitoring facilities pertaining to an environmental monitoring network.

EXAMPLE 3 The description of a ship cruise linking a research vessel with a marine network.

EXAMPLE 4 The participation of a citizen in a citizen-science project involving crowd sensing.

AbstractObservationCharacteristics and AbstractObservation from the Abstract Observation Core are described as a class diagram in Figure 10. The schema is fully described in 9.2 and 9.3.

The ObservingProcedure is a generic or standard procedure, rather than an event-specific process. In this context, parameters bound to the observation act, such as instrument settings, calibrations or inputs, local position, detection limits, asset identifier or operator may augment the description of a standard procedure.

EXAMPLE A time sequence of observations of water quality in a well can be made at variable depths within the well. While these can be associated with specimens taken from the well at this depth as the features-of-interest, a more common approach is to identify the well itself as the feature-of-interest and add a “samplingDepth” parameter to the observation. The sampling depth is of secondary interest compared to the temporal variation of water quality at the site.

EXAMPLE 1 A river, an aquifer, soil layer, outcrop, a butterfly, a survey area, a room, Abby’s car, a specific human being, this document.

EXAMPLE 2 To determine the concentrations of chemical compounds in a river, a sample is taken in a predefined location in the river. This sample is taken to a laboratory where the required chemical analysis is done. In this case, the river is the ultimateFeatureOfInterest, while the sample is the proximateFeatureOfInterest .

EXAMPLE 3 Pertaining to documents and observations on the consistency of documents, for the Observation “This clause is inconsistent”, the ultimateFeatureOfInterest is the entire document, while the proximateFeatureOfInterest is the specific clause being addressed.

EXAMPLE 4 The determination of the species of the butterfly, in this case the butterfly is the ultimateFeatureOfInterest, no proximateFeatureOfInterest need be provided.

If in the real world both ultimateFeatureOfInterest and proximateFeatureOfInterest exist but not both have a digital representation, then the appropriate relation should be selected that best describes the nature of the entity being referenced.

AbstractObservableProperty from the Abstract Observation Core is described as a class diagram in Figure 11. The schema is fully described in 9.4.

AbstractObservingProcedure from the Abstract Observation Core is described as a class diagram in Figure 12. The schema is fully described in 9.5.

AbstractObserver from the Abstract Observation Core are described as a class diagram in Figure 13. The schema is fully described in 9.6.

AbstractHost from the Abstract Observation Core is described as a class diagram in Figure 14. The schema is fully described in 9.7.

AbstractDeployment from the Abstract Observation Core are described as a class diagram in Figure 15. The schema is fully described in 9.8.

EXAMPLE 1 A researcher involved in a biodiversity survey campaign assessing the distribution of selected alien species. The deploymentReason describes the fact that this individual was involved in this campaign for the reason of identifying alien species.

EXAMPLE 2 A sensor is mounted on a building to monitor seismic activities.

EXAMPLE 3 A new sensor type is rolled out within a regional or thematic network due to new legal reporting requirements.

EXAMPLE 1 A researcher involved in a biodiversity survey campaign assessing the distribution of selected alien species. The deploymentTime provides the time period(s) during which this person carried out this activity in the framework of the campaign.

EXAMPLE 2 A sensor is mounted on a building to monitor seismic activities. The deploymentTime provides the time period(s) during which this sensor is mounted or active.

AbstractObservationCollection from the Abstract Observation Core is described as a class diagram in Figure 16. The schema is fully described in 9.9.

EXAMPLE When used as the value of an Observation: parameter, the name can take values like ‘procedureOperator’, ‘detectionLimit’, ‘amplifierGain’, ‘samplingDepth’, ‘analysisIteration’, etc.

The code list AbstractObservationType can be specialized as required to more precisely define the semantics of observation types, as done in the derived codelist ObservationTypeByResultType below.

The code list AbstractObservationCollectionType can be specialized as required to more precisely define the semantics of collection types, as done in the derived codelist ObservationCollectionType below.

Observation from the Basic Observations is described as a class diagram in Figure 17. The schema is fully described in 10.2.

ObservationCharacteristics from the Basic Observations is described as a class diagram in Figure 18. The schema is fully described in 10.3.

ObservationCollection from the Basic Observations is described as a class diagram in Figure 18. The schema is fully described in 10.4.

ObservationCollection from the Basic Observations is described as a class diagram in Figure 18. The schema is fully described in 10.5.

EXAMPLE In order to explicitly describe the capabilities of an environmental monitoring facility, information on which Observable Properties are being measured with which methodology is provided.

For example, in a national groundwater quantity monitoring network, depending on the equipment and the underlying observational strategies:

ObservableProperty from the Basic Observations is described as a class diagram in Figure 19. The schema is fully described in 10.6.

ObservingProcedure from the Basic Observations is described as a class diagram in Figure 20. The schema is fully described in 10.7.