Unified Content Descriptor Controlled Vocabulary RFC

This document will act as RFC centre for the UCD - Controlled Vocabulary Proposed Recommendation.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used in ResourceMetadataRFC (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the mailing list semantics@ivoa.net.

Comments on new version 1.2

---

(please insert here your comments)
SebastienDerriere : suggested modification:
Transform the atoms exposure and sequence into secondary words for a greater flexibility and for omogeneity with observation. So:
Start time of observation is now time.start;obs
Start time of exposure will become time.start;obs.exposure
Response (by AndreaPreiteMartinez):
OK, already implemented.

---

JonathanMcDowell : suggested new word:
I would like to propose : spect.continuum as a Q word, for example phot.flux.density;spect.continuum to represent continuum flux (a fit to the continuum spectrum, say)
Response (by AndreaPreiteMartinez):
OK, although I think the syntax flag should be S, not Q

---

---

Comments on old version 1.11

---

AndreaPreiteMartinez : suggested changes to the list:

1. suppress instr.filter.transm, replaced by phys.transmission;instr.filter

2. change instr.filter into a secondary word (flag S)

Response (by AndreaPreiteMartinez): suggestions accepted.

---

AlbertoMicol - 16 Sep 2005:

3. Suppress em.wl.central

Rationale:

em.wl.central exists, em.energy.central and em.freq.central don't. Wouldn't be better to remove it and use instead em.wl;stat.mean?

4. em.wl.effective

Similar, but not identical, to em.wl.central. Maybe effective and central should be added to (e.g.) stat?

Response (by AndreaPreiteMartinez):

the proposal to move the atoms "central" and "effective" to the stat tree can be discussed for the next issue of the controlled vocabulary. The reason why wl.central exists, while energy.central or frequency.central don't, is that "central wavelength" is a description of a quantity that is actually used (remember the bottom-up approach of the vocabulary). See, e.g. HST log or the wfpc2.

---

PierreDidelon - 19 Sep 2005

somethings seem to miss in UCD1+, even compared to UCD1. for example

5. considering polarization in UCD1 we found POL_FLUX_LCP, POL_FLUX_LINEAR, POL_FLUX_RCP corresponding in UCD1+ (http://vizier.u-strasbg.fr/UCD/ucd1-ucd1p.txt) to ... phot.fluxDens even not a polarization, phys.polarization at least would be preferable. And it would be nice to introduce something more specific like phys.polarization.linear and phys.polarization.circular.

Similarly for POL_STOKES_I, POL_STOKES_Q, POL_STOKES_U, POL_STOKES_V only phys.polarization.stokes exists, it may be worthwhile introducing phys.polarization.stokes.I...

and even for new word introduced the tree is not enough developped

Response (by AndreaPreiteMartinez):

"phys.polarization" already exists. Atoms "linear"/"circular" can be introduced. The UCD "phys.polarization.Stokes" groups all Stokes parameters. It could be worthwhile introducing the different names of the parameters in the case they were used separately.

---

6. pos.bodyrc need to be extend to pos.bodyrc.lat, pos.bodyrc.lon, pos.bodyrc.alt and pos.bodyrc.dist.
pos.precess, pos.eop, pos.eop.nutation really need extensions also.

Response (by AndreaPreiteMartinez):

suggestions accepted for "pos.bodyrc.lat/lon/alt".
pos.bodyrc.dist could be written "pos.distance;pos.bodyrc".
For the other, I'm open to suggestions!

---

comments from PatricioOrtiz

7. file http://vizier.u-strasbg.fr/UCD/ucd1-ucd1p.txt has one type in

SPECT_EQ-WIDTH spect.line.eqwidth
It should be spect.line.eqWidth.

Response (by AndreaPreiteMartinez): change accepted

---

8. The following deprecated terms still appear in the list:

phot.fluxDens still in the list
phot.fluxDens.sb still in the list
phys.massYield still in the list

Response (by AndreaPreiteMartinez):

Yes, we say explicitly this in the document:

"Changes from v1.01 .
The following words have been restored to their previous spelling (v1.00):

phot.fluDensity	phot.fluxDensity
phys.energDensity	phys.energyDensity
phys.mYield	phys.massYield

A note has been added to indicate that these words do not strictly comply with the UCD1+ Rec. "

---

9. The definition of arith.ratio can be used with quantities with different UCDs, eg, axis ratio: semi-major and semi-minor axes have different UCDs. Although the new UCD phys.size;arith.ratio doesn't make it clear that we're dealing with an axis ratio, we could be comparing planet sizes... worrisome

Response (by AndreaPreiteMartinez):

Indeed, so I suggest the introduction of the new word:

E | phys.size.AxisRatio          |  Axis ratio (a/b) or (b/a)

---

10. em.line... drop molecular, so far only atomic lines are mentioned, unless molecular lines are to be added to the list.

Response (by AndreaPreiteMartinez):

this is a change in the description of a "word". Taken.

---

11.

S | instr.pixel | Pixel

S | instr.plate | Photographic plate

could be better off as Q

Response (by AndreaPreiteMartinez):

No, they are not quantities. Example: if we say "plate" we probably want to indicate some specific quantity related to that plate, e.g. its "name" (then we'll write: meta.id;instr.plate) or central coordinates (then : pos.eq.dec;instr.plate).
Similarly for a "pixel".

---

12. pos.resolution... despite that most astronomical resolution is angular, there are other resolutions in distance, eg, solar and planetary phenomenae, and quite possibly a resolution in the distance scale. Simplifying too much could be dangerous in the long run. Furthermore, the angular resolution seems to me a quantity more related to the instrument than an intrinsic property of the object position in space.

Response (by AndreaPreiteMartinez):

Yes, "pos.resolution" might be misleading and indeed you may be right in the long run. We can modify it into "pos.angResolution".

---

13. seems to me that instr.seeing should become part of the obs.atmos family... hold on,

14. S | obs.field | Region covered by the observation

Does the explanation encompass field of view? The equivalences with UCD1 doesn't seem to show that.

Response (by AndreaPreiteMartinez):

Indeed, it doesn't mean that.

---

15. I agree with Pierre that the section on polarization has been oversimplified

Response (by AndreaPreiteMartinez): See answer to comment #5.

---

16. phys.gravity: gravity is more than surface gravity, as it could be measured around any * objcted at any distance from the surphace, and the ones doing gravitational waves experiments may find this too limiting.

Response (by AndreaPreiteMartinez):

this is a change in the description. Taken.

---

17. Are numbers permitted in atoms? This: phys.mass.light may look much better as phys.mass2ligth or phys.massToLight, light is not a property of mass.

Response (by AndreaPreiteMartinez):

Right. Let's propose "phys.massToLight".

---

18. People still quote "major axis" and "minor axis"... how do we fit this with phys.size.smajAxis and phys.size.sminAxis ?

Response (by AndreaPreiteMartinez):

In the present list we have:

phys.angSize	Angular size width diameter dimension extension major minor axis extraction radius
phys.angSize.smajAxis	angular size extent or extension of semi-major axis
phys.angSize.sminAxis	angular size extent or extension of semi-minor axis

where one can find all 4 combinations of "major,minor,semi".
In the next version of the vocabulary we can decide, to introduce a more specific

phys.angSize.majAxis

phys.angSize.minAxis

---

19. temperature: people modelling interiors might want a few more flavours of temperature.

Response (by AndreaPreiteMartinez): open to suggestions!

---

20. Q | pos.earth.altitude | Altitude, height above the Earth's surface

Do we really mean Earth's surface, as in an airborne apparatus or above sea level (to quote how high an observatory is?)

Response (by AndreaPreiteMartinez):

this is a change in the description. Yes, we mean above sea level. Taken.

---

21. time.x.start, and time.x.end . exposure is fine, observation is fine, what about a phenomenon? eg, a solar flare? What about start and end of a phenomenon at different levels of intensity/importance?

Response (by AndreaPreiteMartinez): I think it would be a good idea to introduce

time.event.start/end

---

22. in the area of photometry and color indices, how would I assign a UCD, and later on recognize without having to sort through a ton of meta-data a color index formed with two HST filters? Or Gunn filters? Just to name two of the commonly used systems today and left out of the list.

If it's felt that there are too many UCDs in the phot field, at least leave the root of the different photometric systems to avoid sorting irrelevant data when one is digging a registry for Cousins V-I!!

Response (by AndreaPreiteMartinez):

I share your concern. In the next version of the vocabulary we can decide, for instance, to introduce "S" words indicating the photometric system (perhaps the right place could be in the registry).

---

-- PierreDidelon - 23 Sep 2005

23. It seems that pos.satellite is not very usefull now that pos.bodyrc is available. Moreover its equivalent in UCD1, POS_PLANETARY may have very strange usage (see http://cdsweb.u-strasbg.fr/UCD/cgi-bin/ucd_stats?leaf=POS_PLANETARY&query=Submit) like, among others, positions of spots on close binary system [in J/A+A/426/1001, Catalog of contact binary stars (Csizmadia+, 2004) (http://cdsweb.u-strasbg.fr/cgi-bin/VizieR-3?-source=34261001&-out=*POS_PLANETARY&-meta.ucd=u) which has nothing to do with PLANETARY stuff.

Response (by AndreaPreiteMartinez):

I agree that "pos.satellite" is not only useless but misleading, or just "wrong"! Indeed its description is:
Position/coordinates of satellite or planet, not
Position/coordinates on satellite or planet.
It is as if we had to add "pos.star" or "pos.galaxy" to pos.eq.ra/dec of a star/galaxy!
I propose to remove it.

---

Comments from the Technical Coordination Group

TWG members should add their comments under their name. The deadline for comments is 4 Dec 2006.

Mark Allen (Applications IG)

I approve, and I make the following note:

There is some ambiguity in the emission line UCDs. I guess this will be addressed very thoroughly in line data models, but I suggest that the short emission line UCD list should have a minor correction.

The UCDs for the lines H-alpha, H-beta specific unambiguously mean H-alpha and H-beta transitions of H I (vac wavelengths around 6564 and 4861 Ang), but

S | em.line.OIII | [OIII] line

is ambiguous, it could be [OIII]4363 or [OIII]4959,... when what is probably meant is the bright line [OIII] 5007. So, the description should probably say '[OIII] 500.7 nm line'.

Sebastian explained: It was decided that there would be no citation of the emission wavelength value, because it is only valid for the rest wavelength, and the UCD is supposed to be the same for one transition.

In this case perhaps include some information on the transition such as the spectroscopic term which for [OIII] 5007 is 3P-1D.

Response (by AndreaPreiteMartinez): we could say: the [OIII] line whose rest wl is 500.7 nm

Francoise Genova (Data Curation & Preservation IG)

I approve.

Bob Hanisch (Standards & Documentation WG)

OK with me. In the next iteration I think someone needs to review the physics under phys.atmol. Most of this is atomic, not molecular, and there is also phys.mol.

Response (by AndreaPreiteMartinez): I asked M.L.Dubernet of the line DM to inspect the phys.at/mol branch, and the present list is also the result of that interaction. I agree that more has to be done.

Gerard Lemson (Theory IG)

I approve.

Jonathan McDowell (Data Models WG)

I approve, although I agree with FO that more detailed descriptions (possibly via links, and retaining the current concise ones) would be welcome.

Reagan Moore (Data Curation & Preservation IG)

I approve.

Francois Ochsenbein (VOTable WG)

One main wish: that the list of the valid words is more accurately described, as e.g.

• what is the validity domain of the em.IR.NIR/MIR/FIR ?
• in the em.line branch, the definition of a line by just the element+ionization can represent many many lines over the whole spectrum; while HI is defined as 21-cm line, the wavelength of OIII is not given
• while concise definitions are very useful, it happens that 2 UCDs can have exactly the same definition (e.g. Statistical wight exists as stat.weight and phys.atmol.sWeight) which means that at least this definition is too concise.

If not for this version, it would help to improve these definitions in a future version...

Response (by AndreaPreiteMartinez):

• NIR goes from 1 to 5 microns, MIR from 5 to 30 microns, FIR from 30 to 1000 microns.
• see M.Allen for the OIII line.
• I agree that some definition are still too concise (see also the comment from D.Tody). With those you are pointed out I'll start a list of the definitions that we have to improve for next version.

Pedro Osuna (VOQL WG)

I approve, but agree with Bob in that next revision care has to be taken with the separation and definitions of the phys.atmol with respect to those of phys.mol.

There is by the way a typo where in the appendix B it describes the replacement of phys.atmol.qn.I by phys.atmol.qn the Description should read: "Quantum Number" rather than "Nuclear Spin Quantum Number"

Response (by AndreaPreiteMartinez):

• yes, the description is wrong, but it refers to the deleted word.
• See Response to Bob H. for your first comment.

Ray Plante (Resource Registry WG)

I approve

Andrea Priete-Martinez (Semantics WG)

I approve

Guy Rixon (Grid & Web Services WG)

I approve.

I think one of the new items, em.binSize has been missed out of the document.

I note that there are a few words removed in this change, and words have also been dropped in previous updates. I don't object to this, but I think that all the other standards and the implementators will need to be specific about which version of UCD is used: calling it UCD1+ isn't accurate enough for interoperation any more.

Response (by AndreaPreiteMartinez):

• binSize is under the spectral branch: spectr.binSize .
• The name UCD1+ has to do with the general way UCDs are defined and constructed, as described in the IVOA Rec An IVOA Standard for Unified Content Descriptors, 19 August 2005. We (I mean we-all) agreed to separate the main document from the vocabulary in order to upgrade and mantain the list of ucd-words without changing the main IVOA Rec.

Doug Tody (Data Access Layer WG)

I am happy to approve the document, with some comments. This document is remarkably concise; I suggest adding at least a sentence or two at the front stating what a UCD is and what UCDs are used for. As other have noted, most of the document is the summary of UCD primaries (words). It would be useful to either define these more carefully in the document (what is the difference between src.var, src.var.amplitude, src.var.index, src.var.pulse?), or perhaps instead online, in a controlled area. It seems that a vocabulary such as this will constantly evolve, hence merely having a document is probably not sufficient.

Response (by AndreaPreiteMartinez): see response to FO's comment

Nic Walton (GGF Astro-RG)

I approve

Roy Williams (VOEvent WG)

I approve