Often, data values stored in structures will be accompanied by textual labels describing what they are and what units they are represented in. Whilst this paper describes abstracted data structures, clearly the main use of the data formats is for astronomical data. Therefore, it is important that the form and content of these label and units strings conform to a definite standard, so that they are readable and unambiguous.
One important reason for consistency is so that those general-purpose applications which have more than one input data array can test for equality the units of the various associated data objects. For utility operations, like addition and subtraction, the application must warn the user if the units are different, and where an output object is being generated must drop the units altogether. In other cases it may not be possible to proceed with the processing at all.
A minor reason for a rather definite standard is that future applications (but not the present ones), may have the capability of interpreting and processing labels and units. For example, consider a hypothetical application which would calibrate an array of data by dividing into it another array containing the calibration information. The attributes of the two arrays, and the result, [FLUX] might be:
Ang is Ångstrom to avoid a clash with
A (ampere), and parentheses are to bracket units in the
J/m**2/Ang/s, for example, would be easy to misinterpret. In this case (and probably all
others), it would be impossible to predict the label to be associated with the result. However, the
units could (with some care) be determined. Towards this goal, present-day applications
should conform to the following guidelines when generating the output [UNITS] object as
To clarify these rules here are some examples.
|input [UNITS]||input [UNITS]||Operation||Output [UNITS]|
| ||arithmetic with a constant||
| ||logarithm to base 10||
| || ||multiplication of data||
| || ||subtraction of data||—|
| ||exponentiation to power of 2||
The standards for saying which units are to be used for each kind of value will probably have to be determined by a group of interested users and implementors. However, a start can be made by looking at the scheme proposed along with the FITS specification (Wells & Greisen, 1979). The FITS scheme may be summarised as follows:
The first proposal—conformity with SI — includes the standard prefixes used to scale
values by factor multiples of 1000. There is one problem here: micro- is abbreviated to
, which is not
a character available within HDS strings (see Section 3.1; the character
u should be used instead. Also, the SI
units include an
abbreviation; here, the full unit name,
ohm, should be used. Using SI units is, on the face of it, clean and
simple, and the right thing to do. However, at present, SI units are quite alien to many in the
astronomical community, and their adoption as a rigid Starlink standard would probably not be
acceptable. (There is also the complication that to distinguish the abbreviations for seconds and
siemens case-sensitive testing would be required.)
|Physical Quantity||Name of Unit||Symbol for Unit|
|amount of substance||mole||mol|
|magnetic flux density||tesla||T|
|activity (of radioactive||becquerel||Bq|
|absorbed dose (of||gray||Gy|
SI Base Unit
Some of the SI quantities are rarely, if ever, used in astronomy, but are included in Table 8 for completeness.
|Quantity||SI||Others in use and their abbreviations|
|plane angle|| ||
|solid angle|| ||
|luminous flux|| ||
|spectral-flux density|| ||
|surface brightness|| ||
|magnetic-flux density|| ||
Within the literature there is liberal misuse of the terms intensity, flux and flux density. For example,
“flux” is frequently used where “flux density” is the correct term. Table 9 shows the diversity of units
currently employed, and the duplication of abbreviations, e.g.
m both for minute and metre. Starlink’s
current recommendation is to use SI units; if this is unacceptable, the names or abbreviations used
must be unambiguous.