A proposal for Units representation and usage for the Virtual Observatory
Version 0.1

IVOA WG Internal Draft 2009 February

This version:


Latest version:


Previous versions:



Working Group:



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.

Status of this Document

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

·         Acknowledgments

·         Contents

·         1. Introduction

·         2. Present use of units

o    2.1 Vocabularies

o    2.2 Quantities

o    2.3 Libraries

·         3. Suggested IVOA conventions

·         4. Implementation

o    4.1 Integration

o    4.2 Model representations

·         Appendix A: ...

·         References


1. Introduction

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.

2. Present use of units

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.

2.1 Vocabularies

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.

2.2 Quantities

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) .

2.3 Libraries

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.

3. Suggested IVOA conventions for units controlled vocabulary

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.


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...

4. Implementation

4.1 Integration

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.

4.2 Model representations

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
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)


Appendix A: ...

If you have an appendix, put content here



[1] Author(s), Title