Units of Measure Use and Definition Recommendations
AUTHOR: Name: John Bobbitt
Address: Petrotechnical
Open Software Corporation
9801 Westheimer Ave, Suite 450
Houston, Texas 77042
Phone: 713-267-5174
Email: bobbitt@posc.org
DATE: March 11, 2002
The following set of recommendations was developed at POSC in coordination with other groups, including CSIRO and the OpenGIS. It has been submitted to POSC for approval, and to OpenGIS for approval.
When an abbreviation for units of measure is to be used in an element or attribute name, the abbreviation should be uom or UOM.
Comment: The other obvious choice is “unit.” Since “unit” can have other meanings, it was felt that “uom” was a better choice than “unit.” The important point is to select one, and use it exclusively.
Comment: This recommendation is for abbreviations only. It is still permissible to use the full name, “UnitOfMeasure,” where appropriate.
A measureType datatype be defined as follows:
<xsd:complexType name="MeasureType">
<xsd:simpleContent>
<xsd:extension base="xsd:double">
<xsd:attribute name="uom" type="xsd:anyURI" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
The type for the attribute, uom, may also be IDREF or string, with the understanding that it will be a keyref to a value that is contained within the file.
Comment: The use of xsd:double for the value is used since it is the most general format available in the W3C datatypes. It is not intended to imply any semantics on the data value, or to imply any special computer representation of the value.
Comment: It is intended that the attribute, uom, be a reference to another instance within the same file. Thus, alternative formulations of the MeasureType would allow the uom to be of type xsd:IDREF, or of type xsd:string, where string is declared to be a keyref to a locally defined key. The particular implementation of the MeasureType is left to the using application. Note that xsd:IDREF is being deprecated, and its use is discouraged.
Comment: The use of xsd:anyURI for a local reference implies that a “#” is included. Applications should be able to handle a reference with or without the “#” symbol. Below is an example of a MeasureType with uom of type xsd:anyURI and one of xsd:string:
<length uom=”#ft”>26.62</length>
<width uom=”ft”>18.3</width>
Comment: The Recommendation uses the term, “MeasureType.” This is not mandatory. The name of the complexType is local, and is under control of the schema developer. However, the structure of the complexType should be maintained.
Comment: The Recommendation is that the uom attribute be optional. This is not mandatory. The schema developer may make it required.
Comment: The string value of the uom attribute does not contain any semantic meaning. It is strictly defined as a key reference to another instance within the document. The use of “ft” in the above example does not necessarily imply that the unit of measure is a foot. However, in practice, it would probably be useful to have a meaningful value.
A unit of measure reference type be defined as follows:
<xsd:complexType name="unitref">
<xsd:attribute name="uom" type="xsd:anyURI" use="required"/>
</xsd:complexType>
Comment: The comments for Recommendation 2 apply to Recommendation 3.
Comment: This datatype differs from the MeasureType only in that there is no value. Its usage is to set a unit of measure within a context, rather than to assign a unit of measure to a value.
The uom attribute defined above is intended to be a key reference to an instance within the same document. The instance within the document is a definition of the unit of measure. The definition may either be contained at that point in the document, or be a reference to a definition in another document. This latter case is referred to as a “skip reference.”
Every uom value in a document should reference an instance with an id attribute within the document.
Comment: Recommendation 4 is a preferred practice. There are two exceptions to the practice. The first is that the uom attribute directly reference an instance in another document. This alternative puts a burden on the reader, and may degrade interoperability.
Comment: The second exception is that the reference be implied, rather than explicit. In particular, using the example above, the “ft” used as a reference is intended to imply that there is meaning to “ft” that is known to the reading application. This puts a burden on the reader to understand all uom references, since they are implicitly defined. While this practice is acceptable in a tightly controlled environment, it is not interoperable in a general environment, and its use is highly discouraged. This comment leads to the following variation on Recommendation 4:
Within a tightly controlled environment, it is acceptable for the uom value to be a symbol that represents a unit of measure. When this is the case, there must be a specification that lists all the acceptable symbols and their meanings.
Comment: When using Recommendation 4a – reference by symbol – compliant applications must understand all the symbols in the listed set. It should also be understood that extensions to new units of measure require a change to the specification, rather than a simple extension, since the new unit of measure will break all existing applications.
A skip reference datatype be defined as follows:
<xsd:complexType name="skipRefType">
<xsd:attribute name="id" type="xsd:ID" use="required"/>
<xsd:attribute name="to" type="xsd:anyURI" use="required"/>
</xsd:complexType>
with exceptions as noted below in the comments.
Comment: The skipRefType has the property that it contains a referencable key, and references a resource, generally in another document.
Comment: The value of the id attribute is a key may be referenced by a uom attribute. The semantic meaning of the xsd:ID datatype in this definition is that it be unique within the document, and serve as a key for a uom keyref. Note that this may also be accomplished using the schema elements uniq, key, and keyref. This process is encouraged within application documents as an alternative to the above.
Comment: The to attribute is illustrative. No general agreement has been set for the attribute name. However, such agreement should a goal of using groups.
Comment: The datatype xsd:anyURI is necessary. The purpose of the skip reference is to reference an outside resource.
Comment: An example of use of the skip reference follows. This reference takes the local “ft”, and skips it to a document which contains the definition of a “foot”:
<skipRef id=”ft” to=”http://www.some.com/unitDef.xml#foot”/>
A complexType be used that defines the meaning of a unit of measure. The meaning is contained in one of two ways – either it is a base unit, or it contains a conversion to a referenced base unit. Beyond these two requirements, this recommendation does not define the information carried in such a definition or the structure of the information. Recommendations 7 and 8 define these two requirements.
Comment: The element containing the definition must have an id attribute of type xsd:ID, where the xsd:ID may be replace by xsd:string with uniq, key, and keyref definitions as appropriate. This allows the definition to referenced by a uom or to attribute.
Comment: Recommendations 6, 7, and 8 will require that a unit of measure definition have either a BaseUnit subelement or a ConversionToBaseUnit subelement.
A definition of a base unit should have a subelement, BaseUnit. The content of BaseUnit, if any, is not defined by this recommendation.
Comment: A minimal definition of a base unit would look like, for example,
<UOMDefinition id=”m”>
<BaseUnit/>
</UOMDefinition>
Additional information may be contained that would, for example, give a name for the unit (such as metre), the definition of it, how it is annotated, a citation, etc.
A definition of a unit of measure that is not a base unit would have a subelement, ConversionToBaseUnit, that is of type, conversionType, as follows:
<xsd:complexType name="conversionType">
<xsd:sequence>
<xsd:choice>
<xsd:element name="factor" type="xsd:double"/>
<xsd:element name=”fraction”>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="numerator" type="xsd:double"/>
<xsd:element name="denominator" type="xsd:double"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name=”formula”>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="A" type="xsd:double" minOccurs="0"/>
<xsd:element name="B" type="xsd:double"/>
<xsd:element name="C" type="xsd:double"/>
<xsd:element name="D" type="xsd:double" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="baseUnit" type="xsd:anyURI" use="required"/>
</xsd:complexType>
Comment: This definition maps directly to the schema that is output using the MDA rules in ISO 19118. However, it has been modified slightly from the direct output.
Comment: As given in other papers, the A, B, C, D capture the parameters in the equation:
Y = (A + B* X) / (C + D* X)
Where X is the value of the measure in the input units, and Y is the value in the base unit.
Comment: The ConversionType may be restricted by groups, and still be in compliance with Recommendation 8.