SpectrumDataModelRFC < IVOA

---++ 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. <nop>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 <nop>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.
 

---
   * IVOA.AndreaPreiteMartinez - 22 Jun 2007

Jonathan,

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

---

--- * IVOA.JonathanMcDowell -23 Jun 2007

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).
 - Jonathan 

--- * IVOA.JonathanMcDowell - 11 Jul 2007   


Andrea,

 I've reviewed your UCD suggestions again. While some of them are very sensible,
I don't feel they are compelling enough to change the version 1 Spectrum standard
at this late date, given the existing implementations. We should plan
to evolve the UCDs in any later revision to the model.

 I note that the only ones that really matter are those in in table 3, which
may be used by software to distinguish different Y axes; the other UCDs
are all fixed: so the important argument is over "phot.flux.density;em.wl" versus
"plot.flux.density.perWave", and I think the other Spectrum authors also prefer
my way (although none of them have responded to your comments!)

- Jonathan

 


--- * IVOA.FrancoisBonnarel - 25 Jun 2007

    Jonathan,
Reviewing the document, I discover two little points which may
be a problem:

 A)  Page 8 the document claims that
"
In section 4 we elaborate these concepts in detail, including some complications that we
explicitly do not attempt to handle in this version. The data model fields and possible values arelisted. We distinguish between optional and required fields in the text, as well as via a "Req"
column in the tables which has values of R (Required) and O (Optional). Where appropriate
we list those values of the physical units which interoperable implementations are required to
recognize."
   But actually at page 13 and in the following table there is
no more Required and Optional but "MANDATORY" abreviated as MAN and
"OPTIONAL" abreviated as "OPT". In addition we have "REC" for recommanded. I think i remember the statement at page 8 was what
was planned at the beginning...
 
  B ) Page 17 for the Spectrum.Char.*.Calibration utypes I
think the meaning should be "coord calibration status" instead of
Type of Coord Calibartion. Type can be interpreted as "Data Type"
for calibration, no ? (Or is that due to French being my mother 
language?)

François Bonnarel

<br> * IVOA.DougTody  - 8 Jul 2007

The first item is a typo (left over from an earlier version) and will
be fixed in the next version.  The reference to "section 4" is also
incorrect.

Regarding the "type of calibration", this could be expressed either way,
but I think "type" is better than "status", so long as the allowable
values are documented.


--- * IVOA.FrancoisBonnarel  - 25 Jun 2007

Page 56 you write:

"How can this be generalized to mapping an arbitrary data model schema to VOTABLE? The
only tricky parts are
" Spotting where the tabledata parts are. We could require any DM schema that maps
to VOTABLE to include elements called FIELDS and Data (perhaps ROWS would be a
better name), otherwise you would get a VOTABLE with no data section.
" Spotting where to start the main TABLE (i.e. the fact that SPECTRUM is
special). We could change the schema to have an explicit attribute, annotation or other
marker to tell us this.
These issues will require further discussion for future models."

We started a discussion on that in Moscow... (yes Moscow, not
Beijing !!!)

  I think the formulation here is a little too restrictive.
We may imagine any elemnt with a simple content as a "FIELD"
in some context, as long as you have more than one representative
of this element. It is not the case here but what when we will
get several segments in a main SED or Echelle spectrum ?
Will we have each segment as a separate Spectrum serialisation and
all this concatenated ? or redefine the PARAMS with several representatives as FIELDS... An index FIELD can be defined to hook
information in the "metadata" TABLE to information in the data
TABLE. This is the way we try to implement data models in the
DAL Extension mechanism (see SSA 1.01 and references therin), and I
think we need to let that open.
So I will rephrase:
"map all elements with simple content to PARAM" as
"map all elements with simple content and one single representative to PARAM"

and add a third "spotting".

"Spotting if and where we need secondary TABLES with Metadata 
FIELDS and how we hook the information therin to the main TABLE rows"

François Bonnarel

<br> * IVOA.DougTody  - 8 Jul 2007

None of the analysis in 8.1 is actually necessary for SSA V1.0 as the
VOTable serialization is explicitly defined, hence we don't require a
general scheme for mapping arbitrary data models to VOTable.  It is not
necessary to resolve this now; as the text says "these issues will
require further discussion for future models".

That said, my recollection from the old SED model is that each segment
mapped to a separate TABLE element.  Within each TABLE, one can have
both PARAM and FIELD elements, depending upon whether the element has
multiple values.  What is most needed for a general mapping from a
data model to VOTable is probably a way to identify what is a TABLE in
the VOTable representation.  Within a TABLE, PARAM and FIELD are the
same except that FIELD is used if the element has multiple instances.
Outside TABLE, only PARAM is used.

We should revisit this later when we consider how to handle multi-segment
spectra or time series, and SEDs.

<hr>
* IVOA.FelixStoehr - 02 Jul 2007

Dear all,

Currently, the !SpectrumDM states under section 5.3 Derived Data fields, Signal-to-noise:

"A suitable method, used by the !STScI MAST group, is to define the noise by the median absolute value of the difference between adjacent independent flux values in the spectrum. (The MAST definition multiplies this noise value by a 1.048 correction factor for precise applications)."

The !STScI(MAST)/ST-ECF/CADC Spectral Container Working Group has worked quite a bit on the algorithm and tested several possibilities. The final "best" algorithm is presented in the issue #42 of the ST-ECF Newsletter

http://www.spacetelescope.org/about/further_information/newsletters/html/newsletter_42.html

Implementations of the new algorithm can be obtained from:

http://stecf.org/software/ASTROsoft/DER_SNR/


As a suggestion, we propose to change the sentences cited above by:

"A suitable method, set forth by the !STScI/ST-ECF/CADC Spectral Container Working Group, is to define the signal as the median of the flux values in the spectrum and the noise as the median absolute third-order difference of flux values spaced two pixels apart. This noise value is then multiplied by 1.482602 / sqrt(6). Padded zeros in the flux values are skipped. A detailed description and discussion of the algorithm can be found in the issue #42 of the ST-ECF newsletter at www.spacetelescope.org/about/further_information/newsletters/html/newsletter_42.html. Implementations of the algorithm can be obtained from www.stecf.org/software/ASTROsoft/DER_SNR. We recommend to use this algorithm where suitable to allow meaningful cross-instrument searches."

Felix Stoehr

Adding a reference to a _recommended_ method for computing comparable SNRs is an excellent idea.  - IVOA.MarkusDolensky

For SNR, the essential point is that this value represents an overall
SNR for the entire spectrum; the SNR of individual spectral features will
vary of course.  There are various ways in which this could be computed.
I am not sure we are ready yet to standardize on a method for computing
the overall SNR, but it is reasonable to _suggest_ a technique such as that
mentioned above, so long as we have a good reference to some external paper
describing the technique.  - IVOA.DougTody

<hr/>
<hr>
* IVOA.MartinKuemmel - 13 Jul 2007
Dear all,

there is one point in the Spectral Data Model, which I do not
understand.

The specification for the fits serialization clearly says:
"The table represents a spectrum or photometry point as a single
row of a table." Within the "Hubble Legacy Project" we will start
to publish spectra in two weeks from now. The spectra are given out
as fits binary tables. Since we want to be VO-compliant, the spectra
are, as requested, in one row, each table element having several
entries.

Today I did a test on what I and our users can do with these spectra,
and plotted them with various tools. The simple "stsdas.sgraph"-task
can not plot them. Specview (version 2.14) can not plot them.
Splat-VO (version 3.7-0) can not plot them. Only VOspec was able
to plot these VO-compliant one-row tables.

I want to emphasize that this was not an error from my side
or just due to bad fits files or so. None of these tools had problems
plotting the spectra in the 'usual' format with one row per
spectral element.

Why does the VO-standard require us to publish spectra in a format
which can not be plotted, and therefore handled, by VO-tools
(as such I would name specview and SPLAT-VO)?

I have a very bad feeling that we produce and give out products
in a format which is difficult to handle by us and our users. 

Cheers,
Martin Kuemmel


Below is quoted from Ivo Busko, the Specview developer:


> Well, I cannot really answer that question for sure unless I get my hands on such a spectrum file. 
>
> But regardless of what happens when specview 2.14 is fed with such a file, it's a very simple matter to upgrade it in order to support one-row tables with IVOA-compliant data. In fact, this one-row format is already used by several data products that specview *can* read, such as STIS amd IUE spectra. because of its OO design, it's easy to reuse such code to handle data coming from VO servers.
>
> In fact, I would greatly appreciate if you can point me to such a file for testing purposes. I could work out possible problems before the release of specview 2.14.1 (which is planned tentatively for the upcoming Aug-Sept time frame).

-- IVOA.RoyWilliams

I've been in contact with Peter Draper, the SPLAT-VO author.  He too would like access to example data for testing purposes, though Martin is not willing to provide his for this purpose before his service goes live.  Given some test data it may be possible to upgrade SPLAT to provide at least partial support for this format in the reasonably near future, though I/he can't promise.  There are also the other serialization formats (VOTable, XML) recommended in the document, which SPLAT, and presumably other tools, do not support either.  In general it is bound to take some time for applications to catch up with any new VO format, all the more so where standards define multiple new formats at once. -- IVOA.MarkTaylor - 24 Jul 2007

<hr/>

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

Chairs should add their comments under their name.   

---+++ Mark Allen (Applications WG)
Approved

The Spectrum Data Model appears to contain all the pieces necessary 
to fully describe spectra as is needed in the VO. The examples are
especially useful as they will help guide usage in services and
applications.

---+++ Christophe Arviset (TCG vice Chair)
Overall the document is fine and I approve it, with the following comment:

Figure 3 (Diagram for Characterization object) and Figure 4 (Diagram for CoordSys object) should be checked to make sure they are compatible with the corresponding diagrams in the Characterization DM and STC specs. They look somehow similar but still rather different and these diagrams should be homogeinized accross these IVOA standards.

---+++ respons from IVOA.JonathanMcDowell
Christophe, I worked with the other Char authors to ensure compatibility. There are a couple of specializations for Spectrum but the Char here is essentially compatible with the PR version of Char.
For this and STC, we elected to establish an implementation to get Spectrum out there and used, prior to the adoption of the other standards. I don't think there is any semantic incompatibility, the same information is there.

---+++ Markus Dolensky (Data Access Layer WG, Vice Chair)

Approved.<br/>
From a DAL perspective the main point of splitting off the DM was to ensure that the SSA protocol is not only technically sound, but also satisfies the needs of interoperating plotting and analysis tools downstream. First implementations show that this has been achieved.<br/>
Many thanks to the numerous contributors throughout the years!<br/>
( _on behalf of Chair, Keith Noddle_ )

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

I approve this document with the following comment:

I wonder why a simplified instance of STC is preferred to just using the full STC structure for the <nop>CoordSys fields? 

The <nop>SpectrumDM is an abstract data model, with elements keyed by
UTYPE, which can be represented in a variety of formats or accessed
from within an application written in any language.  STC on the other
hand is pretty much tied to XML, which is a specific implementation
technology.  What we have tried to do is parameterize and define
UTYPEs for those few elements of STC actually used in Spectrum
and SSA.  We are trying to use the STC data model, rather than the
XML schema and serialization.   - IVOA.DougTody

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

I approve this document.

---+++ Gerard Lemson (Theory IG)
I approve this document, with a few comments.


That said, I would have liked that this document from the data modelling working group would have contained properly 
constructed UML diagrams. At the very least there should be some explanation of the meaning of the squares and 
connecting lines in the figures that likely are meant to represent such diagrams. A long time ago, in Cambridge 2003, 
we decided that UML was the prime language to present data models. XML was the one required serialisation method.
I urge the DM working group to try to come up with a uniform UML language to be used in the different documents 
coming out of this group, and if possible one that is formally defined and comprehensive. UML has an accepted way 
to do this in the form of UML profiles.

The only comment on the contents of the model I have is that I understand from X-Ray experts in our institute
that for X-Ray spectra to be published in a 
scientifically justifiable manner the current model may not be sufficient. They require that a reponse matrix 
comes with their channel data. I understand this is deemed to be part of a future version of the model, 
depending on "level 4 characterisation", but wonder whether we have to wait till such a general solution 
is offered by an other project.

I think the way UTYPEs are represented in the document is good and might be followed by other data model docuements. 
I think though that the precise manner how utypes are derived form a datamodel can likely be automated, 
especially in the case where a well constructed UML representation is available. But this is a discussion 
for later. The same btw is true for XML and other serialsations.
---+++ Mireille Louys (Data Models WG)
I approve this document with the following comment:
this version has been improved all along the period for comments , with a new version issued by Jonathan (link???).
We shall take special care in the next version of the standard for compatibility with other IVOA standards , especially the Characterisation subpart of this Model, but also access protocols.


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

---+++ Pedro Osuna (VOQL WG)
I approve this document. Please find below my comments to it, that I would like to discuss for future versions.

The document is very well thought-of and easily readable. The huge effort spent on it can be clearly seen. I think it is in the correct status for PR. Some minor comments, which don't constitute a showstopper for the PR approval in my view but which should be taken into account at som epoint, follow.


1.- In page 5, the rules for "Mandatory, Recommended", etc. are given as in other Data Model documents. I have this general comment: that the Data Model should not define what is Mandatory or otherwise, as it does not make sense in the context of a Data Model, but in the context of "Access" to that Data Model, i.e., in the DAL context. To illustrate what I mean with a small example, a "Person" mini-model with name (String attribute), height (double attribute) and address (a complex object of type Address) can represent a person. It can not be said that something is not a Person because it does not have a name. It might a priori seem necessary to know the name of a person ("mandatory" attribute) but, for instance, a statistics company making a survey of numbers of people working in Aerospace jobs in Spain (this would be the "protocol") does _not_ care about the name of the person. They only care about "how many" regardless of the attributes. In the other case, the "White Pages" collecting information about people living in Madrid would _certainly_ need to know their name and Address, regardless of. e.g., their height. While the NBA looking for basket players would probably only be interested in the Height regardless (initially) of the name or address.
In the context of the Spectrum DM/ SSA Protocol, the SSAP would define the Mandatory attributes for the protocol to work, while the Spectrum DM would just describe an abstract representation of a Spectrum. Even future Services (e.g., an eventual Crossmatch service) would define their own "mandatory" sets to be able to work with certain data. As can be seen, the Mandatory or Recommended nature appears when one "makes use of the data" and not for the qualification of the data themselves. Therefore, in my view, the Data Model group documents should avoid introducing Mandatory parameters in the models, and leave that to the Access Protocols.

2.- Page 7 desrcibes a UML for the SED. There are words like "SpectralCoord" and "Accuracy". I understand the former belongs to the STC and the latter to Characterisation. Should this be the case, it should be made clear. Otherwsie, an explanation of why it is not the case should appear clearer as well.

3.- Section 3.3. mentions UCDs as attribute identifiers. I think we have finally agreed on the issue of UFIs vs. UTypes and UCDs. Maybe some words on the distinction among them would be useful

4.- Section 4.6 on Position Coordinate should make explicit reference to STC, isn't it? (see comment 2.)
5.- Same as above in 4.7 with <nop>CharDM
6.- Same again in 5.1
7.- Section 7 should be reviewed. It mentions the Observation DM and the Quality DM which evolution is yet not clear. It is too lose a chapter that should either be expanded to tell how the different DMs interact or possibly removed until this is better clarified in a future. 

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

This is a well-written document.  I especially like the use of figures--not too overwelming!  I approve this document, if you fix the following:

Section 5.5, 2nd paragraph:  First, you should link to the [[http://www.ivoa.net/Documents/latest/IDs.html][Identifiers spec]]. Second, you need to clarify what you mean by this, or it can be interpreted in an a way that is incompatible with the ID spec.  That spec says that every IVOA ID must resolve to a resource registered in a registry.  I don't think this is what you intended.  You probably meant the ivo://auth/resid#localid form.  Technically, the IVOA ID is only that part up to the #.  Read the spec, and clarify what you mean.  

Next, many of the IDs given in the examples (all of the XML ids and many of the others) are not legal IVOA IDs.  Corrections or clarifications are needed. 

Ray, Jonathan, and I discussed this and concluded that "dataset
identifers" and their relationship to existing standards such as IVOA
resource identifers and authority IDs need to be more carefully specified.
This does not change anything we are doing, rather it is a clarification.
- IVOA.DougTody

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

I approve the document for Recommendation. My comments are expressed above.
---+++ Roy Williams (VOEvent WG)

This is a well-written, well-thought out definition of a spectrum, and the authors are to be congratulated. I approve it for Recommendation.

The examples may be all that a reader sees. They may read NONE of the text! Therefore these are important. After looking carefully, I find only two things worthy of note:

-- In the Characterisation section of example 7.2, the flux units are difficult to see, it says 
name="Flux density" ucd="phot.flux;em.wavelength" unit="erg cm**(-2) s**(-1) Angstrom**(-1)", and this is still not enough for me to see which kind of flux you mean. Perhaps a comment from Table 3 would help, it explains simply: "Flux density per unit wave", and now I am clear.

-- In the VOTable example 8.2, there are no schema locations for either
VOTable or <nop>SpectrumModel. This means that simply copying the example
does not allow XML validation.

--

Roy, I've uploaded a revised version of the document
which addresses these issues and one of the comments from Francois.
We should have some downloadable examples - there isn't a place for examples on the IVOA documents page, and there ought to be.

 - IVOA.JonathanMcDowell

Jonathan:  this would be a great subject of an IVOA Note.

-- IVOA.RayPlante - 12 Jul 2007


<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->


   * [[%ATTACHURL%/N8BR02T1Q_spec84A.fits][N8BR02T1Q_spec84A.fits]]: FITS serialization
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
fits	N8BR02T1Q_spec84A.fits	r1	manage	16.9 K	2007-07-25 - 11:47	MartinKuemmel	FITS serialization
This topic: IVOA > SpectrumDataModelRFC
Topic revision: r38 - 2007-07-25 - MartinKuemmel