> 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
I agree that we'll never have a complete list of useful wavelength regions, but there is still a difference between "an instrument with the bandpass of a Bessel V filter" (instr.opt.V) and "photons with wavelength corresponding to the peak of a Bessel V filter" (em.opt.V). Although I see arguments for both, I personally prefer the old form.
> 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
Did anyone ever respond to my suggestion of using the primary word "weather"?
Seeing is only the property of an observation if used to describe image properties. If one is careful, it's not even the property of an observatory but simply part of the "weather". We need other weather words anyway, so
weather.seeing weather.temp weather.humidity weather.precipitation
which permits the weather generally or the "weather" inside a dome to be described. If you want the seeing within an image (which is implied by "instr.obsty.site.seeing" since it's tied to an instr), then you need things like
> 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
YUK! I propose to DROP meta.code.multip ALTOGETHER : why single out this one property of objects when there are zillions of others? The other meta.codes are tolerable because they're very general and inspecific (e.g. "quality" or "class") or at the very worst boolean ("membership").
> 10. we propose to add a further "meta" atom: "meta.subexp". Rationale:
> this will allow to characterize the rank of sub-exposures in a
> multi-exposure observations, whenever useful for, e.g., variability
> studies
Sorry - another YUK! This is even worse than using src.class.distance officially only for Abell distance class.
The only reasonable solution is a general-purpose hierarchy structure word: meta.pos or maybe meta.hierarch, where one can easily recognize that, e.g., the value "0" or "A" is the top level, "1" or "B" the next, etc. Then one could use this for all kinds of things.
> 11. we propose to add a further "meta" atom: "meta.rank". Rationale:
> useful to indicate an element in an intrinsically vectorial quantity
See above.
> 12. we propose to move "meta.id" and "meta.id.assoc" to "src.id" and
> "src.id.assoc". Rationale: they belong to "sources" rather then to
> "metadata"
Only if one is applying them to sources: when applying them to other things (e.g. XML document id's), one would have a problem with src.
> 13. we believe that the following "phys" word should be moved to
> "src":
> "phys.angArea", "phys.AngSize" (and associated words), "phys.area",
> "phys.size" (and associated words). Rationale: the same as #12 above
Ibid.
> 14. we believe that words belonging to the following categories:
> "phot",
> "pos", "spec", should be placed under the category "src" (e.g.:
> "phot.antennaTemp" -> "src.phot.antennaTemp", "pos.angDistance" ->
> "src.pos.angDistance"; "spect.Doppler" -> "src.spect.Doppler".
> Rationale: all these words ultimately describe source properties
Just as you argued above to place the words appropriately, antennaTemp is DEFINITELY not a property of a src but of an obs or instr.
> 15. the words for coupling of quantum numbers do not cover all the
> possible coupling cases. A more general method is needed, and the Data
> Line Model sub-group is indeed working on this. We propose to wait for
> the conclusion of their work, before this issue is ultimately addressed
>
> 16. a new word "pos.offaxis" should be added. Rationale: the off-axis
> angle may be a useful quantity is some catalogs
A better and more general choice would be "pos.relative".
> 21. we propose to add "src.stellarityIndex". Rationale: it may be
> useful
> to easily discriminate point-like from extended sources
Too specific. The current "src.class.starGalaxy" is just as bad or worse (as if there are only stars and galaxies out there!). A MUCH better solution is "src.class.resolved". Please dump src.class.starGalaxy!!!!
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!!!!)
Otherwise, OK. 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 or (like myself) wrote their disserations at home using an acoustic modem at 300 baud and so don't trust computers and networks to handle strings longer than about 8 characters. ;-)
Rick
NEW ADDRESS!!!
------------------------------------------------------------------------
------------------------
Dr. Frederic V. Hessman Hessman-at-Astro.physik.Uni-Goettingen.DE
Institut für Astrophysik Tel. +49-551-39-5052
Friedrich-Hund-Platz 1 Fax +49-551-39-5043
37077 Goettingen Room F04-133
http://www.Astro.physik.Uni-Goettingen.de/~hessman
http://monet.Uni-Goettingen.de ------------------------------------------------------------------------ -------------------------Received on 2005-07-14Z11:42:55