On 9 Jun 2005, at 8:47 pm, Jonathan McDowell wrote:
> arith a good basic tree, although "math" might be better.
> stat Maybe should be under arith?
I agree : math covers arith and stat. *math.arith *math.stat
> src Another fundamental concept, although as usual I would argue
> for
> a distinction between "src" (2D on the sky, results of
> observation) and
> "object" (real 3D thing in space).
Now, now: don't try to bring "concepts" into the UCD world ;-) !
We have to agree that "src" means "object on the sky" (where the
definition of "sky" is,
of course, relative to an observer, e.g. a spacecraft), since
everything that
UCD describes is for observations or observed properties. Otherwise,
the whole
"concept" (or, God-forbid, "ontology") discussion comes up again!
Right now, the official UCD description of "src" is "Source" - not very
helpful. I suggest
using "Observed source viewed on the sky".
> instr Fairly fundamental but one could argue should be under obs
No!: "obs" is an observation thing made with an instrument "inst". The
focal length of a telescope isn't (in our present sense) an
observation, but a
property of an instrument and so doesn't at ALL belong to "obs".
> spect I worry about spect - this is a kind of data.
> If spect, why not image? I predict a few years from now
> we will have to change spec and instr.image to data.spect,
> data.image, etc.
I agree that data.image and data.spec is a much better model, at least
for observations. After all, what UCD
often does is to provide generalized "keywords" a la FITS.
On the other hand, the VO theory people might complain that their "images" and "spectra" are not really "data".
Sounds like a problem which has to be put off until later.
> But then Sebastien reminded us of the 'concept/property' way of looking
> at UCDs, where the question becomes: are there specific properties we
> need to describe? To be more specific:
>
> radial.velocity;src.class.galaxy
>
> would be the radial velocity of a galaxy. Does having this add
> anything to
> just saying
>
> radial.velocity;src
>
> - do you really care that it's a galaxy and not a star.
> This leads to a data model question: what properties do a galaxy and a
> star
> *not* share? For example:
> object.galaxy.spiral.HolmbergRadius
> object.star.convectionParameter
>
> This, to my mind, is the correct role of object types in UCD and
> argues for a tree
> of this kind. Right now, these kind of properties go in the phys or src
> list without the 'object.<particularkind>.' prefix.
This can of worms obviously won't be solved using UCD alone: that's why
I'm pushing the
development of a parallel system which LOOKS like UCD and can be
treated/
manipulated/concatenated like UCD but addresses this concept/property
problem.
Simply put: one person's property is another's concept and vice versa,
so we need
a system which can be used in both directions.
> instr.calib *obs.calib [Calibration observation]
> phot.calib obs.image;*obs.calib;phot.flux
> obs.calib.dome-flat
> obs.image;obs.calib;*instr.det.flat;*instr.tel.dome
> obs.calib.flux obs.image;*obs.calib;phot.flux
> obs.calib.freq spect;*obs.calib;em.freq
> obs.calib.guide-star meta.id;*obs.calib;*pos.astrometry
> obs.calib.phot [What's the difference with obs.calib.flux?]
> obs.calib.pos obs.image;*obs.calib;*pos.astrometry (?)
> obs.calib.sky-flat obs.image;obs.calib;*instr.det.flat
> obs.calib.slit-mask *instr.spect.slit
> obs.calib.spect spect;*obs.calib;em.wl
> obs.calib.veloc spect;*obs.calib;src.veloc
> obs.calib.wl spect;*obs.calib;em.wl
> phot.calib.flux [same as obs.calib.flux?]
> phot.calib.mag *obs.calib;em.opt.B (etc.)
> pos.calib *obs.calib;pos
> spect.calib spect;*obs.calib
> spect.calib.wl spect;*obs.calib;em.wl
> spect.calib.freq spect;*obs.calib;em.freq
I basically think this is a very good compromise. See my other mail about problems with instr and others.
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 ------------------------------------------------------------------------ -------------------------
http://monet.uni-goettingen.de ------------------------------------------------------------------------ -------------------------Received on 2005-06-10Z12:09:12