UCDs in SpectrumDM
jcm at head.cfa.harvard.edu
Sat Jun 23 11:52:33 PDT 2007
I guess I don't feel that
(and similar) are 'cumbersome' - I find them much easier
to understand than extra custom-crafted UCDs like ..perWave.
I feel that em.wl, em.freq, etc. are naturally adjectives as well as
nouns; since they are 'Q' and not 'P', what I have done seems perfectly legal, and
I guess I would like a reason based on the standard that it's not right,
rather than just 'Andrea doesn't like it'...
I accept the proposal to add stat.error.lower, stat.error.upper, em.wl.air
as new UCDs. But I'm a bit concerned that you give me all this input now
at/after the end of the RFC period, we were hoping to get approval for Spectrum
at the July 15 exec - if we need to add all these new UCDs, does this
mean we have to wait for a new update to the words list to be approved
before Spectrum can go to approval? (Plus, of course, the time required
for all the implementers to change their implementation, since we've published
essentially the current list of Spectrum UCDs over a year ago and everyone is using
them - this mostly is important for the Flux.Value cases).
For polarized flux: yes, a data provider could choose to separate
it out into (total flux vs wavelength) and (fraction of polarized flux vs
wavelength), but I believe it's fairly common (certainly
in AGN work) to show the product of these two things as the 'polarized flux',
and I want a UCD for that. Since phys.polarization is an 'E' word, I believe
that phot.flux.density;em.wl,phys.polarization is a reasonably unambiguous
UCD for this?
For em.*: in the context of the doc, this is a shorthand for
(EITHER em.wl OR em.freq OR em.energy).
I hope other sci-ucd members will comment.
> 1) first of all, a general consideration: if we miss an ucd-word for
> expressing a given quantity, then lets create the corresponding new
> 2) as an alternative, we can agree that e.g. phot.flux.density;em.wl
> (or freq or energy) indicates the flux density per unit wavelength (or
> frequency, or energy) : no syntax problem (valid syntax <EQ>), but
> cumbersome if you want to add other modifiers/qualifiers (em.opt,
> stat.max,...). What I do not like in the form phot.flux.density;em.wl
> is the use of a quantity (em.wl) as a modifier/qualifier of the first
> quantity (phot.flux.density). In this case I prefer going to point (1)
> above, and re-present the proposal (see Victoria 2006) of adding:
> phot.flux.density.perEnergy, ..
> phot.flux.photon.per*, ..
> phot.flux.brTemperature, ..
> phot.intensity.perWave ..
> So, phot.flux.density;em.wl;spect.continuum will become
> About Polarized Flux: I dont understand the problem. I would have added
> an additional attribute for the degree of polarization or the fraction
> of polarized flux.
> the same concern applies to phys.area;phys.transmission: lets go to
> src.amplitude;arith.ratio : you are right
> Spectrum.Char.SpatialAxis.ucd, unit: I took out meta.ucd, meta.unit for uniformity with the other axes. You can replace them, adding them also to TimeAxis .
> stat.error;em : yes, if a * is legal in your context, you can write stat.error;em* (but not meaning all the em-word branch! )
> em.wl;obs.atmos: I prefer em.wl.air.
> 3) in order to avoid confusion in multi-word ucds, I suggest also to introduce
> stat.error.lower instead of stat.error;stat.min
> stat.error.upper instead of stat.error;stat.max
> Ciao, Andrea
More information about the semantics