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:

BobHanisch (9/10/09)

Abstract: The text here is very tentative (“could be too simple...” “will be studied in this document”) and inappropriate for an Abstract, and in particular inappropriate for a standards document. Define the standard and express restrictions and caveats as footnotes or appendices.

Overview: Add citation for SSLDM document. [1] in reference list. In the second paragraph, remove the tentative language (“intended to be”).

Section 3, 3rd paragraph: what is intended by “must/should/may”? This paragraph is very confusing, suggesting that a MUST parameter could be non-compulsory, for example. It might be clearer, combined with the next paragraph, as “This document describes standard query parameters for SLAP services. Some SLAP services might make use of extra parameters, not cited in this document, to support additional filtering and selection.”

Section 3, last paragraph, wording would be better as “Since it is awkward to compile all such extra parameters in a document such as this one, a general mechanism is described. As will be explained later, the discovery of these extra parameters by VO client applications or by the registry relies on an implementation of the format=metadata input parameter. The exact expected response when this parameter appears in the query will be discussed in Section 5.”

4.1 The text and formatting make it very confusing to discern the two parts of the URL. The description of the base URL should be more clearly separated from the description of the constraints, with the same indentation and bullet style. The first sentence should be complete and stand-alone, as in “A URL with two parts is used to transmit the spectral line query as an HTTP GET request.” Then,

1) A base URL...

2) A set of constraints expressed as...

The final example line in this section is written as if it is a legal form of query constraint, which I don’t think it is.

4.2 In the definition of REQUEST, I think “server” should be “service”. “Valid values for SLAP” should be “Valid values for REQUEST are”

I’d suggest, instead of “To have backwards compatibility with older SLAP implementations, if the REQUEST parameter does no appear in the query, the default value is queryData (see example of use in next section)” writing “If the REQUEST parameter does not appear in the query, the default value is queryData.” [Again, this is a specificaiton of a standard... it does not need reasons and rationale for everything, just the facts.]

Similarly, I would delete “The use of REQUEST is mandatory to provide upwards compatibility with future versions.” First, there is no need to explain why, and second, how do you know what future versions of the specification will have as mandatory?

In the last sentence of 4.2, delete “If desired,” and delete the comma midway through the sentence.

4.3 Section title should be “Compulsory Parameters”. The subsequent text is repetitive. Make the first sentence to the point. “The service MUST support the WAVELENGTH parameter, defined as:” In the actual definition, replace “in the vacuum” with “in vacuum”.

4.4 In the paragraph beginning with “Energy Level range” I think “compliant” should replace the word “compulsory”. In the explanation of TEMPERATURE, “score” is probably not the right word. “Sort”? “Rank”? “Order”?

In the explanation of PROCESS_NAME, the “next point” should be “next section”. There is also a typo in “redshift”.

4.5 Instead of “Free query parameters”, perhaps “Additional query parameters”? Again, I think “score” is not quite the right word here. See above.

“...will be studied in the next section” should be “...will be defined...”.

“construct on the fly a form” would be better as “dynamically construct a form”

I would delete the last paragraph in 4.5 as it is about uses of the registry and not germane to the definition of SLAP.

5 I think there is continued mixing of registry and SLAP issues here and that this could be simplified.

“Simple Spectral Line services advertise their availability by registering with a registry service, which may provide the mechanisms to fully characterize the service including its non-compulsory and additional parameters. Alternately, the FORMAT=METADATA parameter or REQUEST=getCapabilities can be used to ascertain the service’s full capabilities.”

Use consistent spelling of “implementer”, here and elsewhere.

5.2 Is this needed in this document at all? I’d drop it, and then merge 5.1 into 5.

6. Add citation [6] to VOTable. Item 1, “addition” --> “additional” Item 4, “the following UCDs” suggests that a list follows immediately, but it doesn’t. I think this refers to Section 6.1.

6.1 “in the vacuum” --> “in vacuum”.

slap.QueryScore, as noted above, I think a term like “rank”, or perhaps “relevance”, would be better. Not sure if people have used this already; if so, I would not push very hard for this change. “sorter” --> “sorted”

Further down (p. 15 in the .doc version), “LATEX” should be “LaTeX” and “convection” should be “convention”. A citation to the LaTeX manual needs to be provided. (Leslie Lamport, “LaTeX: A Document Preparation System.” Addison-Wesley, 1986)

p. 16, “enclosed by squares” --> "enclosed by square brackets”

p. 17, top, “previous point” --> “previous section”

Did not read Apps. B, C, and D.

Ray Plante

Abstract, p.2, last sentence.

a bit of word-smithing for style:

consider collapsing text into a single paragraph
consider rewriting (what is now) the last paragraph:

Thus, an implementation of the service may support additional search parameters (some which may be custom to that particular service) to more finely control the selection of spectral lines.

Contents, p.3: Entries "UTYPE" through "Size" seem spurious.

s1, p.3, Overview: I think it would be useful to add some words that explicitly call the consistency with SSAP via the adoption of current conventions for DAL service interfaces. Perhaps something like this:

The SLAP interface has intentionally been made similar to that of SSAP and SIAP (v2.0) through the adoption of current IVOA Data Access Layer conventions, including:

queries encoded as URLs

the use of standard input parameters, REQUEST and VERSION,

the syntax for specifying numeric ranges and value lists,

the use of VOTable for encoding search results,

the mechanism for handling errors, and

the retrieval of service metadata.

-- RayPlante - 16 Sep 2009

RFC period comments from Working and Interest Groups

Applications

Data Access Layer

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

-- JesusSalgado & AurelienStebe 10-Sep-09

Data Modeling

Grid & Web Services

Resource Registry

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.