|
UnitsML is a standard for non-ambiguously describing physical quantities, dimensions, and units and providing a framework for deriving and describing units and dimensions starting from the standard ISO-31 compliant set. This work was first initiated by members of NIST, and then moved to the auspices of the OASIS (Organization for the Advancement of Structured Information Standards) UnitsML technical committee. The motivation behind the work was gained through experience that highlighted the issues involved when humans meet computers. To humans, specifically scientists and engineers, quantities and units are second nature - for computers, not so. There have been many instances where humans would introduce quantities that would be misinterpreted by computer applications (e.g., Mars Climate Orbiter and Star Wars - come to our briefing to hear some details). To make the notion of physical quantities, dimensions, and units more appropriate for computer interpretation, the UnitsML work defines these concepts as THINGS, not types. By being things, computers can more effectively ensure that two things are really the same and if not, more readily convert from one to the other. This notion is implemented by using a database to define quantities, dimensions, and units, and then using XML instance documents that conform to a standard schema to render this information for external use. The following example highlights the relationships between quantities, dimensions, and units. The example shows the description of a single dimension, called "LengthDim." It further defines two distinct quantities of dimension "LengthDim," namely "distance" and "placement." The "distance" quantity is, by definition, always positive. It is defined as the measure between two points. The "placement" quantity has direction, often within the context of a coordinate system, and so can be negative. These two quantities may both be examples of the "LengthDim" dimension, but measures of one cannot be properly compared with measures of the other. The units, "inch," however, can be used for both. Also, the information described in the database provides mathematical equations for converting among units (shown), for deriving new dimensions (not shown), etc. <unitsml:Dimension xml:id="LengthDim"> <unitsml:Length powerNumerator="1" symbol="L"/> </unitsml:Dimension> <unitsml:Quantity dimensionURL="#LengthDim" quantityType="base" xml:id="OMqL1"> <unitsml:QuantityName xml:lang="en-US">distance</unitsml:QuantityName> <unitsml:UnitReference xml:lang="en-US" name="meter" url="#Distance-m" /> <unitsml:UnitReference xml:lang="en-US" name="inch" url="#Distance-in" /> ... </unitsml:Quantity> <unitsml:Quantity dimensionURL="#LengthDim" quantityType="base" xml:id="OMqL2"> <unitsml:QuantityName xml:lang="en-US">placement</unitsml:QuantityName> <unitsml:UnitReference xml:lang="en-US" name="meter" url="#Distance-m" /> <unitsml:UnitReference xml:lang="en-US" name="inch" url="#Distance-in" /> ... </unitsml:Quantity> <unitsml:Unit xml:id="Distance-in" dimensionURL="#LengthDim"> <unitsml:UnitName>inch</unitsml:UnitName> <unitsml:Conversions> <unitsml:Float64ConversionFrom initialUnit="#Distance-m" exact="true" divisor="0.0254" xml:id="OMc1.3"/> </unitsml:Conversions> <unitsml:QuantityReference xml:lang="en-US" name="distance" url="#OMqD1"/> <unitsml:QuantityReference xml:lang="en-US" name="placement" url="#OMqD2"/> </unitsml:Unit>
At this time, the UnitsML team is trying to finalize a first version of the schema. This version assumes that science labs and businesses will either use standard definitions administered through a NIST database or define stand-alone versions of their own databases. We are working with them to ensure that version 1 has sufficient description for supporting our efforts involved in modeling mailing system capabilities and carrier product descriptions, e.g., they have added bit and byte as bona-fide units within the version 1 standard. We are also interacting with them for a version 2 upgrade that would allow data across databases to be cross-linked so that those of us who know less about official units standards can leverage the work of those who know more.
Deborra Zukowski October 23, 2009
|