IVOA Web>IvoaDAL>SpectralLineLists>SpectralLineListsDocs>SimpleSpectrumLineDMRFC (revision 11)~~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 to 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 of a variable's use (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.
- indicate which are represented by other object classes defined in the document and give the cross reference.

And now for the some specific notes...

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