> 1. we propose to remove all the words containing an explicit
> specification of the wavelength or frequency range...
> 2. we propose to substitute "instr.${band}" for all words of the type
> "em.${band}". Rationale: the sensitive bandpass is a property of the
> detector
This has been a problem since the very beginning of the ucd's history. The
pros and cons of different possible solutions were carefully considered,
and at the end it was decided to consider that <em> words were only a way
to describe the wl/freq axis, NOT the properties of an instrument, and that
the spelling was only mnemonic.
The job of assigning the right em-word to a point or interval on that axis
is done by a script, who takes care of units, band codes, intervals,
difference of intervals (i.e.: colours in astronomy), so that, for example:
2.456mm is translated into em.mm.100-200GHz L em.IR.3-4um 0.1eV em.IR.8-15um 0.001nm em.gamma.hard V-N em.opt.V;em.IR.8-15um , and even F439W em.opt.B
(Warning: the on-line script needs a quantity to assign an ucd. em-words are not, so add mag/flux... to your wl/freq/energy to get an answer)
> 3. we propose to add the words "em.wl.start" and "em.wl.stop".
> Rationale: they may be useful and flexible characterizations of the
> bandpass
In many cases I found a data/column description saying: beginning/minimum wl, ending/maximum wl, that I translated using stat.min, stat.max. On the other hand, beginning/ending of observation/exposure deserved wholly new ucd-words! So I'm in favour of introducing these concepts, but as generic qualifiers that can be applied to any axis (time, wl, freq, ..)
> 4. we propose to move "instr.obsty.site.seeing" to "obs.seeing".
> Rationale: this is a property of an observation rather than of an instrument
I whould say seeing is a property of a <site>. I also agree with Rick's suggestion, it's a property of the <weather> at a given site.
> 5. we propose to unify "instr.beam" and "instr.det.psf" into
> "instr.psf"...
> 6. we propose to remove "instr.precision". Rationale: too generic,
> probably useless
A good occasion to repeat that the list of words was initially built entirely bottom-up, i.e. from data description. If "instr.precision" exists, it means that the description "precision", although too generic, has been used by some author.
> 7. we propose to add the following radio-related words:
> "instr.interferometry", and "instr.resolution". Rationale: the former is
> self-explaining; the latter indicates the spatial resolution
The former can be one of the many <non-quantities> with syntax-flag S. As for the latter, at present:
instrument resolution => pos.resolution image resolution => pos.resolution;obs.image spatial resolution => pos.resolution
> 8. we propose to change the word code of "instr.filter.transm" and
> "instr.spect.resolution" to "V". Rationale: the filter transmission is
> an intrinsically vectorial quantity; the spectral resolution as well
> (dependence on energy and/or order)
The V-flag indicates a vector in <ordinary> space
> 9. we propose to add a further atom to the "Multiplicity of binarity
> flag": "meta.code.multip.star", "meta.code.multip.planet". Rationale:
> self-explaining
I think that <meta.code.multip> is tolerable because it's sufficiently generic, and because it is used.
> 10. we propose to add a further "meta" atom: "meta.subexp"...
> 11. we propose to add a further "meta" atom: "meta.rank"...
I need a use-case to make-up my mind
> 12. we propose to move "xxx" to "src.xxx"
> 13. as above
> 14. as above
> 20. as above
> 24. as above
In doing this, I think we would narrow the meaning of those words.
> 16. a new word "pos.offaxis" should be added. Rationale: the off-axis
> angle may be a useful quantity is some catalogs
I agree.
> 17. "pos.earth", "pos.earth.lat", "pos.earth.lon" should be placed under
> the "obs" category. Rationale: these quantity belongs logically to an
> observation, not to (the position of) a source
I can assure you that pos.earth means position ON the earth, not source position on some earth-based coordinate frame!!
> 18. "pos.earth.nutation" should be removed. Rationale: it is no longer
> consistent with the IAU specification
Changed.
> 21. we propose to add "src.stellarityIndex". Rationale: it may be useful
> to easily discriminate point-like from extended sources
A word with the description ?stellarity index? already exists.
> 22. we propose to add the following words in the "stat" category...
> 23.
Yes, I think a revision of the "stat" category is probably necessary.
> 25. we propose to add the following word: "time.deadtime". Rationale:
> useful for photon-counting devices based catalogues
I agree.
> An additional point that we have discussed concerns the units in which
> interferometric data shall be provided...
?? UCDs do not care about units..
> Finally, there are still two corrections to the descriptions to
> remove narrow applications of general concepts:
> src.morph.type | morphological type, e.g. Hubble (there are others!!!)
> src.morph.scLength | scale length, e.g. of disk or bulge in a
> galaxy (there are others!!!)
> src.spType | spectral type, e.g. MK (there are others!!!!)
Sorry, but I did not study english at school. I studied latin.
When you write:
i.e. = id est, you mean: that is
e.g. = exempli gratia, which means: for example (i.e., of course, there are
others!!!)
> I'm still not enthusiastic about the inconsistant use of contractions
> ("lg" is OK for "local group" but "sg" is not OK for
> "supergalactic"???), > but there are obviously too many of us old
> people who grew up worrying about to get our > data into 4k of
> computer memory...
Indeed!!! I still feel that changing to ?supergalactic? was a terrible waste of memory!! :-)
Andrea
Andrea Preite Martinez andrea-at-rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.339.381735500133 Roma