(r7) SpectrumDataModelRFC < IVOA

IVOA Web>SpectrumDataModelRFC (revision 7) (raw view)~~EditAttach~~
---++ Spectrum Data Model RFC

This document will act as *RFC* centre for the [[http://www.ivoa.net/Documents/cover/SpectrumDM-20070515.html][Spectrum Data Model 1.01 Proposed Recommendation]].

Review period: 16 May 2007 to 12 Jun 2007 (still open)

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your TWiki.WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the data model mailing list, dm@ivoa.net.

---++ Comments
   * First sample comment (by %MAINWEB%.BrunoRino): ...
      * Response (by _authorname_): ... 
---
   * IVOA.AndreaPreiteMartinez - 19 Jun 2007 
      * I have revised the UCDs in Tables 1, 2 and 3. The revised tables can be found *[[%ATTACHURL%/DMspectrumUCD.doc][here]]*. Note that rows with changed UCDs are in bold+italic.
      * Pag.23: erase sentence "My solution for brightness... "
      * Pag.23 last line: change with "Note: we propose for the next version of the IVOA REC UCD-list to (a) change the flag of *pos.eq* from S to Q, (b) add two new words *em.start*, *em.end* to indicate the lower/start and upper/end boundaries of a spectral interval (as already done for the time axis)"


   * IVOA.JonathanMcDowell -20 Jun 2007


Andrea,

 I don't like the fact that you propose the same UCD for energy flux
density and photon number flux density, and the same UCD for polarized
flux and total flux, and the same UCD for observed flux and for source
intensity per unit emission solid angle. These are different physical
concepts, in some cases they have the same units and I REALLY need
different UCDs to describe them to users - this is exactly what UCDs are
for. I want to avoid using units to distinguish since this is of limited
reliability ( e.g. source intensity as described below has the same
units as a surface brightness but is a very different thing)
and since it's a difference in CONCEPT not a difference in UNIT
that is key here.

<pre>
Concept                My new proposal                          Your proposal

Energy flux vs energy  phot.flux.density;em.energy               phot.flux.density;em.energy
Number flux vs energy  phot.flux.density;em.energy,phys.photon   phot.flux.density;em.energy
                    or phot.flux.number;em.energy

Flux density (vs wl)   phot.flux.density;em.wl                   phot.flux.density;em.wl
Polarized flux (vs wl) phot.flux.density;em.wl,phys.polarization phot.flux.density;em.wl

Flux density (vs wl)   phot.flux.density;em.wl                   phot.flux.density;em.wl
Source intensity       phys.luminosity; em.wl,phys.angArea       phot.flux.density;em.wl

Flux density           phot.flux.density                         phot.flux.density
Brightness temperature phot.flux.density; phys.temperature       phot.flux.density

Aperture area          phys.area                                 phys.area
Effective area         phys.area;phys.transmission               phys.area

Continuum-only vs wl   phot.flux.density;em.wl,spect.continuum   phot.flux.density,spect.continuum
Continuum-only vs freq phot.flux.density;em.freq,spect.continuum phot.flux.density,spect.continuum
</pre>

Can you (1) explain what is wrong with my proposals (ok the first one uses
a so-far-nonexistent UCD I agree, the others seem legal to me) and
(2) provide alternatives that do not lose these distinctions?

I have a few other issues with your list vs mine:

 Why is src.var.amplitude;arith.ratio not acceptable for
the variability as fraction of mean? To say that this
should have the same UCD as the actual amplitude is
losing valuable discriminatory power.

What is wrong with meta.ucd and meta.unit for e.g.
Spectrum.Char.SpatialAxis.ucd, unit?

With e.g. Spectrum.Char.SpectralAxis.Accuracy.StatError you suggest
"stat.error;em" while I suggested "stat.error;em.wl" or
"stat.error;em.freq" etc. Isn't it better to specify here, so that
software can use the UCD to tell which is being given?

Why don't you like: em.wl;obs.atmos for Air Wavelength? I would really
like to be able to distinguish it from vacuum wavelength. How can I tell
the client (user) that air wavelengths are being used?

 - thanks,
    Jonathan






---
   * IVOA.GaryFuller - 19 Jun 2007 
      * Does the model allow for double sideband spectra? That is spectra for which each pixel can correspond to two different frequencies or wavelengths? This is a fairly common situation in the mm and submm. 
      * More generally what about the issue of describing how to convert between two different spectral axes, for example in the dsb case the upper and lower sideband frequency?  
      * Is there support for non-uniform spectral (and temporal) axes? 
      * In derived data fields signal-to-noise ratio seems a poorly defined quantity as it depends on what signal, spectral feature,  is of interest to a particular user. A value for the rms noise level on the other hand would be very useful but doesn't seem to be in the model.
 
---



   * IVOA.JonathanMcDowell -20 Jun 2007

Gary:

We discussed the double sideband spectrum case but decided that
it complicated the model too much for version 1. We'll revisit
this in future, and for now you just have to pick one sideband as the
nominal frequency, maybe providing two Spectrum instances, one for
each sideband. We acknowledge this is a limitation, as is
the inability to represent two different spectra axes in a
single instance.

The S/N is a bit vague, but was requested by some data providers
for who a single target object is the norm. There is no rms noise, but
there is a 'typical (1 sigma) error' in StatError which does much the
same thing. We may add rms in a later rev but not this one.

We do, however, support non-uniform axes, since each spectral coordinate
is listed explicitly.
 



---

<hr/>

---++ Comments from the Working Group Chairs and Interest Group Chairs

Chairs should add their comments under their name.   

---+++ Marc Allen (Applications WG)

---+++ Christophe Arviset (TCG vice Chair)

---+++ Matthew Graham (Grid &amp; Web Services WG)

---+++ Bob Hanisch (Data Curation &amp; Preservation IG)

---+++ Gerard Lemson (Theory IG)

---+++ Mireille Louys (Data Models WG)

---+++ Keith Noddle (Data Access Layer WG)


---+++ Francois Ochsenbein (VOTable WG)

---+++ Pedro Osuna (VOQL WG)

---+++ Ray Plante (Resource Registry WG)

---+++ Andrea Priete-Martinez (Semantics WG)

---+++ Roy Williams (VOEvent WG)







<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
Topic revision: r7 - 2007-06-22 - JonathanMcDowell
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema