european space astronomy centre (esac) villafranca del castillo, madrid (spain) jesús salgado...

European Space Astronomy Centre (ESAC)Villafranca del Castillo, MADRID (SPAIN)Jesús Salgado

Simple Line Access Protocol May 2006, Victoria, Canada

(1/ 11)

SLAP: Simple Line Access Protocol v0.5

(Current Status)

Jesús Salgado*

Pedro Osuna*, Matteo Guainazzi*, Isa Barbarisi*, Marie-Lise Dubernet**

* ESA/VO - European Space Astronomy Centre (ESAC)

** VO/France – LERMA, Observatoire de Paris



(2/ 11)Summary of activities

It was agreed during the interop meeting at Kyoto to start some work in Spectral Lines database access

Three different works started in coordination:• Definition of a Spectral Line Data Model• Definition of a Simple Spectral Line Access Protocol (SLAP)• Reference implementation: Server (IASD) and Client (VOSpec) to

control the usability of the protocol and the data Model First version of the data Model, protocol definition and reference

implementation were presented during last interop at ESAC Interesting comments during the presentation and in the IVOA DAL

forum. Many of them included directly in the document (to all the people who have sent inputs, thank you!)



(3/ 11)SLAP Overview

VOTable, one spectral line per row

λ range is compulsory

A SIAP-like URL service, would allow an easy implementation for all spectral line providers



(4/ 11)Inputs during last interop

Why to use wavelength in as the main query instead of frequency? Arguments to make the change:

• Comparing ground based spectra, scientist could have wrong conclusions about a possible redshift

• Frequency does not depend of media Arguments against the change:

• Laboratory wavelength in vacuum is, at the end, same as frequency• SSAP/SED Data Model should provide a mechanism to correct

ground based spectra air wavelengths. Difficult automatic corrections• In case of real redshift, the SED could be corrected using the redshift

(included in the SED data Model) before the comparison or it can be even calculated via comparison between SED and Spectral Lines from SLAP

Not changed for the time being, but there are not strong objections to change it, if necessary



(5/ 11)Internal inputs from the authors

Why temperature has preferential treatment in the inputs definition (as it appears specifically) to e.g. density, pressure or metallicity? Link to Environment object in the spectral line data Model. • Temperature appears in the SLAP document as an example of one

query filter condition. Any quantity in the spectral line data model Reference added in the SLAP document Change units in the document to SI, in particular for the wavelength

to meters Changed Add A-coefficient as a possible input parameter to prevent people to

retrieve lines not strong enough Added



(6/ 11)Inputs from DAL forum

INITIAL_LEVEL_ENERGY and FINAL_LEVEL_ENERGY have UCD “phys.atom.level”. Shouldn’t we use the “phys.atmol.level” instead? (N. Moreau)

Changed Utypes Line.initialLevel.name and Line.finalLevel.name appears in SLAP but

attribute “name” is not present in spectral Line Data Model for Level (N. Moreau)

To be added in the Spectral Line Data Model Initial_Level_energy and final_energy_level have “int” as datatype.

Shouldn’t be double? (N. Moreau) Typo changed Is it really useful to have a “title” attribute for each line? A line is described

by its other attributes (N. Moreau)• Not all the attributes will be present in all databases. Clients will be forced to

create on-the-fly descriptions of the lines using the metadata present in the results (difficult implementation at client side and trivial at server side)

• String representations for rows are used in all the simple access protocols Title field NOT demoted to optional



(7/ 11)Inputs from DAL forum (II)

As per RFC 2119, Must/Should/May should be used in the document (Doug Tody)

Document changed to be compliant to the RFC convention Ranges definition using “<“, “>” produce not “valid” URLs (Doug

Tody)• Doug Tody, as DAL chairman, and the rest of the DAL group have

and action to define a standard mechanism to define ranges in URLs to be used in DAL protocols

• Approach in previous SSA spec is define ranges with commas, in the following way: WAVELENGTH=5.1E-6,5.6E-6. However, this is more for lists than for ranges

• Doug proposed another range specification that it is the one we have followed in the current SLAP document



(8/ 11)Range definition

Some examples of the range definition:• Param = x equality• Param = x/y closed range• Param = x/ open range• Param = x,y list• Param = x,a/b,y range list

Are x and y included in the range x/y? Other possibilities including “[“ and “(“ explored, but more difficult to parse. To consider x and y as included should be enough.

Document changed accordingly to this proposal



(9/ 11)Inputs from DAL forum (III)

Utype usage. Wavelength_min and Wavelength_max have same utype and this is not permitted (Doug Tody)• The use of two different parameters for the wavelength was used to

define the range. Now, as the range definition has been changed, there is only one wavelength input parameter and there is not utype repetition

Field “names” are imposed in the document. Only the utype should be fixed and the names should be free (Doug Tody) • e.g. “Exactly one field MUST have name=“wavelength” …. with

utype=“ldm:Line.wavelength”…” This is not correct• Document changed to, e.g., “Exactly one field MUST have

utype=“ldm:Line.wavelength”…”



(10/ 11)Future actions

Utypes syntax in the document should be revisited (Close to current specification). Note that the SLAP protocol is based in utypes

If the changes are approved for this version, the reference implementation developed for the IASD (Infrared Astronomical Spectroscopic Database) will be updated accordingly. This update will help people to create SLAP services and to get scientific inputs of needs/improvements

At the same time, the client implementation in VOSpec will be updated SLAP service for XMM-Newton spectral lines to be implemented After last meeting in Vienna about the Spectral Line data model, Creation

a SLAP service on the NIST Atomic Spectra Line Database. One of the biggest theoretical spectra line databases

Coordinate with the registry group to create new resource type for SLAP services to allow registration



(11/ 11)First Draft v0.5

european space astronomy centre (esac) villafranca del castillo, madrid (spain) jesús salgado...

Documents