Andrea,
I guess I don't feel that
phot.flux.density;em.wl,stat.max
(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.
Andrea wrote:
> 1) first of all, a general consideration: if we miss an ucd-word for
> expressing a given quantity, then let’s create the corresponding new
> ucd-word.
>
> 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.perFreq,
> phot.flux.density.perWave,
> phot.flux.density.perEnergy, ..
> phot.flux.photon.per*, ..
> phot.flux.brTemperature, ..
> phot.intensity.perWave ..
>
> So, phot.flux.density;em.wl;spect.continuum will become
> phot.flux.density.perWave;spect.continuum
>
> About Polarized Flux: I don’t 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: let’s go to
> phys.area.effective
>
> 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
>
>
Received on 2007-06-23Z18:52:51