1. 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. 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. SLAP Overview
A SIAP-like URL service, would allow an easy implementation for all spectral line providers
Form
Query
Panel
SLAP
Layer
Line
Database
Client
SLAP
Layer
Line
Database
VOTable,
one spectral line per row
Form
Query
Panel
SLAP
Layer
Line
Database
λ range is compulsory

4. 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. 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. 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. 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. 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. 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. 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. First Draft v0.5
Comments are welcome!