UCD comments 2: Rick's suggestions
Hi UCD board,
Rick Hessman proposed a number of UCDs (May 30) and I wanted to comment on them.
One was
spect.cont spectral continuum
I endorse adding this, it's very useful for my own data.
Rick suggested either
em.grav-wave
em.neutrino
with 'em' redefined as 'emission', or else
phys.grav-wave
phys.particle.{cosmic-ray,neutrino}
I like both. If you are comparing the light curves of the
SN1987a neutrino flux and the optical flux, it makes sense
to me to have
phot.flux;em.neutrino
even though 'photometry' strictly doesn't apply to non-photons, or
maybe better
phys.flux;em.neutrino
but I think that
phys.flux;phys.particle.neutrino
is more generalizable, so I suggest we go with that.
He also proposed an obs.calib tree to describe many different kinds
of observation. I feel many of these are better handled with secondary
words, for instance
obs.calib;phot.flux instead of obs.calib.flux
I know that some people feel excessive use of secondary words
means that a simple search returns too many false positives - but I am
convinced that alternative is an explosion of the vocabulary that
will overwhelm us, and that a mild increase in search query sophistication
will solve the perceived problem.
We already have instr.calib, but many calibrations are not just for the instrument per se but for the observation as a whole (e.g. for ground based photometric calibrations it's usually not the instrument but the sky that is changing and needs calibration). So I think obs.calib is a better UCD.
So here's my proposal for Rick's list, in which proposed new UCDs are marked by a * (sort of the paleolinguistics convention of marking hypothetical word forms with a *).
Rick Jonathan phys.grav-wave/em.grav-wave *phys.wave.gravitational phys.particle.neutrino/em.neutrino *phys.particle.neutrino
(note that phys.wave is a good subtree for other things like phys.wave.Alfven or phys.wave.dispersionRrelation)
instr.calib *obs.calib [Calibration observation] phot.calib obs.image;*obs.calib;phot.flux
[It's an image; it's for calibration; what are we calibrating - flux.]
spect;*obs.calib;phot.flux
[or, it's a spectrum...]
obs.calib.dome-flat obs.image;obs.calib;*instr.det.flat;*instr.tel.dome
[We're calibrating the flatness of the detector; we're using the dome to do it]
obs.calib.flux obs.image;*obs.calib;phot.flux obs.calib.freq spect;*obs.calib;em.freq
[It's a spectrum; it's for calibration; we're calibrating freq]
obs.calib.guide-star meta.id;*obs.calib;*pos.astrometry
[If this is the name of the guide star used..]
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 [If you mean by this an arc spectrum; what diff from obs.calib.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
Rick's next message on May 30 proposed an 'event' tree. All his events are things that happen to sources, so we might want to make this a src.event subtree. Also, it's "occultation", not "occulation". Otherwise I like it. But as we agreed in Kyoto, let's wait a while on this subject.