SLAP: Simple (Spectral) Line Access Protocol

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
  FORMATMETADATA 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 FORMATMETADATA could be requested by the
  registry services or by the VO clients.
• Evolution to VOResource?

8
FORMATMETADATA output
   
9
Output Results

• Output MUST Compulsory fields
• wavelength (ucd"em.wl utypeldmLine.waveleng
  th) wavelength in the vacuum of the transition
  originating the line in micrometers
• description (ucdem.lineutypeldmLine.title
  ) contains a small description identifying the
  line.
• Output SHOULD non-compulsory field.
• chemicalelement_name (ucdphys.atmol.elementut
  ypeldmChemicalElement.name) contains a name
  of the chemical element source of this line
• initial_level final_level (ucdphys.atmol.ini
  tial/finalphys.atmol.level utypeldmLine.in
  itial/finalLevel) 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
  utypeldmLine.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 (utypeQuery.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/finalphys
  .atmol.level utypeldmLevel.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 ucdmeta.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!