Difference: SimpleLineAccessProtolRFC (12 vs. 13)

Revision 132009-09-10 - JesusSalgado

 
META TOPICPARENT name="SpectralLineListsDocs"

SLAP RFC Discussion

Review period: 2009 July 21 – 2009 September 15 (Extended!)

July 20, 2009 Page created to encapsulate the discussion of the Simple Line Access Protocol RFC process

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

SLAP Use:

The purpose of the Simple Line Access Protocol is to allow the comsuption of Spectral Line List databases using a common/standard interface. The most basic query parameters will be the minimum and maximum value for the wavelength range. Additional parameters may be used to refine the search or to model physical scenarios.

SLAP Implementations:

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

The following list corresponds to SLAP like implementations, not fully compliant due to different reasons:

  • SLAP Name: STSCI SLAP
    • Type: Observational
    • Publisher: STSCI
    • Contact: Randy Thompson
    • Service Description: SLAP prototype of HST lines using ssa data model
    • Spectral Coverage: NIR-Optical
    • Not fully compliant reason: It makes use of Spectral Data Model utypes

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

RFC period comments from Working and Interest Groups

Applications

Data Access Layer

Added:
>
>
  • Although errors are something that should be described in a more general DAL architecture document and to have a self-consistent document, error section to be added as per TAP specification
 
Added:
>
>		 -- JesusSalgado & AurelienStebe 10-Sep-09
 

Data Modeling

Grid & Web Services

Resource Registry

Added:
>
>
  • VOResource extension schema has been created and uploaded to IVOA pages
http://www.ivoa.net/xml/SLAP/SLAP-v0.1.xsd

  • Registration section to be updated as per SSA specification

-- AurelienStebe & JesusSalgado 10-Sep-09

 

Semantics

VO Event

VO Query Language

VOTable

Data Curation & Preservation

OGF Astro-RG (MasatoshiOhishi)

First of all I would like to express appreciation to the authors of this document. And I have some comments as follows:

(1) In section 4.3, WAVELENGTH is designated as a compulsory parameter, which I agree. However, it is not common in the radio or submillimeter range to use wavelength. The common practice for radio astronomers is to use "frequency" rather than "wavelength". I would suggest to add "frequency" as another compulsory parameter. In this case MHz/GHz(/THz) need to be added as allowed "units".

(2) Section 4.4, Energy Level range; I think the units for the energy levels should be more flexible. In the X-ray region it is common to use eV (keV, MeV, etc.). Similarly, wave number (cm-1) is also used in the IR region. In many cases it is very convenient to express the energy levels in Kelvin or in MHz.

(3) Section 6. If we add FREQUENCY as a compulsory parameter, we need to update this section, too.

(4) Page 16, 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

Replied by JesusSalgado

  • First, thanks for your comments.

  • Point (1); this possibility was discussed within the authors in the past and it was agreed that, in order to maintain the query interface simple in the communication client-server, the translation from the wavelength range input in SI units to the original data provider units can be done more easily at server part. That allows to send the same query to all the different SLAP servers. However, in the response, we allow different fields in different units so the data provider can publish magnitudes in the units defined in the specification and in their original units (sometimes more adequate for the type of data or more precise)

  • Point (2), same reply as before. In the query interface we ask for a single unit set (always SI) and we allow different fields in different units in the response. The authors agree that, in some cases, the election of SI is not the usual one for some magnitudes like, e.g., energy levels, but it provides a documented/unique units reference system.

  • Point (3), we will modify the specification to add frequency and wavenumber as optional output fields so the specification mentions, explicitely, the previously mentioned feature for this particular case.

  • Point (4), I have translated this question to the SSLDM RFC page in your name, so we have the support of the data model experts on this.

-- JesusSalgado - 03 Sep 2009

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. I [TAM] have noted cases where the RFC comments seemed to indicate an approval in the RFC period but the appropriate chairs should review this final draft.

Applications

Data Access Layer

Data Modeling

Grid & Web Services

Resource Registry

Semantics

VO Event

VO Query Language

VOTable

Data Curation & Preservation

OGF Astro-RG

Theory

TCG 


<--  
-->

META FILEATTACHMENT attr="h" comment="SLAP v1.0 14July2009" date="1247497795" name="PR-SLAP-1.0-20090714.pdf" path="C:\Documents and Settings\jsalgado\Desktop\PR-SLAP-1.0-20090714.pdf" size="191457" user="JesusSalgado" version="1.1"
View topic | History: r40 < r39 < r38 < r37 | More topic actions...
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback