### 4 Labels and Units

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:

 Name Label Units [DATA] flux count/s [CALIB] flux-calibration J/(m**2*Ang*count) [FLUX] flux-density J/(m**2*Ang*s)

where Ang is Ångstrom to avoid a clash with A (ampere), and parentheses are to bracket units in the denominator; 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 follows.

• Fortran conventions and intrinsic functions are to be used.
• Parentheses should be placed around the input [UNITS] if an intrinsic function or arithmetic operation has been applied to the associated data.
• If a meaningless output [UNITS] arises, say due to addition or subtraction of different input [UNITS], no output [UNITS] should be created.

To clarify these rules here are some examples.

 ${1}^{st}$ input [UNITS] ${2}^{nd}$ input [UNITS] Operation Output [UNITS] ’count/s’ arithmetic with a constant ’count/s’ ’count/s’ logarithm to base 10 ’log10(count/s)’ ’count/s’ ’s’ multiplication of data ’(count/s)*(s)’ ’count/s’ ’W’ subtraction of data — ’J/(m**2*Ang*s)’ exponentiation to power of 2 ’2.**(J/(m**2*Ang*s))’
Present applications will not have the ability to interpret or parse [UNITS] objects. Until standard routines appear which do this (which will not happen soon and may never happen), applications must not attempt to do this themselves.

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:

• Consistent with the International System of Units (SI).
• Add Janskys (Jy) for flux density.

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 $\mu$, 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 $\Omega$ 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.)

Table 8: International System (SI) Nomenclature
 Physical Quantity Name of Unit Symbol for Unit length${}^{\ast }$ metre m mass${}^{\ast }$ kilogram kg time${}^{\ast }$ second s electric current${}^{\ast }$ ampere A thermodynamic${}^{\ast }$ kelvin K amount of substance${}^{\ast }$ mole mol luminous intensity${}^{\ast }$ candela cd plane angle${}^{+}$ radian rad solid angle${}^{+}$ steradian sr frequency hertz Hz energy joule J force newton N pressure pascal Pa power watt W electric charge coulomb C electric potential volt V electric resistance ohm $\Omega$ electric conductance siemens S electric capacitance farad F magnetic flux weber Wb inductance henry H magnetic flux density tesla T luminous flux lumen lm illuminance lux lx activity (of radioactive becquerel Bq source) absorbed dose (of gray Gy ionising radiation) ${}^{\ast }$ SI Base Unit ${}^{+}$ Supplementary Unit

Some of the SI quantities are rarely, if ever, used in astronomy, but are included in Table 8 for completeness.

Table 9: The more commonly appearing quantities, their SI units, and alternatives in current use
 Quantity SI Others in use and their abbreviations length m centimetre(cm), parsec(pc), astronomical unit(AU) mass kg gram(g), solar mass(Mo) time s minute(m), hour(h), day(d), year(yr), Julian date(JD) velocity m/s km/s plane angle rad degree, arcminute, arcsecond solid angle sr square degree, square arcsecond wavelength m Angstrom, micron, centimetre energy J erg force N dyne pressure Pa dyne/cm**2 density kg/m**3 g/cm**3 power W erg/s flux W/m**2 erg/(cm**2*s) luminous flux lm erg/(cm**2*s*sr), magnitude(mag) spectral-flux density Jy erg/(cm**2*s*keV), erg/(cm**2*s*Ang) surface brightness Jy/sr magnitudes/arcsecond**2 magnetic-flux density T gauss

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.