What are UCDs for?

This was written before Guy's UCDAtomsPreliminaryList appeared, so my choice of the main (leftmost) atoms (nouns in Guy's terminology), are different, but the instances I give are not meant to be definative, it is the structures that matter.

In examples I have retained the _ to link related components of a UCD since this helps reading even if it would not be used in the atomic version. _UCD indicates a partial UCD.

UCDs at present should

1. Aid query
   1. By selection of catalogues
   2. By querying values in selected columns within catalogues
   3. By querying keywords if catalogue uses correct conventions
   4. And eventually cover catalogue headers too

2. Help humans understand column headings
   1. By a logical structure of the UCD tree (e.g. grouping measured source properties separately from instrument properties)
   2. Eventually by the use of atoms and the possibility of searching on part-UCDs.
3. Set standards
   1. For current adoption of UCDs
   2. For eventual more complex VO queries performing operations on combinations of values extracted from UCDs

4. It would be desirable if, when evaluting UCDs,
   1. Unit conversions could be performed, e.g. YYYMMDD hh mm ss.s to JD.xxx
   2. Separate UCDs in the same (or specified related) catalogues could be correlated where necessary, e.g. to use OBS_FREQ and MAP_FLUX_PEAK rather than _FLUX_1.6G etc.
   3. UCD values could be interpreted and converted where the units are related to the values of other UCDs in the same (or specified related) catalogues e.g. _STOKES_Q as a percentage of _STOKES_I converted to Jy/beam and v.v. or MAP_FLUX_PEAK in Jy/beam could be converted to Jy/arcsec (or even Jy/pixel) if MAP_BMAJ/BMIN (and PIX) are given.
5. Atomic UCDs will be useful if:
   1. They can be combined for searches using logical operators (&&, not, or, nor...) and wildcards;
   2. Which may be simplified if the order of atoms in a search string is signficant;
   3. Which requires that partial UCDs are built from the most significant atom down. At present you have TIME_DATE for observing time and TIME_PERIOD for an e.g. pulsar period, I suggest OBS_TIME_DATE or OBS_TIME_DATE_START/_END would all be valid for the observing time depending on the amount of information, and TIME_PERIOD would be in a separate group.
   4. The user query is posed in UCDs (which means a user-friendly presentation) - or via a controlled vocabulary (pull-down menus? I hate ones with more than one level or a few choices...) or ultimately the AQL...

Guidelines for defining and combining atoms.

Properies related to insruments, observations and direct output (maps, spectra etc) have the first atom INST_, OBS_, MAP_ etc; deduced source properties have the most significant property first (since in some catalogues it might not be obvious from the column name where a value comes from). Hence in the example in 5.3) it would be possible to search for properties of instruments or observations (time resolution, observing epoch etc) using ?*_TIME_* and for properties related to variable sources using TIME_*; TIME would produce everything.

In this example, OBS_TIME would have both direct instances (where only one value was given) and subclasses (OBS_TIME_START/END) - is this OK?

If we assume that a query can require evaluating UCDs as per 4). then if e.g. OBS_FREQ is defined, MAP_FLUX_PEAK is adequate. In fact if the query machine can distinguish between units of Jy, J etc. and magnitudes, then just MAP_PEAK would do? With _1, _2 etc if required for multiple peaks in one map. Such UCDs would be found in observation-based catalogues (linked to observatory log etc). In that case, PHOT_FLUX_ or PHOT_PEAK_ or PHOT_JHN_ etc. would be found in object-based catalogues.

-- AnitaRichards - 08 Oct 2002