T0: needed last minute changes

From: Frederic V. \ <Hessman-at-Astro.physik.Uni-Goettingen.DE>
Date: Fri, 10 Jun 2005 12:10:44 +0200


After reading Jonathon's comments and re-reading the UCD vocabulary document again, I realized that we definitely need a few changes:

  1. I first stumbled over

                instr.obsty.site.seeing

        Does this mean we need...

		instr.obsty.site.temperature
		instr.obsty.site.humidity

	Seem like a better solution would be to introduce "weather", which  
permits the concatenation

                instr.obsty.site;weather.seeing

        which would open a new handy family

		weather				| meteorological condition
		weather.seeing		| atmospheric image quality
		weather.temp			| local temperature
		weather.humidity		| relative humidity
		weather.dewpoint		| dewpoint temperature
		weather.precipitation	| presence of rain/snow/sleet (boolean?)

	This would be VERY helpful for VOEvent/RTML.   I won't open up a new
	discussion of the uneven choice of contractions (e.g. "temp" instead of
	"temperature" but "wavenumber" instead of "wavenum" - sigh!).

	The topic "space weather" comes into mind as well , but I'll let others
	worry about that.


2. instr

        First of all, a trivial but needed addition:

                instr.det.temp | temperature of detector

	Next: we presently have "instr.tel.focus" and "instr.fov" which are
	quantities which refer to the "end-users" - no info about how the fov  
or
	focus came into being.  The problem is whether to assign something
	like "focus" to the telescope or to the instrument.  Generally, the
	fov of an instrument (e.g. CCD camera) is very different from that of  
the
	telescope.   Do we then interpret "instr" things as being from a black
	box or from a specific instrument hanging on a telescope?  If it's the  
latter,
	then one may need double entries.  In any case there's a need for  
something
	like

		instr.tel.aperture		| geometric diameter of telescope optics
		instr.tel.area			| (effective?) collecting area of telescope optics
		instr.tel.focallength		| focal length (effective?) of telescope
		instr.tel.fRatio			| ratio of focal length to aperture diameter
		instr.tel.temp			| temperature of telescope

	After all, we already have instr.focus, which is a much less needed  
number than
	the above!

	Sounds to me as if we need to distinguish between generic instr =
	e.g. telescope+filterwheel+CCD or telescope+spectrograph+CCD and
	"device" (can't think of a better name) which could be just the  
instrument part of the
	above (e.g. just the imaging camera or just the spectrograph).

	This would also imply that we need to make tel a primary key, since  
the telescope
	doesn't "belong" to the generic instrument - it's an associated thing.  
  This would solve
	Jonathon's suggested of using

		obs.image;obs.calib;instr.det.flat;instr.tel.dome

	(i.e. using proposed UCDs obs.calib and instr.tel.dome) by permitting

		obs.image;obs.calib;inst.det.flat;tel.dome

	and would permit the differentiation between e.g. instr.focallength and
	tel.focallength.  On the other hand, this means a lot of double  
entries which
	could only be gotten rid of using something like

		instr;optics.focallength
		tel;optics.focallength

	(unfortunately, "opt" is already taken: if we would be using "optical"  
for
	wavelength band and "optics" for optics, there wouldn't be any  
confusion).

        In summary, we need to get rid of

		instr.tel
		instr.tel.focus

	and add

		optics
		optics.focus
		optics.focallength
		optics.aperture
		optics.area
		optics.fRatio
		tel
		tel.dome		(instr.obsty.dome is no good if there are lots of domes at  
the site)
		tel.mount		(e.g. "alt-az", "equatorial", "english",....)


3. PLEASE PLEASE PLEASE change

			src.class.struct		->	src.class.struct.BautzMorgan
			src.class.distance	->	src.class.distance.Abell
			src.class.richness	->	src.class.richness.Abell
			src.spType		->	src.class.spectral.MK
			src.morph.type		->	src.morph.Hubble

		The present definitions associating general class descriptions with  
very particular versions
		of  mostly extragalactic classifications are absolutely insane!   Or,  
the description has to be
		changed to something like

			src.class.struct		| structure classification, e.g. Bautz-Morgan  
galaxy type
			src.class.distance	| distance classification, e.g. Abell galaxy  
cluster
			src.class.richness	| richness classification, e.g. Abell galaxy  
cluster
			src.class.spectral	| spectral classification, e.g. MK spectral class

		which results in a loss of specificity.  There are other spectral  
classes beyond MK stellar,
		other richness classifications other than Abell (e.g. open stellar  
clusters), ....

Rick



Dr. Frederic V. Hessman      Hessman-at-Astro.physik.Uni-Goettingen.DE
Universitaets-Sternwarte     Tel.  +49-551-39-5052
Geismarlandstr. 11                Fax +49-551-39-5043
37083 Goettingen                 http://www.uni-sw.gwdg.de/~hessman

------------------------------------------------------------------------
-------------------------

MONET: a MOnitoring NEtwork of Telescopes
http://monet.uni-goettingen.de

------------------------------------------------------------------------
-------------------------
Received on 2005-06-10Z12:09:17