UCDs in SpectrumDM

[Jonathan McDowell]

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.

 - Jonathan

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
> 
>