Quality Element Group Requirements Class: Basic Types and Simple Components Schemas Requirements Class

OGC 08-094r1 SWE Common Data Model This group allows the use of some of the XML elements define above to add qualitative information to a simple data component. The following examples illustrate how this is done in a SWE Common XML instance. This first example shows that quality is expressed by wrapping the value in one of the data components defined previously that is appropriate for the desired representation. Here a “Quantity” element is used to specify a decimal value representing relative accuracy: swe:Quantity definition = http:sweet.jpl.nasa.gov2.0sciUncertainty.owlAccuracy swe:label Relative Accuracy swe:label swe:uom code = swe:value 5 swe:value swe:Quantity This snippet is then inserted within the data component element whose value’s quality needs to be expressed. This is shown below: swe:Quantity definition = http:sweet.jpl.nasa.gov2.0physDynamics.owlVelocity swe:label Velocity swe:label swe:description Linear velocity of the vehicle swe:description swe:quality swe:Quantity definition = http:sweet.jpl.nasa.gov2.0sciUncertainty.owlAccuracy swe:label Relative Accuracy swe:label swe:uom code = swe:value 5 swe:value swe:Quantity swe:quality swe:uom code = ms swe:value 23.5 swe:value swe:Quantity This example is a velocity measurement of 23.5 meters per seconds, with a relative accuracy of 5. Absolute accuracy could have been specified as well by using a different definition URI and setting the unit of the accuracy value to “ms”. Bidirectional tolerance is a measure of quality that is often used for specification of mechanical parts. Such a use case is shown below: swe:Quantity definition = http:sweet.jpl.nasa.gov2.0spaceExtent.owlThickness swe:label Thickness swe:label swe:description Thickness measured by the sheet metal gauge swe:description swe:quality swe:QuantityRange definition = http:sweet.jpl.nasa.gov2.0sciUncertainty.owlTolerance swe:label Dimensional Tolerance swe:label swe:uom code = um swe:value -20 +0 swe:value swe:QuantityRange swe:quality swe:uom code = mm swe:value 5.6 swe:value swe:Quantity In the previous example, the sheet of metal is measured to have a thickness between 5.58 and 5.6 millimeters. Note that a different unit i.e. micrometer is used for the tolerance value. 82 Copyright © 2011 Open Geospatial Consortium SWE Common Data Model OGC 08-094r1 The following example shows the use of a categorical representation of quality in order to implement a passfail quality control flag as defined in the MMI Marine Metadata Interoperability ontology: swe:Quantity definition = http:sweet.jpl.nasa.gov2.0physPressure.owlPressure swe:label Water Pressure swe:label swe:description Water pressure measured by CTD swe:description swe:quality swe:Category definition = http:mmisw.orgontq2otestpointsGoodTest swe:label QC Flag swe:label swe:codeSpace xlink:href = http:mmisw.orgontq2oflag swe:value fail swe:value swe:Category swe:quality swe:uom code = dbar swe:value 1084 swe:value swe:Quantity All previous examples show how quality can be given along with the inline value. However this standard allows specifying quality in a data descriptor, which means that the qualitative information applies to all data values represented by the component in a separately encoded data stream. This is just achieved by using the component with no inline values. Additionally the quality value can be given in the encoded data stream along with the measurement values when the quality component is defined itself as a field of the dataset. This is shown in clause 7.5.3 describing the “DataStream” element. The “quality” property element should never be used recursively by an implementation i.e. This property should not be used within a data component that is himself used as an instance of the “Quality” group. Indeed, although it is theoretically acceptable to describe the quality of the qualitative information itself, it is a practice that would greatly complexify the analysis of such metadata and is thus strongly discouraged.

8.1.14 NilValues Element

The “NilValues” element is the XML schema implementation of the “NilValues” UML class defined in clause 7.2.16. The schema snippet for this element and its corresponding complex type is shown below: element name = NilValues substitutionGroup = swe:AbstractSWE type = swe:NilValuesType complexType name = NilValuesType complexContent extension base = swe:AbstractSWEType sequence element name = nilValue type = swe:NilValue maxOccurs = unbounded sequence extension complexContent complexType Copyright © 2011 Open Geospatial Consortium 83 OGC 08-094r1 SWE Common Data Model complexType name = NilValuePropertyType simpleContent extension base = token attribute name = reason type = anyURI use = required extension simpleContent complexType This element allows specifying a list of nil value for a particular data component. The next example shows how it can be used to reserve values for indicating a bad measurement in a radiation sensor data stream. swe:Quantity definition = http:sweet.jpl.nasa.gov2.0physRadiation.owlIonizingRadiation swe:label Radiation Dose swe:label swe:description Radiation dose measured by Gamma detector swe:description swe:nilValues swe:NilValues swe:nilValue reason = http:www.opengis.netdefnilOGC0BelowDetectionRange -INF swe:nilValue swe:nilValue reason = http:www.opengis.netdefnilOGC0AboveDetectionRange INF swe:nilValue swe:NilValues swe:nilValues swe:uom code = uR swe:Quantity This means that if the “-INF” or “INF” values these are allowed values for a floating point representation are found in the data stream, they should not be taken as real measurement values but instead carry a specific meaning that is given by the “reason” attribute. In this example, all other values i.e. all decimal numbers should be interpreted as a radation dose expressed in micro-roentgens. One important feature is that the “NilValues” object can be referenced instead of being included inline. In addition to allowing their definition in shared repositories, this also enables sharing nil value definitions between several components of the same dataset. This is for instance useful for describing multispectral and hyperspectral images since all bands in these types of images usually share the same nil values. The field representing the first band can then be defined as shown below: swe:Count definition = http:sweet.jpl.nasa.gov2.0physRadiation.owlRadiance swe:label Band 1 swe:label swe:nilValues swe:NilValues id= NIL_VALUES swe:nilValue reason = http:www.opengis.netdefnilOGC0BelowDetectionRange swe:nilValue swe:nilValue reason = http:www.opengis.netdefnilOGC0AboveDetectionRange 255 swe:nilValue swe:NilValues swe:nilValues swe:Count And the following bands can have a much shorter description as it just references the nil values group previously defined: swe:Count definition = http:sweet.jpl.nasa.gov2.0physRadiation.owlRadiance swe:label Band 2 swe:label swe:nilValues xlink:href = NIL_VALUES swe:Count ... swe:Count definition = http:sweet.jpl.nasa.gov2.0physRadiation.owlRadiance swe:label Band 33 swe:label 84 Copyright © 2011 Open Geospatial Consortium