1 / 26

DAL (Data Access Layer) protocols

DAL (Data Access Layer) protocols. Jesus Salgado ESAVO-ESAC Jesus.Salgado@sciops.esa.int. Why do we need protocols?. Form Query Panel. Service Provider 1. T. T. Web Service. Service Provider 2. T. Raw Socket. Service Provider n. Why do we need protocols? (II). Service

sharis
Download Presentation

DAL (Data Access Layer) protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DAL (Data Access Layer) protocols Jesus Salgado ESAVO-ESAC Jesus.Salgado@sciops.esa.int

  2. Why do we need protocols? Form Query Panel Service Provider 1 T T Web Service Service Provider 2 T Raw Socket Service Provider n

  3. Why do we need protocols? (II) Service Provider 1 Service Provider 2 DAL Protocol Service Provider n

  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. SIAPSimple Image Access Protocol(Tody et al.)

  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" [...] • 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. Coordinates/Target matches? Give ACCREF data (real Data) Query Response: VOTable with list of matches Data Response: Image SIAP Basics REGISTRY Client application SIAP Servers available? SIAP Servers service URLs SIAP Service Provider 1 SIAP Service Provider 2 SIAP Service Provider n

  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. SSAPSimple Spectral Access Protocol (Tody et al.)

  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. Coordinates/Target matches? Give ACCREF data (real Data) Query Response: VOTable with list of matches Data Response: Spectrum ( fits, VOTable, …) SSAP Basics REGISTRY Client application SSA Servers available? SSA Servers service URLs SSAP Service Provider 1 SSAP Service Provider 2 SSAP Service Provider n

  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. SSAP 1.01 - Query Interface • Mandatory query parameters • POS RA, DEC (ICRS) • SIZE diameter (decimal degrees) • FORMAT VOTable, fits, xml, text, graphics, html, external • Should other parameters be mandatory? • e.g., BANDPASS, TIME, SPECRES, APERTURE

  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.SpectralSI SI factor and dimensions • Dataset.FluxSI SI factor and dimensions • Dataset.CreationType atlas, pointed, cutout, resampled • DataID.DataSource Original source of data

  15. SSAP 1.1– Some specialized response metadata • Characterization - Reference Frames • CoordSys.SpaceFrame.Name Spatial 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. 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) • 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. 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. SLAPSimple Line Access Protocol (Salgado et al.)

  19. SLAP (Simple Line Access Protocol) 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

  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. 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. <RESOURCE type="results"> <DESCRIPTION>IASD Simple Line Access Service</DESCRIPTION> <INFO name="QUERY_STATUS" value="OK"/> <PARAM name="INPUT:WAVELENGTH" ucd="em.wl;stat.min" utype=”ldm:Line.wavelength” value="30"> <DESCRIPTION> 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 </DESCRIPTION> </PARAM> <PARAM name="INPUT:CHEMICAL_ELEMENT" ucd=“phys.atmol.element" utype=”ldm:Line.initialElement.name” value="190"> <DESCRIPTION> Specify the chemical element that originates the line </DESCRIPTION> </PARAM> <PARAM name="INPUT:OBSNO" ucd="obs.id"> <DESCRIPTION> Specify the ISO observation number where this line has been identified </DESCRIPTION> </PARAM> …………………………………….. FORMAT=METADATA

  23. SLAP output parameters (I) • 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

  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. SLAP output parameters (III) • 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

  26. Questions?

More Related