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

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!)

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

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

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

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

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

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

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”…”

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

First Draft v0.5 Comments are welcome!