1. Workshop on How to Publish Data in VO ESAC, June 25-June 29 2007 DAL (Data Access Layer) protocols Jesus Salgado ESAVO-ESACJesus.Salgado@sciops.esa.int

2. Plenary Session, Page 2 Why do we need protocols?

3. Jesus SalgadoPlenary Session, Page 3 Why do we need protocols? (II)

4. Jesus SalgadoPlenary Session, Page 4 Simple Protocols  SIAP (Images), SSAP (Spectra), SLAP(Spectral Lines)  HTTP based  VOTable response  Similar interfaces; different protocols for different types of products (images, spectra, lines,…) to converge in a latter state  Not difficult to be developed

5. Jesus SalgadoPlenary Session, Page 5 SIAP Simple Image Access Protocol (Tody et al.)

6. Jesus SalgadoPlenary Session, Page 6 SIAP: IVOA standard  […] standard for retrieving image data from a variety of astronomical image repositories through a uniform interface […]  […] based primarily on two documents […]"Simple Image Retrieval: Interface Concepts and Issues", […] "Simple Cone Search specification" [...] "Simple Image Retrieval: Interface Concepts and Issues""Simple Cone Search specification""Simple Image Retrieval: Interface Concepts and Issues""Simple Cone Search specification"  Originally [...] primarily as an "image on demand" service, with images created on-the-fly [...]  […]Required query parameters: POS, SIZE, FORMAT[…]  […]Required response columns: Image_Title, POS_EQ_RA_MAIN, POS_EQ_DEC_MAIN, Image_Format […]

7. Jesus SalgadoPlenary Session, Page 7 SIAP Basics SIAP Servers service URLs Query Response: VOTable with list of matches Data Response: Image Coordinates/Target matches? SIAP Servers available? Give ACCREF data (real Data) Client application REGISTRY

8. Jesus SalgadoPlenary Session, Page 8 SIAP: facts  More than 80 SIAP services registered  The most successful IVOA protocol up to now  Easy access to images from different spectral ranges in the same VO application (e.g. Aladin)  Some examples: –HST, 2MASS, XMM, SDSS, ISO, Integral, ROSAT, FIRST, IRAS,… and many more

9. Jesus SalgadoPlenary Session, Page 9 SSAP Simple Spectral Access Protocol (Tody et al.)

10. Jesus SalgadoPlenary Session, Page 10 SSAP: A summary  […]To define a uniform interface to spectral data[…]  […]The term “Simple” in Simple Spectral Access Protocol refers to the design goal of simplicity in both implementing spectral data services and in retrieving spectroscopic data from distributed data collections[…]  […]Required query parameters: POS, SIZE, FORMAT[…]  […]Required response columns: FORMAT, ACREF, SED Object, Data Source, Coverage Metadata…]

11. Jesus SalgadoPlenary Session, Page 11 SSAP Basics SSA Servers service URLs Query Response: VOTable with list of matches Data Response: Spectrum ( fits, VOTable, …) Coordinates/Target matches? SSA Servers available? Give ACCREF data (real Data) Client application REGISTRY

12. Jesus SalgadoPlenary Session, Page 12 SSAP 1.01 - Basic Usage  Simple query –POS, SIZE - like cone search –Possibly refined by spectral or time bandpass, etc. –Most metadata in query response is optional  Data retrieval –URL-based –Get back a dataset (normally VOTable or FITS) –In simplest case could be wavelength, flux as text (for Spectrum) –Or external data pass-through

13. Jesus SalgadoPlenary Session, Page 13 SSAP 1.01 - Query Interface  Mandatory query parameters –POSRA, DEC (ICRS) –SIZEdiameter (decimal degrees) –FORMAT VOTable, fits, xml, text, graphics, html, external  Should other parameters be mandatory? –e.g., BANDPASS, TIME, SPECRES, APERTURE

14. Jesus SalgadoPlenary Session, Page 14 SSAP 1.01 - Query Response  Dataset Metadata –Dataset.Type Spectrum, TimeSeries, SED, etc. –Dataset.DataModel DM name, e.g., "SSA-V1.0" –DataID.Title Brief descriptive title of dataset –Dataset..Length Number of points in dataset –Dataset.SSA.SpectralAxis SpectralCoord axis (external data) –Dataset.SSA.FluxAxis Flux axis (external data) –Dataset.SpectralSISI factor and dimensions –Dataset.FluxSISI factor and dimensions –Dataset.CreationType atlas, pointed, cutout, resampled –DataID.DataSourceOriginal source of data

15. Jesus SalgadoPlenary Session, Page 15 SSAP 1.1– Some specialized response metadata  Characterization - Reference Frames –CoordSys.SpaceFrame.NameSpatial Coordinate frame (default ICRS) –CoordSys.SpaceFrame.Equinox Equinox (2000) –CoordSys.TimeFrame.Name Timescale (TT)  Characterization - Coverage –Char.SpatialAxis.Coverage.Location.Value  Observed position, e.g., RA DEC –Char.SpatialAxis.Coverage.Bounds.Extent  Aperture angular diameter –Char.SpectralAxis.Coverage.Location.Value  Midpoint of Spectral coord. range –Char.SpectralAxis.Coverage.Bound.Extent  Width of spectrum

16. Jesus SalgadoPlenary Session, Page 16 SSAP implementations  Implement service able to provide SSAP-like access –ESA’s Infrared Space Observatory (ISO) spectra available in SSAP- like form since December 2003. First ever SSAP-like server. –Other SSAP-like services that followed suite (in chronological order): IUE, HST, SDSS, FUSE, HYPERLEDA….up to 18 services (all available from VOSpec tool) (all available from VOSpec tool)VOSpec  Implementation of latest protocol specification not ready for most of them  Design and implement client able to consume SSAP spectra services –ESA’s initiative response called VOSpec: a tool for handling SSAP- like spectra in VO context

17. Jesus SalgadoPlenary Session, Page 17 TSAP (Theoretical spectra)  Same protocol (input/output) re-used to give support theoretical spectral servers  Both coverage input parameters and output characterization coverage metadata non- compulsory  As it will be seen in next section, discovery of server capabilities is crucial  9 services already in place

18. Jesus SalgadoPlenary Session, Page 18 SLAP Simple Line Access Protocol (Salgado et al.)

19. Jesus SalgadoPlenary Session, Page 19 SLAP (Simple Line Access Protocol) VOTable, one spectral line per row A SIAP-like URL service, would allow an easy implementation for all spectral line providers

20. Jesus SalgadoPlenary Session, Page 20 SLAP input parameters  If the only compulsory parameters are the minimum and maximum wavelength, the number of lines in the output result, in particular for theoretical spectral line databases, could be HUGE. –Some non-compulsory parameters added to the protocol to filter or score the output lines –CHEMICAL_ELEMENT: This parameter would constraint the search to the chemical element selected (syntax problems, but some standards found) –LEVEL_ENERGY_START & LEVEL_ENERGY_END: Parameters to specify the minimum and maximum energy for the START & FINAL level of the transition. Filter at CLIENT side –TEMPERATURE: This parameter would be used (in particular for theoretical spectral line databases) to score the lines in the output using physical models. Score at SERVER side

21. Jesus SalgadoPlenary Session, Page 21 SLAP extra parameters  The servers could have extra parameters that cannot be identified easily and included in the document.  For Theoretical Spectral Line services, the parameters could be used to filter/score the result due to physical models  For Observational Spectral Line services, the parameters could be project dependent  Solution adopted: –Use same approach than proposed for TSAP. All the input parameters will be DESCRIBED in a FORMAT=METADATA query. –The description should include not only the parameter names but a description, UCDs (to identify the physical meaning of the parameters), utypes whenever possible (to Line Data Model or another IVOA data model) –This FORMAT=METADATA could be requested by the registry services or by the VO clients

22. Jesus SalgadoPlenary Session, Page 22 FORMAT=METADATA IASD Simple Line Access Service <PARAM name="INPUT:WAVELENGTH" ucd="em.wl;stat.min" utype=”ldm:Line.wavelength” value="30"> Specify the wavelength spectral range. To be specified in micrometers. This wavelength will be interpreted as the wavelength in the vacuum of the transition originating the line <PARAM name="INPUT:CHEMICAL_ELEMENT" ucd=“phys.atmol.element" utype=”ldm:Line.initialElement.name” value="190"> Specify the chemical element that originates the line Specify the ISO observation number where this line has been identified ……………………………………..

23. Jesus SalgadoPlenary Session, Page 23   Output “MUST” Compulsory fields – – wavelength (ucd="em.wl”; utype=”ldm:Line.wavelength”) wavelength in the vacuum of the transition originating the line in micrometers – – title (ucd=“em.line”;utype=”ldm:Line.title”) contains a small description identifying the line.   Output “SHOULD” non-compulsory field. – – chemicalelement_name (ucd=“phys.atmol.element”;utype=”ldm:ChemicalElement.name”) contains a name of the chemical element source of this line – – initial_level & final_level (ucd=“phys.atmol.[initial/final];phys.atmol.level”; utype=”ldm:Line.[initial/final]Level) contain a full description of the initial & final levels of the transition originating the line SLAP output parameters (I)

24. Jesus SalgadoPlenary Session, Page 24 SLAP output parameters (II)   Summary of output COULD optional fields – – observed_wavelength (ucd="em.wl“; utype=”ldm:Line.observedWavelength”) contains the observed wavelength in the vacuum of the transition originating the line in micrometers, as it was observed. This could be used by observational spectral line databases – – score (utype=”Query.Score”) similar concept to SSAP 0.9. Easier to be implemented for physical models – – level_energy_start & level_energy_end (ucd="phys.energy; phys.atmol.[initial/final];phys.atmol.level”; utype=”ldm:Level.energy.[start/end]”) describe the energy for the starting & final levels of the transition which originates this line.

25. Jesus SalgadoPlenary Session, Page 25   URL-like fields – – publication_link (ucd="meta.bib”) specifies a http link that contains a bibliographic reference related to the spectral line – – Other fields could have ucd=“meta.ref.url" specifying URLs that contains extra information related to the spectral line   Non-Standard output fields – – In many occasions, extra scientifically interesting parameters could be added to the output. Implementors are encouraged to add descriptions and UCDs to the return fields to clarify the meaning of this information and utypes to the Line data Model or other existing Data Model, whenever possible.   4 services already in place; IASD, Cielo (observational), NIST, Lerma (laboratory). Plans to include ALMA in a near future SLAP output parameters (III)

26. Jesus SalgadoPlenary Session, Page 26