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

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

SLAP ImplementationsSep 2006, Moscow, Russia

Simple Line Access Protocol Implementations

Jesús Salgado*

Document authors & Project contributions

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



SLAP Overview

VOTable, one spectral line per row

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



SLAP specification update

Since version 0.5, no many major changes have been included in the document.

Implementors have not found significant problems in the protocol and data model definition.

Some (server/client) implementations have been developed, by different projects.

We briefly present some servers and clients SLAP implementations and we will comment some of the aspects pointed by the different project implementors that could be included in the specification.



SLAP document update

FORMAT=METADATA use in SLAP• The SLAP will evolve parallel to the SSAP, and this method will be

superseded by the, more powerful, “getCapabilities” (getData, stageData not applicable)

• When a clear definition was done in SSAP, the SLAP specification will be updated accordingly

There is a need to have implementation rules to create SLAP like services for “unidentified”, “uncalibrated”,… etc lines, in the case of observational spectral line databases (ALMA). That means the compulsory field “ldm:Line.wavelength” for the output cannot be set for these lines.• Positional inputs parameters POS and SIZE will be explicitly included in the

document as it is done in the SSAP (optional)• New input parameter to filter by line identification status. Services with

unidentified lines should have the default value for this parameters as “identified”. Similar field to be included in the output

• These minimal changes will be included to create SLAP services for internal use or to be requested on purpose by specific clients.

Services with only not-identified lines would be not very interoperable, so they should not be registered as such



SLAP server 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

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



SLAP server implementations

SLAP Server Name: NIST Type: Theoretical Publisher: National Institute of Standards Contact: Yuri Ralchencko Service Description: SLAP Access to NIST Atomic Spectra Database Spectral Coverage: Multiple Coverage Number of Records: 142000 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



ALMA Spectral Line Catalogue

ALMA Archive Group at The University of Manchester:Stewart Williams, Andrew Markwick-Kemper, Sandra Etoka & Gary Fuller

ALMA requires a list of spectral line lines: Spectral Line Catalogue (SLC) SLC adopts the IVOA Atomic and Molecular Line Data Model

• Well placed to query and server lines in a complex Spectral Line Access protocol in the future

Do we have an agreed solution for versioning and history information?• ALMA provides first observations of many spectral lines; many (most?) will be

unidentified at first ALMA requires a list of Spectral Line Catalogue (SLC) Initial database sourced from Splatalogue 1

• Splatalogue:• Do we have a standard way of labeling a line as “unidentified”, “provisional

assigment”, predicted, “conflicting identification”, etc?• Can/should we request lines of this type in SLAP?

http://www.cv.nrao.edu/naasc/AAS/AAS208/aas208_splatalogue.ppt



Splatalogue

Contact points: A.J.Markwick-Kemper, A.J.Remijan, E.Fomalont ALMA & NRAO

Main role: Next generation of powerful millimeter/submillimeter observatories (ALMA/Herschel) require extensive resources to help identify spectral line transitions. Splatalogue started to fulfill this need

Functionalities:• Common interface for JPL, CDMS and Lovas/NIST line list• Implements SLAP 0.5 specification• Queries for specific species• XML and human-readable outputs

Future plans:• Not operational yet.



Splatalogue



LERMA SLAP Client

Contact points: N. Moreau and M.L. Dubernet, LERMA, Observatoire de Paris, VO-France

Main role: a specific client for the Basecol SLAP implementation Provides quantum numbers of each transition The client is able to send queries to other SLAP services

Functionalities:• Provides a choice between 3 SLAP servers: Basecol, ESA, NIST• Allows to do requests by wavelength or by frequency (frequency converted to

wavelength for the SLAP request)• Displays transitions in alphabetical or increasing frequencies order• Save to ASCII

Future plans:• More saving formats (VOTable)• Visualize in SpecView



LERMA SLAP Client



VOSpec

Contact points: Barbarisi I., Osuna P., Salgado J.,

ESA-VO Main role: A tool for handling Virtual Observatory compliant Spectra Functionalities:

• SLAP reference implementation• Provides a choice between 3 SLAP servers: ESA IASD, LERMA

Basecol, NIST, ESA Cielo• Select wavelength ranges on Spectral displayer• Superimpose line location on SSAP spectra

Future plans:• Line data model exploitation• Use of server dependent input parameters



VOSpec in action

VOSpec_SLAP.EXE



Conclusions

SLAP specification looks in good state. Several implementations have been developed (both server and client) without major problems

Support to SLAP like services, for observational line databases without proper identification to be included in the document as an new Appendix

Atomic and Molecular Line Data Model document has been proved as a

good theoretical complement and new projects, e.g. ALMA, can use it to easily generate data models to store their data, so the usability looks proved

Changes to have a common interface definition for SIAP/SSAP/SLAP, like the definition of the “getCapabilities” method can wait for a future version

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

Documents

transitions slap

slap services

clients slap implementations

lerma slap access

list of spectral line

spectral line providers

russia slap overview

server lines