SSLDM RFC Discussion

TCG Review period: 12th May - 11th June

See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20100506/

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.

See http://www.ivoa.net/Documents/SSLDM/20090714/

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.

SSLDM"> 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:
  • a clause that defines each variable (e.g. "where B is the magnetic field"),
  • a reference to published literature where the formula is discussed, or
  • (preferably) both.
  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.

Editors' input: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.

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

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

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

Editors' input: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.

Editors' input: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.

Editors' input: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"

Editors' input: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.

Editors' input: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

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

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

s2.1.3, p.8-12

Which of these attributes can be provides as instances of "PhysicalQuantity"?

Editors' input: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

Editors' input: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.

Editors' input:Done.

s2.1.3.12, p.10, Line.weightedoscillatorStrength

please insert cross-references to s2.1.3.11 and s2.1.3.2.

Editors' input: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 N_k). If this is so, can we state this explicitly (say, as the last sentence of the first paragraph); e.g:

When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.

Editors' input: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)"

Editors' input:Done.

s2.1.3.21, p.12, Line.observedShiftingCoefficient

Change "type=Energy shift" to "Process.type=Energy shift (sect. 2.1.8.1)"

Editors' input: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.

Editors' input:Done (see before)

s2.1.5.4, p.14, Level.lifeTime

Should this be described explicitly in terms of an e-folding time?

Editors' input: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.

Editors' input: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".

Editors' input: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"'.

Editors' input: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.

Editors' input: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?

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

s.4.1, p.23, Table 1 caption

fix spacing error

Editors' input: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.

Editors' input: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.

Editors' input:Numbers removed.

-- RayPlante - 16 Sep 2009

---

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

Editors' input: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

-- MasatoshiOhishi

Theory

TCG

---

TCG Review: Working and Interest Groups

TCG Review period: 12th May - 11th June

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

Data Access Layer

Data Modeling

Grid & Web Services

Resource Registry

Semantics

I approve this document. SD.

VO Event

VO Query Language

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 DocStds document.

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.

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

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.

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.

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.

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

Theory

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.

A few other minor comments:

• as agreed, in the abstract, please add the link to the newly agreed IVOA Architecture
• in the references section, UCD should be 1.23 instead of 1.10
• in the references section, SSAP should be 1.04 instead of 1.4

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

ChristopheArviset - 25 june 2010