IVOA Web>IvoaDAL>SpectralLineLists>SpectralLineListsDocs>SimpleSpectrumLineDMRFC (revision 13)~~EditAttach~~

SSLDM RFC Discussion

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.

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

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

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.

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"

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.

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

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

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

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.

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

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.

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

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

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.

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

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

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

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

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.

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

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

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.

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.

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

-- MasatoshiOhishi

Theory

TCG

TCG Review: Working and Interest Groups

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.