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.