SimpleSpectrumLineDMRFC < IVOA

IVOA Web>IvoaDAL>SpectralLineLists>SpectralLineListsDocs>SimpleSpectrumLineDMRFC (2010-11-03, RayPlante) (raw view)
---+ SSLDM RFC Discussion
%RED% *TCG Review period: 12th May - 11th June* %ENDCOLOR%

See the PR latest revised version at: 
http://wiki.ivoa.net/internal/IVOA/SimpleSpectrumLineDMRFC/PR-SSLDM-1.0-20101015.pdf
 
Review period: 2009 July 21 – 2009 September 15 (Extended!)

July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. 



---++ SSLDM Use Case:
The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface. 

---++ SLAP Implementations using SSLDM:
   * *SLAP Server Name: IASD*
      * Type: Observational
      * Publisher: ESA
      * Service Description: SLAP Access to ISO Astronomical Spectral Lines Database
      * Contact: ESA-VO team
      * Spectral Coverage: IR
      * Number of Records: 300 transitions
      * Comment: Client: VOSpec

   * *SLAP Name: LERMA*
      * Type: Theoretical
      * Publisher: Observatoire de Paris
      * Service Description: LERMA SLAP access to the CDMS and JPL molecules correlated to the Basecol database
      * Contact: N. Moreau & M.L. Dubernet
      * Spectral Coverage: millimetric, sub-millimetric
      * Number of Records: 37500 transitions
      * Comment: Client developed by N. Moreau

   * *SLAP Name: NIST*
      * Type: Observational
      * Publisher: National Institute of Standards and Technology
      * Contact: Yuri Ralchenko
      * Service Description: SLAP Access to NIST Atomic Spectra Database
      * Spectral Coverage: Multiple Coverage
      * Number of Records: 144000 transitions

   * *SLAP Name: CIELO*
      * Type: Observational
      * Publisher: ESA
      * Service Description: SLAP Access to XMM-Newton observed spectral lines from CIELO Database
      * Contact: M. Guainazzi & the rest of ESA-VO team
      * Spectral Coverage: X-Ray
      * Number of Records: 2700 transitions

   * *SLAP Name: CHIANTI*
      * Type: Observational
      * Publisher: Astrogrid using ESAVO DALToolkit
      * Contact: Kevin Benson
      * Service Description: A database for astrophysical emission line spectroscopy 
      * Spectral Coverage: Multiple Coverage

---++ SLAP-like Implementations using SSLDM:
   * *SLAP Name: ALMA internal SLAP*
      * Type: Observational
      * Publisher: ALMA Archive Group at The University of Manchester
      * Contact: Stewart Williams, Andrew Markwick-Kemper, Sandra Etoka & Gary Fuller
      * Service Description: Internal SLAP services to propagate line list within the project. IVOA spectral line list data model used in database schema
      * Spectral Coverage: Radio
      * Client: Splatalogue    
      * Not fully compliant reason: It contains unidentified lines


---++ Comments:

---++++ Ray Plante

In general, I feel this data model is fairly complete (and fun to read).  My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples.  Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions.  

To start with, here are some general comments:

   * Anywhere there is a formula, it's important to give a full explanation in one of the following forms:
     <ul>
      <li> a clause that defines each variable (e.g. "where B is the magnetic field"), 
      <li> a reference to published literature where the formula is discussed, or 
      <li> (preferably) both.
     </ul> There are places where this is done perfectly (2.1.5.3); other places seem to assume a standard knowledge (2.1.3.19).  In this latter case, it may be distracting too spell out the entire formula, particularly when certain ones would be obvious to anyone whose taken a physics class (e.g. ''c'', ''h''), so simply giving a reference should be sufficient.  The references (with Rybicki and Lightman, Drake, and Condon/Shortly) seem sufficient to do this.  Such references will provide a means for working out ambiguities that we or users may discover later.  

%BLUE%Editors' input:%ENDCOLOR%Definitions have been included in those places where there was no explanation, and components of the formulae have been described (except for common ones like c,h, etc.). Environment variables, being such common definitions (temperature, pressure, mass, etc.) have not been included explicitly though.



<ul>
   <li> In several places, the document cites the commonly used quantum numbers, e.g. J, M, S, etc., but don't actually explicitly indicate that these are their meanings.  I think it would be worthwhile to add a paragraph that defines the subsequent use of these quantum numbers in formulae.  It's not necessary to give a full, from-first-principles explanation, but just enough context (and a reference!) to relate the variable names to their common usage as quantum numbers.  I'm envisioning something like the following inserted after (or at the end of) the 3rd paragraph on p.5:

<blockquote> 
In the definitions of attributes for these concepts, we have adopted the common convention for quantum numbers used by [ref]; that is, where _[insert bulleted list from sect 2.1.6.3. with cross-references to appropriate definitions within sect. 6]_.  We note, however, that an instance of this model can explicitly define the use of these quantum number variables by linking them to their physical definitions (sect. 6).  
</blockquote> 

In the absence such a paragraph, one can merely provide an explicit explanation every place the variable is used (e.g. "where _J_ is the angular momentum quantum number (sect. 6.4.11.)")</li>
</ul>

%BLUE%Editors' input:%ENDCOLOR%A note has been included at the introduction on Quantum numbers. Quantum Numbers have been moved from an appendix to a chapter (chapter 4) and cross-references to the relevant item numbers for the most commonly used Quantum Numbers have been added there.


   * In general when a concept definition invokes another concept defined in the model, an explicit cross-reference would be very helpful.  

%BLUE%Editors' input:%ENDCOLOR%Done.

   * Be sure that every concept is explicit about the data type associated with the value that can be given; in particular,
      * indicate explicitly which concepts may be represented by a "PhyscialQuantity" (or equivalent future model).  Some numeric values--namely quantum numbers should not be represented as a "PhysicalQuantity"; let's be explicity about this.  What about coefficient quantities?
      * indicate which are represented by other object classes defined in the document and give the cross reference.  

%BLUE%Editors' input:%ENDCOLOR%All data types have been included in each of the attributes following them with a colon. A specific summary table has also been created for ease of reference.



And now for the some specific notes...

   $ Abstract:  I recommend some word-smithing for clarity:
      * Change "represents a proposal" to "presents" (reflecting the fact that after this is a REC, it's no longer a proposal).  
      * Change "deal with the" to "provide a"
      * Change "scope is outside" to "is out of the scope"
      * Change "deal with" to "describe"

%BLUE%Editors' input:%ENDCOLOR%Done.

   $ p.6, figure:  class attributes in the figure do not match the text.

   $ s2.1.1.1, p.7:  What is "General Number format"?  Please define.  

%BLUE%Editors' input:%ENDCOLOR%Removed.


   $ s2.1.2.3, p.8:  Please be explicit as to the syntax for the dimensional formula; otherwise this is really a syntax defined by example.  In particular, indicate that:
      * an integer indicates a power that the preceding dimensional symbol is raised to
      * that the concatenation of dimension-power tokens imply multiplication
<dl><dd>Also, I don't recognize "sustracted" as a word; is it a typo?  (Anyway, the clause should be dropped as it does not help to define the syntax.)</dd></dl>

%BLUE%Editors' input:%ENDCOLOR%Done. "Sustracted" removed. Whole point clarified.


   $ s2.1.3, p.8-12: Which of these attributes can be provides as instances of "PhysicalQuantity"?

%BLUE%Editors' input:%ENDCOLOR%As said before, all attributes' definitions include now their type.


   $ s2.1.3.2 and s2.1.3.3, p.9, Line.initialLevel, Line.finalLevel:  indicate that the value can be given as a "Level" as defined in sect. 2.1.5

%BLUE%Editors' input:%ENDCOLOR%Done.


   $ s2.1.3.11, p.10, Line.oscillatorStrength:  Can we start this section with a general, single-sentence definition (that indicates that it is a floating point number)?  e.g. "A dimensionless number that quantifies the strength of the transition."   Please define all symbols in the formulae, and provide a reference.  

%BLUE%Editors' input:%ENDCOLOR%Done.


   $ s2.1.3.12, p.10, Line.weightedoscillatorStrength:  please insert cross-references to s2.1.3.11 and s2.1.3.2.  

%BLUE%Editors' input:%ENDCOLOR%Done. Model attributes referenced have been highlighted in Courier font to represent attribute within the model.


   $ s 2.1.3.13, p.10-11, Line.intensity:  I surmise from the text that given that there is no common scale for relative intensities, the usefulness this attribute is when several are given for different "Line"s and it can be assumed that the arbitrary scale is the same for all of them (i.e. the same <i>N<sub>k</sub></i>).  If this is so, can we state this explicitly (say, as the last sentence of the first paragraph); e.g: 
<blockquote>
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.  
</blockquote>

%BLUE%Editors' input:%ENDCOLOR%Done.


   $ s2.1.3.20, p.12, Line.observedBroadeningCoefficient:  Since Process had not been discussed yet, I didn't know what "type=" refered to.  Change "type=Broadening" to "Process.type=Broadening (sect. 2.1.8.1)"

%BLUE%Editors' input:%ENDCOLOR%Done.


   $ s2.1.3.21, p.12, Line.observedShiftingCoefficient:  Change "type=Energy shift" to "Process.type=Energy shift (sect. 2.1.8.1)"

%BLUE%Editors' input:%ENDCOLOR%Done.


   $ s2.1.5.3, p.13, Level.landeFactor:  Please indicate somehow the meaning of J, L, and S as discussed in the general comments above.  

%BLUE%Editors' input:%ENDCOLOR%Done (see before)

   $ s2.1.5.4, p.14, Level.lifeTime:  Should this be described explicitly in terms of an e-folding time?

%BLUE%Editors' input:%ENDCOLOR%Lifetime is a very general concept, and when it comes to definitions it can be described in several ways. E-folding time is one, another one is related to the inverse of all the transition probabilities of all levels of energy lower than a given one (Einstein coeffs.). Therefore, it looks better to not to restrict the definition despite the risk of comparing different theoretical concepts. It however looks reasonable to consider that however they are measured, lifeTimes described here should be somehow comparable. This could be discussed further but for this version has not been included.


   $ s2.1.5.10, p.15, Level.configuration: please insert cross-reference to quantum number definition sections.  

%BLUE%Editors' input:%ENDCOLOR%Done.


   $ s2.1.6.1, p.15, !QuantumState.mixingCoefficient:  is it really important to indicate that the value is a "double" (which is ostensibly a computer platform-specific concept); perhaps it is better to call it a "real number" or a "floating-point number".  

%BLUE%Editors' input:%ENDCOLOR%Double removed. Not anymore relevant.


   $ s2.1.9.2, p.18, Environment.opticalDepth: Change '"initialLevel"' to '"Line.initialLevel" (sect. 2.1.3.2)'; same for '"finalLevel"'.  

%BLUE%Editors' input:%ENDCOLOR%Not anymore relevant.


   $ s2.1.10.3, p.20, Source.coordinates:  Can we be more explicit as to the STC model utype (e.g. !AstroCoord).  Consult with Arnold.  

%BLUE%Editors' input:%ENDCOLOR%To be discussed with Arnold and in a wider level at IVOA. Probably should not mean a showstopper for this release.


   $ s.4.1, p.23:  is there a formating error with this section number?

%BLUE%Editors' input:%ENDCOLOR%Sections have been reshuffled for ease of reading. Probably not relevant anymore.


   $ s.4.1, p.23, Table 1 caption: fix spacing error


%BLUE%Editors' input:%ENDCOLOR%Probably not relevant anymore.


   $ s6, Appendix B:  I'm not sure it is appropriate to label this section as an appendix as the definitions are as central to the model as the preceding ones.  I would recommend moving this prior to the "Working examples" section.  

%BLUE%Editors' input:%ENDCOLOR%Changed to Chapter 4.


   $ s5, s6, s7, appendices:  If these are to be appendices, then its a bit confusing (at least for the purposes of cross-referencing) to label the sections with both numbers and letters.  I suspect that this is an artifact of the word processing tool used and the styles employed.  Preferably, section 7.1 should really be labeled "C.1".  It's not a big deal, though.  

%BLUE%Editors' input:%ENDCOLOR%Numbers removed.


-- IVOA.RayPlante - 16 Sep 2009

<hr/>

---++ RFC period comments from Working and Interest Groups 

---++++ Applications

---++++ Data Access Layer

---++++ Data Modeling

---++++ Grid & Web Services

---++++ Resource Registry

---++++ Semantics   

---++++ VO Event   

---++++ VO Query Language   

---++++ VOTable

---++++ Data Curation & Preservation

---++++ OGF Astro-RG

Question translated from SLAP RFC pages:

(4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O).

%BLUE%Editors' input:%ENDCOLOR%Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand.
Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference:

http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html
http://www.astro.uni-koeln.de/cdms/catalog

-- IVOA.MasatoshiOhishi


---++++ Theory

---++++ TCG


<hr/>
---++ TCG Review: Working and Interest Groups
%RED% TCG Review period: 12th May - 11th June %ENDCOLOR%

Note that the space for RFC comments from the working groups was intended to spur early review of the document.  A formal approval is still requested from each of the WG and IG heads.  
---++++ Applications

One tiny nit.  In section 3.1 there is a reference to "per the DM dicussion".    RFC documents should not reference DM (or any other) discussions: these are standards documents and stand on their own or reference other documents of equivalent permanence.  So this should reference the appropriate standard, or if there is no such standard, it should simply be presented as a non-normative element of this standard.

%BLUE%Editors' input:%ENDCOLOR%Sentence removed and overall paragraph refurbished slightly.


One larger concern:  This document defines a standard which goes beyond the ambit of astronomy into physics and chemistry.  Some discussion of the existence of relevant standards from those communities might have been desirable.  

%BLUE%Editors' input:%ENDCOLOR%The research was certainly done. One of the authors, Marie Lise Dubernet, did an extensive survey of relevant standards within the community of Atomic and Molecular Physics, and several of the authors did meet relevant parties on the fields where discussions were celebrated.


I raise these issues more for discussion in the future in potential revisions to this document and other standards rather than suggesting a change need be made in the current version or this standard.

%BLUE%Editors' input:%ENDCOLOR%Note taken

I approve the document as it stands. 

-- IVOA.TomMcGlynn October 8, 2010

---++++ Data Access Layer

In Sec 3.2.3 (p. 15), the example of PhysicalQuantity for 3500 Jansky has values 
from Angstrom example above

%BLUE%Editors' input:%ENDCOLOR%Example modified to match properly


Section 8 is titled "Appendix B: ...", but there is no Appendix A in the ToC. There are references 
to "Appendix A" (3.4.1) and "Appendix C" (3.5.3, 3.6.3). Also, some places just refer to 
"see appendix" (3.5.1). There is some plain text on p 68 that seems to be the start of 
Appendix A, buried in the middle of section 7. There is no Appendix C.

%BLUE%Editors' input:%ENDCOLOR%Appendix A exists but it lost its "Heading 1" type, therefore was lost in the TOC. References to the Appendices have been reviewed, and all corrected (as well as anchor links to relevant places within the doc). 

For references 13, 14, and 15 (to other IVOA documents) the reference seems to be (safely) 
to a specific existing version, but the links are to the latest versions, which may change
in the future. It may be better to link to specific versions of the standards, at least in
cases where the other standard is used rather than just informative.

%BLUE%Editors' input:%ENDCOLOR%Links modified to point to the version specified within the reference.

Small note: the link in reference [14] has the final "l" in "html" outside the anchor (at least, it
is displayed black instead of blue for me).

%BLUE%Editors' input:%ENDCOLOR%Corrected

-- IVOA.PatrickDowler October 14, 2010

Small issues: The text on p 10 (under the IVOA architecture diagram) mentions SpectrumDM when I think it is intended to be SSLDM.

The document does not explicitly say this, but I assume that the subsection headings in 3 are (parts of) utypes (and data types) for SSLDM. This is at least implied by the structure of the headings. In some cases one would have to infer the utype where a higher level construct re-uses another. For example, Line.initialLevel is a Level,  Level.energy is a PhysicalQuantity and PhysicalQuantity.value is numeric, which implies a utype of Line.initialLevel.energy.value. Is that correct? Should the connection to utypes be stated somewhere, eg at the start of Section 3?

Approved
-- IVOA.PatrickDowler October 15, 2010




---++++ Data Modeling
Minor comments:
   * In the abstract, could you  specify the kind of levels considered like : "In the astrophysical sense, a line is considered as the result of a transition between two levels __of energy__." or another formulation just to be more didactic in the abstract...

%BLUE%Editors' input:%ENDCOLOR%Energy added.

   * I accidently came to a  typo just in section 3.3.1  in the example: hiperfine --> Hyperfine.

%BLUE%Editors' input:%ENDCOLOR%Corrected.


I approve this document and agree for the next step :IVOA recommendation.

-- IVOA.MireilleLouys October 15, 2010

---++++ Grid & Web Services

The formatting seems to be a bit of an issue 

%BLUE%Editors' input:%ENDCOLOR%See editor comment's below (on Data Curation and Preservation section).

and it would be useful to see some XML serialization, for example, those of the JSON representations;

%BLUE%Editors' input:%ENDCOLOR%Serialisations could be added in a further version or as a support document.


 otherwise I approve this document.

--IVOA.MatthewGraham - 16 Jul 2010



---++++ Resource Registry

I approve this document.  Thanks for the changes and my deepest regrets for the long delay.  -- IVOA.RayPlante - 03 Nov 2010



---++++ Semantics   

I approve this document. SD.

---++++ VO Event

Approved -- IVOA.RobSeaman - 9 Sep 2010

---++++ VO Query Language   

I approve this document -- IVOA.PedroOsuna 15 Oct 2010

---++++ VOTable

---++++ Data Curation & Preservation

I was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult.  First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents.  This is something we will have to make explicit in the next version of the <nop>DocStds document.

%BLUE%Editors' input:%ENDCOLOR%Change log with changes after TCG comments on RFC has been added.

The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version.  But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1.  The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated.  The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels.

%BLUE%Editors' input:%ENDCOLOR%Section numbering reviewed. 4th level hierarchy removed.

In the Abstract, the reference to the SLAP document is missing.

%BLUE%Editors' input:%ENDCOLOR%Reference to SLAP added.


There is something odd in the typography of the math symbols.  For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts.  I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings.  I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems.

%BLUE%Editors' input:%ENDCOLOR%Equations rewritten where necessary to avoid floating issue.


The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version.  In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting.

%BLUE%Editors' input:%ENDCOLOR%TOC changed to include section numbers.


The use of a sans serif font causes confusion in some sections, such as 4.3.x.  An uppercase I and a lowercase l are indistinguishable.  With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times.

%BLUE%Editors' input:%ENDCOLOR%Font changed from Arial to times New Roman everywhere to solve issue.

I have no comments on the correctness or not of the atomic physics.  It is mainly the presentation and the traceability back to earlier versions that concern me.

BobHanisch  28 May 2010

I appreciate the effort put in by Pedro to fix the many formatting problems and equations.  I endorse going forward at this point.

BobHanisch  7 October 2010

---++++ Theory

Approved. 

HerveWozniak - 18 October 2010


---++++ TCG

The document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples.

I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers).
Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version.
But I believe that for the final REC version, the change log should be removed.

%BLUE%Editors' input:%ENDCOLOR%See above. Change log included, to be removed when final Recommendation is agreed.

A few other minor comments:

   * as agreed, in the abstract, please add the link to the newly agreed IVOA Architecture

%BLUE%Editors' input:%ENDCOLOR%Architecture added in Introduction rather than in summary to avoid conflicts with future abstract display (e.g., in ADS).

   * in the references section, UCD should be 1.23 instead of 1.10 

%BLUE%Editors' input:%ENDCOLOR%Modified.

   * in the references section, SSAP should be 1.04 instead of 1.4

%BLUE%Editors' input:%ENDCOLOR%Modified.

Assuming these points will be addressed for the final version, I approve the document.

ChristopheArviset - 25 june 2010

Thanks to Pedro for all these corrections. As said before, I approve the document

ChristopheArviset - 06 September 2010

<br/>
<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
pdf	PR-SSLDM-1.0-20101004.pdf	r1	manage	2013.0 K	2010-10-05 - 11:32	PedroOsuna
pdf	PR-SSLDM-1.0-20101015.pdf	r3 r2 r1	manage	2025.5 K	2010-10-15 - 11:40	PedroOsuna
Topic revision: r35 - 2010-11-03 - RayPlante
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
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema