UCD Draft (18Jun2003)

UCD (Unified Content Descriptor) Overview
Andrea Preite-Martinez, Sébastien Derrière, François Ochsenbein
Draft Version (18 June 2003) Following the Cambridge meeting, the present document tries to focus on a revised scheme of the UCDs to improve its readilibity, and reach some consensus in its usage for the Virtual Observatory.

Contents:

UCD Syntax
Specifiers
The UCD basic tree
Suggestions and Open Issues

Appendix:

Some elements of the UCD basic.tree
Organisation of the wavelength spectrum

1 UCD Syntax

The generic syntax proposed for a UCD is:

[namespace:]basic.tree[,specifier]

namespace is optional and should be used in rare circumstances (e.g. internal / temporary usage) in order to ensure interoperability.
basic.tree represents an organized knowledge tree defined to some ``reasonable'' granularity level sketched below. The allowed character set used in the basic.tree includes the alphabetic letters (upper- and lower-case) and the dash (minus sign); the period (dot) is used as a ``glue'' between the words as in e.g. src.extension.area. It is proposed to use mixed cases for readability in the UCD list (e.g. write absCoeff), but the case is not meaningful (i.e. absCoeff abscoeff AbsCOEFF have all exactly the same meaning)
specifier is optional and represents one (or more?) precision terms which can be associated to any of the basic.tree terms, like error or relative; the proposed list of terms is detailed below.

2 Specifiers

Specifiers or precision terms are assigned two roles:

qualifiers do not change the physical meaning of the basic UCD, i.e. a modified UCD can still be compared to the non-modified UCD. Examples of qualifiers are: main or max
modifiers do change the physical meaning. Examples of modifiers are: flag or ref

The proposed list of qualifiers(q) and modifiers(m) is:

(m) diff difference or amplitude between two quantities of same type, e.g. observed value minus theoretical value

(m) error mean or standard error on some parameter

(m) flag flag/code on parameter.
A flag is generally understood as a warning on the associated quantity. The rule proposed is that a blank or zero value of a flag means ``no warning'', i.e. the associated quantity (or row) can be considered as ``reliable'' (in the context of the current data).
The flags could be more accurately qualified, see the note on flags below.

(m) ID identification or name of parameter

(q) main main instance of parameter: it means that, when similar parameter are present, the qualified one is suggested as the best choice.

(q) max parameter is a maximum value or upper limit

(q) min parameter is a minimum value or lower limit

(m) note note or remark associated to parameter

(m) count cardinal number associated to a parameter (e.g. counts or number of measurements). Could be replaced by weight ?

(m) qual quality flag, class or index associated to a parameter. (see note on quality scale)

(m) ratio relative or normalized result.

(m) ref reference (source), or more generally origin (e.g. used instrumentation) of a parameter

(m) type characterisation or classification of some parameter.

(m) unit unit in which the associated parameter is expressed.

(m) weight weight of parameter -- which has a meaning close to qual, see the note below

Notes on the list of specifiers:

VizieR defined ``specialized'' flags related to uncertainty (like the colon `:' commonly used to designate especially inaccurate data), and limit specifications (the < > symbols indicating that the data represent upper or lower limits). It could be useful to introduce a limFlag modifier, and maybe a varFlag modifier as a variability indicator.
There is no general consensus on quality scales -- some authors consider that 1 or A is the top quality, and other that 1 is very poor. It is in practice important to make a distinction between these opposite scales, and weight could be used to define an increasing quality scale, while qual would be reserved for decreasing quality scales.

3 The UCD basic tree

The revised UCD tree tries to incorporate some of the suggestions found in the discussion list. The list enclosed here proposes the basic elements only, and does not detail each node.

The level#0 branches of the proposed basic.tree are:

data quantities related to data, catalogues, global metadata, bibliography,..

instr quantities related to an instrument; typical sub-levels are telescope, detector, filter, plate, spectrograph, etc...

model parameters and results of a model

obs properties of the observation, typically exposure time

obsty properties of the observatory, includes telescope, site... (is it worth keeping it, or move to instr?)

phot All photometric measurements, basically organized according to the wavelength

phys all physical quantities, including atomic & molecular data, temperature, pressure, gravity, etc...

pos all angular (and 3-D?) positional quantities

spec quantities related to spectroscopic measurements

src properties of the observed source of radiation: class, extension, variability, velocity...

stat statistical quantities, e.g. related to model fitting.

The new tree was simplified compared to the current UCD tree; important modifications include:

atomic and molecular data are moved to a branch of phys
fitting data are moved to a branch of model
the src branch is introduced

More details about some of the most important branches are shown in the annex below.

4 Suggestions and Open Issues

There are a few points we have faced when trying to describe the existing columns with the new UCD scheme. We are listing these points here, together with a few more questions that, we think, should be answered before submitting a draft to the discussion forum.

the new UCD scheme does not keep the concept of `node' and `leaves': UCDs at any level can be used to describe some parameter, whether sub-levels are existing or not. This rule implies that we do not use a qualifier like misc or gen: if a quantity is not accurately defined, we just use the `parent' UCD.
the elements of the basic.tree make use of a standard vocabulary, in the sense that a single word is used in the basic.tree to designate a physical concept or quantity. For instance, if electron is used to designate any electron-related quantity, we write e.g. phys.temp.electron to designate the electronic temperature and not an abbreviation like phys.temp.el; conversely, electron keeps the same meaning among all UCDs. We should try to maintain a list of these meanings -- we are for instance using temp=temperature, phys=physical, ...
modifiers and qualifiers are reserved words, and must not be used as components of the basic.tree. For instance, error being a modifier should not be used in a UCD like src.error.param
Do we allow for aliases?
The `standard' UCD list makes use of a restricted vocabulary, but it could be possible to accept synonyms (aliases). For instance ratio and normalized could be considered as synonym modifiers -- or phot.flux.IR.100-200um could be a synonym to phot.flux.radio.1500-3000GHz.
Do we need the full description?
Full UCDs can become rather long, and it could be envisaged to omit some of the intermediate words when there is no ambiguity. For instance in phot.flux.radio.3-6GHz the 'radio' could be omitted without any loss of information.
Do we need a special character (the comma) before the specifier?
The preceding rule of reserved words implies that no confusion is possible between a specifier and an element of the basic.tree -- and a special punctuation character is therefore not required to separate the two entities. This would by the way enable the usage of the comma as a natural separator in lists of UCDs.
Can we have a UCD made of a specifier only ?
A typical example would be a flag which applies on all columns of a table -- how could we characterize this flag ? The rule of reserved words would alleviate any ambiguity whether the UCD is a specifier or not.
Can we combine several specifiers?
A typical example is the upper bound of an error to a quantity: it seems natural to associate to the quantity the max and error specifiers as quantity,max,error (or quantity.max.error if we accept the no-comma rule above) -- but this UCD could be understood as error on max value of quantity as well as max error on quantity. The order of the terms is therefore fundamental, and a precedence rule has to be defined: if a specifier applies to the left terms only, quantity,max,error would mean error on the maximal quantity, while quantity,error,max would mean maximal value of the error on quantity
Can specifiers become complex ?
A typical application would be the ``specialisation'' of flags mentioned on item 1: a flag could be declined into flag.limit, flag.uncert, etc... This would in fact be an alternative to precedence rule sketched above, but would require to keep a special character to separate the basic.tree from the specifiers.

Notice that some of the proposals are incompatible: if we accept the no-comma rule (item 6), it becomes difficult to accept complex specifiers (item 9).

A Some elements of the UCD basic.tree

The table below contains just a few elements of the revised UCD tree; a fully qualified tree will be prepared as the result of discussions and exchanges. Notice that any of the elements may be qualified or modified by one (or more?) of the specifiers described above, e.g. phys.temp,type or phys.temp,flag.

phys (physical quantities)

phys.at All atomic data, e.g. phys.at.Stark about Stark broadening, phys.at.trans.prob for transition probabilities, etc

phys.mol All molecular data

phys.temp Temperatures (effective, electronic, etc...)

pos (positional data)

pos.ang Angular Distance and related quantities

pos.ecl Position in Ecliptic frame (angular and non-angular?)

pos.eq Position in Equatorial frame (angular)

pos.gal Position in Galactic frame (angular and non-angular?)

pos.geo Position in Geocentric frame (angular and non-angular?)

pos.sg Position in Supergalactic frame (angular and non-angular?)

pos.planet Position in Planetary (e.g Jovian) frame (angular and non-angular?)

pos.parlx Parallax data

pos.pm Proper motion quantities

src (quantities that are a property of a source)

src.class Various Classification Descriptors of source (type, class, codes, ...)

src.extension Angular extension, diameter or size of a source or object

src.morph parameters describing the morphology of a source

src.SpType spectral classification of a source

src.var parameters describing the variability of a source

src.veloc parameters describing the velocity of a source

phot (quantities measuring the energy received from a source)

phot.flux measure of a flux -- which can be expressed in energy units, magnitudes, or photon counts
Photometric data are further organized according to the position in the electromagnetic spectrum (see below)

phot.colorIndex includes photometric ratios
(or should these values be considered just as modified by ratio?)

spec (quantities measuring the wavelength/frequency of photons received)

spec.cont continuum quantities

spec.index spectral index G in the sense
F(v) prop.to. v^G

spec.-index spectral index G in the sense
F(v) prop.to. v^-G

spec.line line properties, e.g. spec.line.eqwidth or spec.line.veloc

B Organisation of the wavelength spectrum

The wavelength spectrum is first divided in the 7 classical domains radio / IR / Optical / UV / EUV / X-ray / gamma. Further divisions are made to define the large bands classically used in optical / IR / UV, and in radio frequencies we keep bands spaced by a factor 2. The overall wavelength domains is the following:

UCD designation Lambda Freq Energy Notes

Radio Regime

phot.flux.radio.20-100MHz >3m <100MHz

phot.flux.radio.100-200MHz 1.5-3m 100-200MHz

phot.flux.radio.200-400MHz 75-150cm 200-400MHz

phot.flux.radio.400-750MHz 40-75cm 400-750MHz

phot.flux.radio.750-1500MHz 20-40cm 750-1500MHz

phot.flux.radio.1500-3000MHz 10-20cm 1.5-3GHz

phot.flux.radio.3-6GHz 5-10cm 3-6GHz

phot.flux.radio.6-12GHz 2.5-5cm 6-12GHz

phot.flux.radio.12-25GHz 1.2-2.5cm 12-25GHz

phot.flux.radio.25-50GHz 6-12mm 25-50GHz

phot.flux.radio.50-100GHz 3-6mm 50-100GHz

phot.flux.radio.100-200GHz 1.5-3mm 100-200GHz

phot.flux.radio.200-400GHz 750-1500µm 200-400GHz

phot.flux.radio.400-750GHz 400-750µm 400-750GHz

phot.flux.radio.750-1500GHz 200-400µm 750-1500GHz COBE 240µm

phot.flux.radio.1500-3000GHz 100-200µm 1500-3000GHz COBE 140µm

Infra-Red Regime

phot.flux.IR.60-100um 60-100µm 3-5THz IRAS 100µm

phot.flux.IR.30-60um 30-60µm 5-10THz IRAS 60µm

phot.flux.IR.15-30um 15-30µm 10-20THz IRAS 25µm

phot.flux.IR.8-15um 8-15µm 20-37.5THz N band; IRAS 12µm

phot.flux.IR.4-8um 4-8µm 37.5-75THz M band; Br{alpha}=4051nm

phot.flux.IR.3-4um 3-4µm 100-150THz L, L', L''

phot.flux.IR.K 2-3µm 75-100THz K band

phot.flux.IR.H 1.5-2.0µm 200-300THz H band; Pa{alpha}=1875nm, Br{Limit}=1731nm

phot.flux.IR.J 1.0-1.5µm 150-200THz J band;

Optical Regime

phot.flux.opt.I 750-1000nm 300-400THz 1.2-1.6eV I band; Pa{Limit}=820nm

phot.flux.opt.R 600-750nm 400-500THz 1.6-2.0eV R band; Halpha=656nm

phot.flux.opt.V 500-600nm 500-600THz 2.0-2.4eV V band;

phot.flux.opt.B 400-500nm 600-750THz 2.4-3.0eV B band; H{beta}=486nm, H{gamma}=434nm, H{delta}=410nm

phot.flux.opt.U 300-400nm 750-1000THz 3.0-4.0eV U band; BaJump=365nm

Ultra-Violet Regime

phot.flux.UV.200-300nm 200-300nm 1000-1500THz 4-6eV UV1 band

phot.flux.UV.100-200nm 100-200nm 1500-3000THz 6-12eV UV2 band; Ly{alpha}=121.6nm

Extreme Ultra-Violet Regime

phot.flux.EUV.50-100nm 50-100nm 3-6PHz 12-24eV Ly{Limit}=91.2nm

phot.flux.EUV.10-50nm 10-50nm 6-30PHz 24-120eV

X-ray Regime

phot.flux.X-ray.soft 6-100Å 30-500PHz 0.12-2keV

phot.flux.X-ray.hard 0.1-6Å 0.5-30EHz 2-12keV

{gamma}-ray

phot.flux.gamma.soft 0.25-10pm 30-1200EHz 12-500keV

phot.flux.gamma.hard <250fm > 1200EHz >500keV e+/e-

Andrea Preite-Martinez andrea@rm.iasf.cnr.it

Sébastien Derrière derriere@astro.u-strasbg.fr

François Ochsenbein francois@astro.u-strasbg.fr

(m)	diff	difference or amplitude between two quantities of same type, e.g. observed value minus theoretical value
(m)	error	mean or standard error on some parameter
(m)	flag	flag/code on parameter. A flag is generally understood as a warning on the associated quantity. The rule proposed is that a blank or zero value of a flag means ``no warning'', i.e. the associated quantity (or row) can be considered as ``reliable'' (in the context of the current data). The flags could be more accurately qualified, see the note on flags below.
(m)	ID	identification or name of parameter
(q)	main	main instance of parameter: it means that, when similar parameter are present, the qualified one is suggested as the best choice.
(q)	max	parameter is a maximum value or upper limit
(q)	min	parameter is a minimum value or lower limit
(m)	note	note or remark associated to parameter
(m)	count	cardinal number associated to a parameter (e.g. counts or number of measurements). Could be replaced by weight ?
(m)	qual	quality flag, class or index associated to a parameter. (see note on quality scale)
(m)	ratio	relative or normalized result.
(m)	ref	reference (source), or more generally origin (e.g. used instrumentation) of a parameter
(m)	type	characterisation or classification of some parameter.
(m)	unit	unit in which the associated parameter is expressed.
(m)	weight	weight of parameter -- which has a meaning close to qual, see the note below

data	quantities related to data, catalogues, global metadata, bibliography,..
instr	quantities related to an instrument; typical sub-levels are telescope, detector, filter, plate, spectrograph, etc...
model	parameters and results of a model
obs	properties of the observation, typically exposure time
obsty	properties of the observatory, includes telescope, site... (is it worth keeping it, or move to instr?)
phot	All photometric measurements, basically organized according to the wavelength
phys	all physical quantities, including atomic & molecular data, temperature, pressure, gravity, etc...
pos	all angular (and 3-D?) positional quantities
spec	quantities related to spectroscopic measurements
src	properties of the observed source of radiation: class, extension, variability, velocity...
stat	statistical quantities, e.g. related to model fitting.

phys (physical quantities)
phys.at	All atomic data, e.g. phys.at.Stark about Stark broadening, phys.at.trans.prob for transition probabilities, etc
phys.mol	All molecular data
phys.temp	Temperatures (effective, electronic, etc...)
pos (positional data)
pos.ang	Angular Distance and related quantities
pos.ecl	Position in Ecliptic frame (angular and non-angular?)
pos.eq	Position in Equatorial frame (angular)
pos.gal	Position in Galactic frame (angular and non-angular?)
pos.geo	Position in Geocentric frame (angular and non-angular?)
pos.sg	Position in Supergalactic frame (angular and non-angular?)
pos.planet	Position in Planetary (e.g Jovian) frame (angular and non-angular?)
pos.parlx	Parallax data
pos.pm	Proper motion quantities
src (quantities that are a property of a source)
src.class	Various Classification Descriptors of source (type, class, codes, ...)
src.extension	Angular extension, diameter or size of a source or object
src.morph	parameters describing the morphology of a source
src.SpType	spectral classification of a source
src.var	parameters describing the variability of a source
src.veloc	parameters describing the velocity of a source
phot (quantities measuring the energy received from a source)
phot.flux	measure of a flux -- which can be expressed in energy units, magnitudes, or photon counts Photometric data are further organized according to the position in the electromagnetic spectrum (see below)
phot.colorIndex	includes photometric ratios (or should these values be considered just as modified by ratio?)
spec (quantities measuring the wavelength/frequency of photons received)
spec.cont	continuum quantities
spec.index	spectral index G in the sense F(v) prop.to. v^G
spec.-index	spectral index G in the sense F(v) prop.to. v^-G
spec.line	line properties, e.g. spec.line.eqwidth or spec.line.veloc

UCD designation	Lambda	Freq	Energy	Notes
Radio Regime
phot.flux.radio.20-100MHz	>3m	<100MHz
phot.flux.radio.100-200MHz	1.5-3m	100-200MHz
phot.flux.radio.200-400MHz	75-150cm	200-400MHz
phot.flux.radio.400-750MHz	40-75cm	400-750MHz
phot.flux.radio.750-1500MHz	20-40cm	750-1500MHz
phot.flux.radio.1500-3000MHz	10-20cm	1.5-3GHz
phot.flux.radio.3-6GHz	5-10cm	3-6GHz
phot.flux.radio.6-12GHz	2.5-5cm	6-12GHz
phot.flux.radio.12-25GHz	1.2-2.5cm	12-25GHz
phot.flux.radio.25-50GHz	6-12mm	25-50GHz
phot.flux.radio.50-100GHz	3-6mm	50-100GHz
phot.flux.radio.100-200GHz	1.5-3mm	100-200GHz
phot.flux.radio.200-400GHz	750-1500µm	200-400GHz
phot.flux.radio.400-750GHz	400-750µm	400-750GHz
phot.flux.radio.750-1500GHz	200-400µm	750-1500GHz		COBE 240µm
phot.flux.radio.1500-3000GHz	100-200µm	1500-3000GHz		COBE 140µm
Infra-Red Regime
phot.flux.IR.60-100um	60-100µm	3-5THz		IRAS 100µm
phot.flux.IR.30-60um	30-60µm	5-10THz		IRAS 60µm
phot.flux.IR.15-30um	15-30µm	10-20THz		IRAS 25µm
phot.flux.IR.8-15um	8-15µm	20-37.5THz		N band; IRAS 12µm
phot.flux.IR.4-8um	4-8µm	37.5-75THz		M band; Br{alpha}=4051nm
phot.flux.IR.3-4um	3-4µm	100-150THz		L, L', L''
phot.flux.IR.K	2-3µm	75-100THz		K band
phot.flux.IR.H	1.5-2.0µm	200-300THz		H band; Pa{alpha}=1875nm, Br{Limit}=1731nm
phot.flux.IR.J	1.0-1.5µm	150-200THz		J band;
Optical Regime
phot.flux.opt.I	750-1000nm	300-400THz	1.2-1.6eV	I band; Pa{Limit}=820nm
phot.flux.opt.R	600-750nm	400-500THz	1.6-2.0eV	R band; Halpha=656nm
phot.flux.opt.V	500-600nm	500-600THz	2.0-2.4eV	V band;
phot.flux.opt.B	400-500nm	600-750THz	2.4-3.0eV	B band; H{beta}=486nm, H{gamma}=434nm, H{delta}=410nm
phot.flux.opt.U	300-400nm	750-1000THz	3.0-4.0eV	U band; BaJump=365nm
Ultra-Violet Regime
phot.flux.UV.200-300nm	200-300nm	1000-1500THz	4-6eV	UV1 band
phot.flux.UV.100-200nm	100-200nm	1500-3000THz	6-12eV	UV2 band; Ly{alpha}=121.6nm
Extreme Ultra-Violet Regime
phot.flux.EUV.50-100nm	50-100nm	3-6PHz	12-24eV	Ly{Limit}=91.2nm
phot.flux.EUV.10-50nm	10-50nm	6-30PHz	24-120eV
X-ray Regime
phot.flux.X-ray.soft	6-100Å	30-500PHz	0.12-2keV
phot.flux.X-ray.hard	0.1-6Å	0.5-30EHz	2-12keV
{gamma}-ray
phot.flux.gamma.soft	0.25-10pm	30-1200EHz	12-500keV
phot.flux.gamma.hard	<250fm	> 1200EHz	>500keV	e+/e-

Andrea Preite-Martinez	andrea@rm.iasf.cnr.it
Sébastien Derrière	derriere@astro.u-strasbg.fr
François Ochsenbein	francois@astro.u-strasbg.fr