1 / 12

SLAP: Simple (Spectral) Line Access Protocol Jes ú s Salgado* Pedro Osuna*, Matteo Guainazzi*, Isa Barbarisi*, Marie-Li

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

guillermo
Download Presentation

SLAP: Simple (Spectral) Line Access Protocol Jes ú s Salgado* Pedro Osuna*, Matteo Guainazzi*, Isa Barbarisi*, Marie-Li

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. SLAP: Simple (Spectral) Line Access Protocol 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. About Spectral Line Access • There is a scientific need to have access to spectral line databases in the VO. Many science cases could make use of this kind of access • It was agreed in last interop meeting (Kyoto) to start some work in this line • Three activities done in coordination. Line Data Model document, Simple Line Access Protocol and test implementation (both server and client side) A clear division was found since the very beginning: • Observational spectral line databases: Lines observed and identified in real spectra collected by different instrument/projects. • Theoretical spectral line databases: Servers containing theoretical spectral lines will be included in this group. This division is quite similar to the one found in spectral access.

  3. Protocol Overview • The approach followed by this protocol is the same one as the successful SIAP protocol, only diverging from it when the physics of the problem force to do it. • But not a two step process! • Some ideas of the access to Theoretical spectra have been developed and used for Theoretical Spectral Line databases. • Parallel to Line Data Model document, using it as the source of the abstract representation of a spectral line. • Basic search, lines in a wavelength range. Need for extra parameters.

  4. Present status Many on-line spectral line search services extensively used by scientists. All of the services have different form panels. Form Query Panel Line Database Form Query Panel Client Line Database Form Query Panel Line Database

  5. SLAP Layer 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 λ minimum and λ maximum are compulsory (μm !!)

  6. Non-Compulsory 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.

  7. Server Specific 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 • Proposed SOLUTION: • 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. • Evolution to VOResource?

  8.  <RESOURCE type="results"> <DESCRIPTION>IASD Simple Line Access Service</DESCRIPTION> <INFO name="QUERY_STATUS" value="OK"/> <PARAM name="INPUT:WAVELENGTH_MIN" ucd="em.wl;stat.min" utype=”ldm:Line.wavelength” value="30"> <DESCRIPTION> Specify the Minimum wavelength of 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:WAVELENGTH_MAX" ucd="em.wl;stat.max" utype=”ldm:Line.wavelength” value="190"> <DESCRIPTION> Specify the Minimum wavelength of 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:OBSNO" ucd="obs.id"> <DESCRIPTION> Specify the ISO observation number where this line has been identified </DESCRIPTION> </PARAM> …………………………………….. FORMAT=METADATA output

  9. Output Results • Output “MUST” Compulsory fields • wavelength(ucd="em.wl”; utype=“ldm:Line.wavelength”) wavelength in the vacuum of the transition originating the line in micrometers • description (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

  10. Output Results (continued) • 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. To unify results, the value must appear in cm-1 (as it can be found in many spectral line databases)

  11. Output Results (continued) • 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.

  12. First Draft v0.1 Comments are welcome!

More Related