An IVOA standard for Unified Content Descriptors
Version 1.1

The idea of building UCDs by combining simple words makes the vocabulary less complex and more flexible (cf. ``atomic UCDs'' proposal by G. Rixon). The two questions that immediately arise are:

1. How do we define the simple words ?
2. How do we combine them to build fully-qualified UCDs ?

3.2  Defining simple words

There is no definitive answer to the first question, because selecting some terms for inclusion in the vocabulary and rejecting other terms is necessarily subjective. The only possible validation of the selected vocabulary is to check its ability to describe properly a wide range of real data.

There are two caveats for the definition of the list of words:

• The words must not be too simple/ambiguous (or we have the same inconveniences as natural language);
• The words must not be too specific (or we come back to the UCD1 drawbacks).

3.3  Combining simple words

Our guideline for UCD1+ is that, while it is possible to build a UCD as a combination of several simple words, the primary word carries most of the meaning as to ``what the quantity is''. After the primary word, subsequent words are arranged by decreasing importance (see section 3.4 for some examples on ordering the words).

In the proposed scheme, UCD are built by adding words from left to right, with each new word specifying/qualifying the combination to its left. The most important words when comparing two UCDs are the first ones (see appendix B) .

People or software who don't want to manage composed UCD can use only the first word of the composed UCD (called primary word). This word must give a first order description of the quantity that is being described. It can be used as UCD1, with the only change that the underscore (_) is to be replaced by a period (.) in the parsing (cf. section 2 for syntax of UCD1+).

Example: Consider a table containing 3 columns:

• A magnitude;
• A flag on this magnitude.
• An error on this magnitude;

We suggest that the primary word for the first column should be phot.mag: the contents of this column is a number, and the semantic meaning of this column is well described by the word phot.mag (whose definition is photometric magnitude).

The contents of the second column is a flag (often it is a symbol, like a, b or * that indicates, e.g. bad weather, unreliable values, ...). Therefore, the primary word should be meta.code (which means code or flag), because what is really described here is indeed a flag. The complete UCD could be written meta.code;phot.mag, to indicate that this flag applies to a magnitude. A simple parser could keep only the primary word of this UCD, and still have a reliable description of what it is. It could also ignore the order of all secondary words.

The contents of the third column is an uncertainty, a measurement error. It can be expressed in magnitudes, but it is not a magnitude, so it is not correct to use phot.mag as primary word. One should use instead stat.error as the primary word, because the definition of this word corresponds precisely to the contents of the column. The complete UCD could be written stat.error;phot.mag, to indicate that this error applies to a magnitude.

One could argue that these three columns are in fact related. This is correct, but it does not imply that the exact relation can be inferred from the UCD themselves. There are other expressive means to describe relationships between elements (e.g. use of <GROUP> tags in VOTable).

We decide to keep UCD1+ simple: they are just simple combinations of words that describe elements. The idea is that ultimately, a UCD3 system, using RDF and/or ontologies will allow a precise description of the relationships between elements. But this will lead to much more complex UCDs, that will most likely be no longer human-readable (or writeable). We hope however that most of the simple words that are defined in the UCD1+ vocabulary will be reusable in future evolution of UCDs.

We will see in section 6 how UCD1+ can be used in practice now, despite (or taking profit from) their simplicity.

Examples of UCD1+ and how they are built:

• The maximum temperature of an instrument. This is a temperature, so the primary word will be: phys.temperature. This temperature is that of an instrument, so we specify it next: phys.temperature;instr. And finally, we add a third word to indicate that this is the maximum value of a phys.temperature;instr, giving the final UCD:

  phys.temperature;instr;stat.max

• The error on a magnitude measured in the V band. The quantity is an uncertainty, so the primary word will be stat.error. This uncertainty applies to a magnitude, so we write stat.error;phot.mag. Then, we can specify the photometric band with another word, giving stat.error;phot.mag;em.opt.V.

In most cases, as shown in appendix A, one or two words are sufficient to form a UCD.

We can note that some of the words present in the vocabulary can not be used as primary words to describe a simple quantity (e.g. most of the words starting with em. that only describe a part of the electromagnetic spectrum). Such words that can not be used as primary will be flagged in the list of standard words, so that people or tools trying to assign UCD1+ can avoid errors.

3.4  Special words combinations

Some words of the vocabulary need to be used in combination with other words. These suggested combinations are described in the document defining the list of UCD1+ words, with the definition on the corresponding syntax flags. We list here a few construction rules that should resolve the most frequent problems in combining the words:

1. Words like phot.mag, phot.flux, phot.count are quantities that should be followed by one secondary word from the em branch, indicating in which part of the spectrum the quantity was measured. E.g. phot.mag;em.IR.J represents a magnitude measured in the J band.

   This two-words combination should then be treated as a single block in the case where other words are to be added to this UCD.

2. phot.color should be followed by two words from the em branch, to express what bands were used in the computation of the color. For example, phot.color;em.opt.B;em.opt.V in that order represents the B-V color (while phot.color;em.opt.V;em.opt.B would mean V-B).

3. Some words (meta.main, meta.modelled, stat.mean, stat.median, stat.min, stat.max) are qualifiers, and it is recommended to place them after the quantity they qualify. For example, phys.temperature;stat.max or phot.mag;em.IR.J;meta.modelled are valid UCD (the latter illustrating points 1 and 3).

4. arith.ratio is used to represent a ratio between two quantities represented by the same UCD. For example a temperature ratio T₁/T₂ is represented by phys.temperature;arith.ratio. It can not be used for ratios between different quantities (e.g. mass-to-light ratio).

   Similarly, arith.diff is used to represent a subtraction between two quantities represented by the same UCD.

4  UCD Boards

The use of ``mission-specific'' namespaces has been addressed in many occasions, and we believe that namespaces should be avoided as much as possible. There has been an exercise in revising the VOX words for the SIAP protocol and trying to assign existing UCDs to them, or proposing new UCD words for the non-existing ones.

The responsibility of the board consists in studying the cases where a UCD word is proposed and to figure out whether the proposed word should be accepted or rejected, and in case of rejection recommending the closest existing word that should be used.

In case a new word is accepted into the main tree, an internal procedure is established so that the new UCD becomes live after a proper internal new release in a short period of time. It should be agreed whether this board would study the proposed cases in an "on demand" basis or would collect requests and study them on a periodic basis.

This Scientific Board is composed of astronomers with broad experience in different subdisciplines as well as data providers. They should have the experience and the resources to maintain the UCD system.

The board's mission is only to maintain and improve the list of words (see 4.5). If major modifications were to be made to the UCD structure, the way they are built or their goal, then the reference document would have to go through the whole IVOA validation process.

4.2  A procedure to request new UCD words

• the contact point to ask for new UCD
• the life-cycle of the process of asking for a new UCD
• when and how a new UCD becomes live
• what to do if a UCD is rejected

The Scientific Board will address these issues. Lessons should be learnt from other projects where similar boards exist. There should be a thorough investigation (maybe from the board mentioned above) of how other projects have worked in this direction (like the Planetary Data System (PDS), the FITS consortium, the W3C) and try to get the right things from them while avoiding the wrong ones.

A first interface for requesting new UCD words has been set up: http://cdsweb.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments

4.3  Creation of a Technical Board

Currently, most of UCD-related material is available at this address : http://cdsweb.u-strasbg.fr/UCD/

4.5  List of valid words and UCDs

The list of valid words is not included in this document: it is described in a separate IVOA document: http://www.ivoa.net/Documents/latest/UCDlist.html

The Scientific Board keeps the list under configuration control. Tools are provided for people using UCDs, to allow easy validation, and to ensure compliance of the words with the latest version of the list (see the upgrade method in section 7).

5  Transition from UCD1 to UCD1+

Services or protocols that already use UCD1 could evolve to use UCD1+ with little extra work. This is because, in most cases, they use standard elements that can be easily expressed with simple combinations of words.

The flexibility of UCD1+ could also be exploited. For example, the Cone Search currently expects the use of the UCD1 POS_EQ_DEC_MAIN. This element would now be written pos.eq.dec;meta.main. The meta.main word is in fact only useful when there are several values of declination in the same dataset. If there is only one value of a declination, it could be described by pos.eq.dec, and a flexible matching function could indicate that this UCD is compatible with the required pos.eq.dec;meta.main (cf appendix B).

The definition of a new list of words is also the occasion to describe in a homogeneous way elements that do not exclusively come from the UCD1:

• a description of FITS keywords coming from different image headers adds useful words to the vocabulary;
• the VOX words that are used for the SIAP protocol can be replaced by combination of UCD1+ words. Only a few words not used in the vocabulary defined by UCD1 are required;
• the atomic and molecular data description is also underway, to provide a homogeneous description of large reference databases in this domain (BASECOL, ...).

6  Use cases

6.1  Database Access and UCD: Translation Layer

What is needed for interoperation with other systems is a ``translation layer'' that is able to associate UCD to the parameters that are used internally, so that the output of the service contains a standard description that can be interpreted by other VO services.

Figure 1: Services use UCD to exchange information. A translation layer is used to interpret the internal description in terms of UCD.

The mapping done by the translation layer can be done using XML files. For the second service above, we can specify that quantities corresponding to UCD pos.eq.ra and pos.eq.dec are to be found in the database table Obs-Table, which has column names alpha and delta:

<?xml version='1.0'?>
<!DOCTYPE ucdToDb SYSTEM 'ucdToDb.dtd'>
<ucdToDb>
      <ucd name="pos.eq.RA" table="Obs-Table" col="alpha" />
      <ucd name="pos.eq.DEC" table="Obs-Table" col="delta" />
      <ucd name= ... />
</ucdToDb>

6.2  UCDs in VO tools

There are already applications that use UCD1 to manipulate or display some data to the user, or to find required fields (VOPlot, Filters in Aladin), ...

If they want not to change, they can use the primary UCD1+ word only.

With UCD1+, it is possible to be more flexible, and to find the ``most appropriate'' element in a dataset.

Consider a tool that expects to find a field with UCD pos.eq.ra;meta.main. Using a custom matching function (see appendix B) to analyze the contents of a VOTable file, this tool could consider that pos.eq.ra matches in the absence of pos.eq.ra;meta.main, and pick that column as the expected one.

6.3  UCDs in a registry

Consider a registry containing descriptions of catalogues, with the associated UCD. The benefit of having access to the contents in terms of UCD is that it is possible to explore the contents of a catalogue more extensively than with simple keywords.

E.g., a catalogue dedicated to very accurate measurement of proper motions and parallaxes will certainly put keywords for these, but it might also contain a column that measures a radial velocity. With UCDs assigned, this column could be identified and the catalogue selected for someone searching for radial velocities, even if this is not the primary goal of the catalogue.

It is however not necessary to describe every element of a dataset by UCDs. Only the most relevant columns need have UCDs attached to them. Parameters used for internal processing by a service do not need to have UCDs attached.

Consider the catalogue above described with UCDs in a registry. A query by UCD allows to locate this catalogue and find that it contains radial velocities.

Once the resource is located, one can then send a query to this resource, either on its specific parameters or again using UCDs.

Because UCD1+ have a more flexible syntax, it is possible to make some kind of fuzzy search, with the help of matching functions (see appendix B) in the case of the search in a registry.

The different possible levels of granularity in the description allow more interoperability.

7  Software and Services

Those currently available are:

• UCD Browser: This tool allows a dynamic view of the tree of UCD1+, either as a single text file, or as a Javascript-enabled tree-browser.
• translate: this tool translates a UCD1 into the default corresponding UCD1+.
• explain: this tool returns a textual description of the meaning of a given UCD1+.
• validate: this tool checks if a UCD1+ is correctly written.
• upgrade: this tool transforms a deprecated UCD1+ into the recommended expression according to the latest version of the list of words.
• assign: This service returns a UCD1+ corresponding to a plain text description.

The UCD Technical Board (see section 4.3) is responsible for proposing and designing new tools.

A  Consequences for VizieR

A.1  Building the list of simple words

The work of finding UCD1+ corresponding to UCD1 consists in finding combinations of simple words that will be used in practice (because they already are with UCD1 in VizieR), and thus an important step in settling UCD1+ on some solid ground.

In this process, the list of simple words forming the vocabulary of UCD1+ is built progressively: UCD1 are translated into word combinations, with new words created when necessary. Care was exercised in the choice of the words, so that those words are:

• unambiguous (avoid homonyms, and provide a clear definition for each word)
• reusable (because the UCD vocabulary should be flexible)
• consistently used (the same word is used to describe the same idea in different places)

Of course, the result will still certainly need a few iterations before some consensus is reached on the vocabulary.

A.2  Result

The first result of the translation of UCD1 into UCD1+ is a considerable simplification of the list of terms. The 1394 different UCD1 used in VizieR transform into approximately 600 different UCD1+ combinations. These combinations use less than 450 different words in total, (see section 4.5 for the list of words).

The transition to UCD1+ brings some improvements:

• the new system is more flexible, because of the possibility to combine words: commonly used concepts (meta.id, or phot.mag) are described by simple words (that can possibly be used in combinations with other words to add some meaning) and allow simplifications of the vocabulary;
• the new system is more accurate than UCD1: one can be more expressive. For example, the UCD1 ERROR corresponds to the new word stat.error. But in practice, with UCD1+ we can assign many combinations starting with stat.error to the unique UCD1 ERROR;
• people who want to use one-word UCD can still interoperate with people/softwares that use composed UCD: the matching function should work because the primary word is the most important;
• the translation to the new system has allowed us to clean up some problems in the current definition or usage of UCD1 within VizieR. These problems were encountered mainly with very specific UCD1 used in only one catalogue. There were also a few ambiguous definitions of UCD1, or problems poorly assigned UCD in specific catalogues that were fixed.