This version:
http://www.ivoa.net/Documents/...
Latest version:
http://www.ivoa.net/Documents/latest/...
Previous versions:
http://www.ivoa.net/Documents/...
http://www.ivoa.net/Documents/...
Working Group:
http://www.ivoa.net/twiki/bin/view/IVOA/IvoaDataModel
Author(s):
Anita
Richards
Mireille
Louys
Francois
Bonnarel
Sebastien
Derriere
Jesus
Salgardo
Pedro
Osuna
Bruno
Rino
This document is meant to record the general practice in manipulating units for astronomical metadata and define a means of consistent representation within VO services.
This is a Working Draft. The first WG internal release of this document , after a first draft initiated in 2008 October.
Working
Draft
This is an IVOA Working Draft for review by IVOA
members and other interested parties.
It is a draft document and
may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use IVOA Working Drafts as reference
materials or to cite them as other than "work in progress.
A list of current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.
We thank Paddy Leahy, Arnold Rots, Mark Taylor, Brian Thomas ... for contributing comments, use cases and examples of usage.
· Abstract
· Status
· Contents
· 3. Suggested IVOA conventions
Generally every quantity provided in astronomy has a unit attached to its value or is unitless.
The VO and its users employ units:
· in IVOA protocols, while exchanging XML documents, in various formats (VOTable, xml)
· in applications
· in queries
The life cycle of units in the VO in particular , can be described in the following graph (fig. 1):
|
Fig: 1 this diagram is intended to exemplify processes which uses units. Assuming that the VO itself is internally consistent the arrows show all stages where translation or interpretation of units might be needed. |
We have to decide where and how and what tools to use.
The need for a Units model and a Units controlled vocabulary has arisen from several needs exemplified below:
1. To understand m, meter, metre ... as the same thing
2. To differentiate between mm (milli-metre) and m.m (m2)
3. To distinguish between the use of m as a wavelength (= c/frequency) and m as a distance e.g. 1 AU = 1.499 1011 m
4. To create combinations of units intelligently e.g. J.s-1 = W
5. To translate between SI prefixes (G, M, k etc.) intelligently
It is not the role of this workpackage to provide a means of converting instrument-related units such as magnitudes, nor to perform coordinate conversions. The former is the domain of the PhotometryDataModel to be issued in a separate Data Model effort ( http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/PhotometryDataModel ); excellent libraries e.g. AST in C, or SLABIB for Java, already exist for the latter.
It is our role to meet the needs of these work packages and provide consistency.
The necessity to come to a controlled usage of string representations for units has arisen in different previous projects. This lead to many initiatives as listed below. The selected examples are reasonably consistent. At this stage we will not consider further representations which are only suitable for use in human-readable literature, e.g. many IAU symbols using Greek letters etc. The other systems are (mostly) machine readable.
1. Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units (Derrière)
2. Standards for Astronomical Catalogues, Version 2.0
3. Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado) offers a mathematical framework to guess and recompute SI units for any quantity in astronomy.
4. Unit strings allowed in STC (Rots)
5. NIST (National Institute of Standards & Technology) project UnitsXML builds up an XML representation of units at the granularity level of a simple symbol string.
6. FITS standards: Reference, Development, Specification of Physical Units within OGIP FITS files (Greisen and Calabretta 2002, A&A 395, 1061)
7. Java JSR-275 specifies one or more Java packages for the programmatic handling of physical quantities and their expression as numbers of units.
This is an attempt to clarify the relationship
between quantities and units:
A quantity, e.g. a measurement of a
physical value like the speed of light, has a value (2.998 10+5), a
ucd (phys.veloc), units (km.s-1) and a is coded using a numerical
type (real).
Some quantities are also reused as units. Many units are expressed, or converted, in terms of physical constants such as the speed of light, c = 2.998 10+8 m.s-1 ; Boltzman's constant, 1.38065 10-23 kg.m+2.s-2.K-1 ; the AU (1.499 10+11 m). Many of these are used as units in their own right, e.g. velocities may be expressed as a fraction or multiple of c, but c is also used to convert between wavelength and frequency, etc. These are combinations of units with scaling factors applied, and so can be treated in the same way as any other compound unit e.g. Jy (10-26 W.m-2.Hz-1) .
Some of the links in Vocabularies e.g. for Java, contain libraries. One of the most widely-used specialised astronomical libraries is AST which includes a units’ conversion facility attached to astronomical coordinate systems.
These are standards we suggest to be used internally within the VO. We need to provide translation to/from other usages as far as is required/practical.
%These are examples of the decisions we need, not necessarily the exact form to be adopted, experts please comment.
1. We use SI (not cgs etc.)
2. We allow European or US spelling (metre or meter) - if this is ever needed
3. m as wavelength is distinguished from m as length by providing different UCDs
4. SI prefixes directly precede a unit, no space should be used, e.g. mT = milli-Tesla, Tm = Tera-metre
5. Compound units are formed using the dot character '.' as a separator, without spaces, e.g. N.m = Newton metre
o Specific cases should be considered: beware e.g. MJD which is not Mega Julian Day but Modified Julian Day. Therefore, interpreters will have to first check whether the unit label matches a known unit, and only if not, strip of the first character, check if that matches an SI prefix and the remainder a unit string.
6. Powers are indicated by + or - e.g. m+2 = metre x metre, m.s-1 = m/s
o If we allow fractional powers in unit conversions e.g. m+1/5, this could be confused with m + 1/5, unless we can avoid such operations.
IVOA should provide (hopefully mostly via existing
libraries etc.) tools for converting between recognised units and SI
multiples, e.g.
10 J x 1 s-1 = 10 J.s-1 = 10 W
0 degC = 273 K
on the contrary, uses a different mapping of temperature coordinates
from Celsius to Kelvin degrees and therefore relies to coordinates
conversion.
%comments
Issue: How much belongs in the unit definition, and how much in the conversion library? e.g. are degC and K indistinguishable apart from the label, which is recognized by the library, or should degC have the offset from the fundamental SI unit in its definition? That might be easy for linear offsets in single-valued units, but gets messy for time, celestial position etc...
This now shows the levels at which conversions
might be done.
Thick
red arrows: At the point where an astronomer or data provider submits
input to the VO, we should provide tools to ensure that units are
labeled consistently (e.g. mm for millimeter; m+2 or m.m for m2;
SI prefixes, or whatever is adopted). This
implies that a units parsing step is included prior to matadata
ingestion into the VO.
Dashed
brown arrows: More complex conversions e.g. AU s-1 to m s-1 are done
where and when they are required.
%comments mireille : what is the red arrow between 'AppsPublishers' and 'Application representing' ??? in my understanding the “Apps Publisher” provides the application code and knows which units are required by this application... Probably I misunderstood.
How do we implement the first stage when dealing with input, i.e. converting to a standard vocabulary (prior to any interpretation of units), e.g. meter = metre = m, mm = milli-metre, m*m = m.m = m+2 .
Backus Naur format (as used e.g. for ADQL) provides
cross-references to define terms, e.g.
Jy = 10-26 W m-2 Hz-1
W
= J.s-1
...
Jy = 10-26 kg.m+2.s-2.s-1.m-2.s
Dimensional analysis provides a means of converting between units with appropriate scaling factors, for relationships between quantities in different units; e.g. between (flux density in Jy v. wavelength) and flux density in erg s-1 cm-2 A-1 v. wavelength).
An equivalent(?) method using UCDs (**UML diagram or reference). e.g. convert m (wavelength) to Hz (frequency) and convert m (distance) to Mpc (distance).
Test case: can both methods cope
with
cosmological_distance = c.z.H0-1
where
z = (lambda_obs
- lambda_rest)/lambda_rest i.e. dimensionless (but might itself be
calculated as part of a VO workflow - note that this is only one
possible definition, see STC...)
Hubble constant H0 = 65
km.s-1.Mpc-1 (or nearest offer)
If you have an appendix, put content here
[1] Author(s), Title
http://
