Physical Properties

: Public Package

Created:	08/08/2012 22:03:34
Modified:	29/11/2012 13:32:32

Project:
Author:	Jeremy
Version:	1.0
Phase:	1.0
Status:	Proposed
Complexity:	Easy
Difficulty:
Priority:
Multiplicity:
Advanced:
UUID:	{538CB5B2-1302-4dcb-858B-9B69C41893CE}
Appears In:

The package 'Physical properties' contains: - a palette of quantity value [1] classes specialising Measure (from ISO 19103), or subclasses thereof, for sensible, well-defined, standard meteorological, hydrological and oceanographic physical properties - usually derived from BUFR or GRIB definitions; and - a palette of «CodeList» classes for expressing nominal values of meteorological, hydrological and oceanographic physical properties. These classes describing meteorological, hydrologic and oceanographic quantity values and nominal property values, governed by WMO, can be imported into Application Schema ensuring consistent application of semantics. All 'quantity value' classes are defined as specialisations of Measure (from ISO 19103 Basic types) or sub-classes thereof (e.g. Visibility is a specialisation of Distance (from ISO 19103 Basic types), which is itself a specialisation of Measure). An instance of a 'quantity value' class provides both the value of the quantity (e.g. "15.2") and the unit of measure that that value is specified in (e.g. "degrees Celsius"). Each 'quantity value' class asserts semantics associated with a specific physical quantity enabling one to determine the physical quantity that the value describes (e.g. AirTemperature/value = "15.2" is a value of air temperature). It is crucial that Measure (from ISO 19103) is the root class for quantity value classes because it is consistently used throughout the ISO 19100 series of International Standards to express the numeric value of a property obtained through measurement or assertion (for example, see ISO 19156 OM_Measurement). Each quantity value class is associated with a physical property defined (or referenced) in the WMO Table Driven Code Forms (e.g. BUFR or GRIB). This association is currently specified as a note (e.g. AirTemperature has the following annotation: "The temperature indicated by a thermometer exposed to the air in a place sheltered from direct solar radiation. In FM-92 GRIB, encoded as GRIB Code-table 4.2 discipline 0 (meteorology), category 0 (temperature), #0 temperature." The UML tag [tagged-value] "quantityName" is intended to support automated mapping from the UML model to the WMO Table Driven Code Forms (TDCF); each 'quantity value' class shall use the "quantityName" tagged-value to refer to a canonical identifier for the physical quantity (e.g. AirTemperature is defined as: "quantityName" = "http://data.wmo.int/def/grib2/codeflag/4.2/0.0.0"). The URI for the "quantityName" is intended to be short whilst retaining human readability. All 'quantities' will now be identified with URI of the form: [http://data.wmo.int/def/quantities/{quantity}]. Note that all {quantity} names must be unique; these are anticipated to be derived from the 'shortnames' defined by IPET-DRC for BUFR elements. Registers for meteorological, aeronautical-meteorology and oceanography will be created with identifiers as follows: - meteorological properties: [http://data.wmo.int/def/common/quantities/meteorology]; - aeronautical meteorological properties: [http://data.wmo.int/def/common/quantities/aeronautical-meteorology]; and - oceanographical properties: [http://data.wmo.int/def/common/quantities/oceanography]. These 'quantity value' classes are intended to be used as Types for attributes in Application Schema that build on the WMO METCE foundation (e.g. the MeteorologicalAerodromeObservationRecord (from ICAO MetCC) defines an attribute 'airTemperature' of type 'AirTemperature'). Note that where a physical property is required for an Application Schema that is _NOT_ listed in here (e.g. feels-like temperature [2]), one can submit a request to WMO to have this added to the model. In the interim (or for the longer term if there need to establish a standard definition for the property) use a generic measure type from ISO 19103 or meteorological measure type from MetBasic (e.g. ThermodynamicTemperature) and apply the semantics to the attribute (e.g. 'feelsLikeTemperature' of type 'ThermodynamicTemperature' from MetBasic). Also note that in order to limit the number of 'quantity value' classes to a manageable collection, qualifying semantics like maximum, minumum, mean etc. are expected to be provided from the attribute in the Application Schema subscribing to a given 'quantity value' type (e.g. attribute 'maxAirTemperature' of type 'met-basic:AirTemperature' may be defined in an Application Schema wherein the modeler should ensure they include documentation that describes that attribute as a 'maximum'. Further qualification of the attribute may be provided using the Observable Property Model if necessary. Finally, it is also worth noting that if deemed necessary one may include additional constraints against a the attribute within an Application Schema that specifies the acceptable set of units of measure for that may be used to specify the quantity-value within their domain of application. This may be implemented as schematron. «CodeList» classes will reference the controlled vocabulary that provides the set of permissible values [tagged value "vocabulary"] and specify the level of governance applied to validation of the use of terms for that «CodeList» class [tagged value "extensibility"]. - Tagged value "vocabulary" is used to refer to the authoritative list of terms using an HTTP URI. This authoritative list may be implemented as a GML dictionary, SKOS concept scheme etc.; and - Tagged value "extensibility" indicates the governance regime applied to evaluation of terms used as values of the <CodeList> class; "none", "narrower" or "any". Basically, "none" implies _ONLY_ terms from the specified code list are permitted, "narrower" implies you can use terms with more refined definitions (e.g. narrower semantics), and "any" implies that anything goes and the specified code list is simply a recommendation! The physical properties are organised according to the scheme used in WMO FM-92 (GRIB): discipline | category | parameter. Whilst this scheme is product centric, it provides a well-known categorisation for physical properties within the meteorological community. In support of the ICAO aviation requirement, 'Meteorological basic types' includes an additional 'Aviation' discipline that does not occur in GRIB Code-table 0.0 "Discipline". Note: should these quantity value and «CodeList» classes need to be reorganised in future, this should not affect Application Schema that have imported these classes as the class GUIDs will be unaffected. Note: missing value codes identified thus far ... {incomplete} i) Cloud cover: - sky obscured by fog and/or other meteorological phenomena - cloud cover is indiscernible for reasons other than fog or other meteorological phenomena, or observation is not made ii) Cloud type: - cloud not visible owing to darkness, fog, duststorm, sandstorm, or other analogous phenomena iii) runway deposit - not reported (e.g. due to runway clearance in progress) iv) depth of runway deposit - runway or runways non-operational due to snow, slush, ice, large drifts or runway clearance, but depth not reported - depth of deposit operationally not significant or not measurable v) friction coefficient / braking action - braking conditions not reported and/or runway not operational [1] Quantity Value: number and reference together expressing magnitude of a Quantity (from the 'International vocabulary of metrology' [http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf]) [2] 'Feels-like temperature' is used by the Met Office (UK) and takes into account wind speed to give a more representative indication of how the temperature will feel. For example if the temperature is 0 °C it will feel much colder with a wind speed of 25 than with a wind speed of 10. [source: http://www.metoffice.gov.uk/guide/weather/symbols]

Tagged Values

Tag	Value
xsdDocument	physicalProperties.xsd
Details: