2015-11-18 EPN-TAP Presentation in CDPP (Toulouse)

Attendance

Pierre Le Sidaner, Nicolas André, Baptiste Cecconi, Vincent Génot, Laurent Beigbeder, Jean-Michel Glorian, Jean-Christope Malapert, Myriam Bouchemit, Joelle Durand

Discussion

Pierre Le Sidaner presents EPN-TAP, see attached slides.

• Presentation of IVOA background and standards used in VESPA
• EPN-TAP = EPNcore + TAP. 
  • EPNcore = list of predefined parameters. Inspired from ObsCore. 
  • EPNcore V1 developed in FP7
  • EPNcore V2 proposed for H2020 project.
  • V2 is not compliant with V1, so new main version.
• EPN-TAP query system
  1. query to VO Registry: where are the EPNcore+TAP registries. Response is list of service URLs
  2. All service URLs are queried with EPN-TAP query (using EPNcore data model)
  3. Each service replies with a list of granules with access URLs and previews for the given query.
  4. Possibility to edirect result into visualisation tool (AMDA, 3Dview, TOPCAT, Aladin...), depending on data product type.
• List of EPNcore parameters, see EPNcore V1 and EPNcore V2.
• How to implement new data services
  • DaCHS is recommended as for now, as it is simple to set up and PgSQL database can be easily adapted. This is based on Python.
  • TAP library of Grégory Mantelet from CDS (library used in SAADA) can also be used (based on java)
• Declare EPN-TAP service:
  • Create service declaration file (XML)
  • There is a validator: http://voparis-validator.obspm.fr (doc to come)
  • Interface to submit service declaration at ESAC registry
  • Possible to use internal DaCHS self-registry 
• Consume EPN-TAP services
  • There is an official registry, based on SOAP. Not working with all.
  • New registry interface based on TAP. Preferred option!
  • It is possible to spy TOPCAT queries with tools like wireshack, and check what is queried and what are the responses.

JCMalapert: We should work on specific cases, from the client to derive specifications of protocol and interfaces. 

Laurent Beigbeder and Jean-Michel Glorian: want to define how their tools (3Dview and CASSIS) will query VESPA, what result they would show to the user, how they handle data they don't know how

Baptiste Cecconi: On the VESPA portal, when we can find AMDA results. If the user wants to send it to AMDA via SAMP, AMDA should understand that the data shall not be downloaded from AMDA, but should be used directly from the database. Decide on what to do? E.g.: display a "plot manager" with the dataset parameters and the time interval.

Baptiste Cecconi: This is agreed. EPNcore is built to provide a data model that describes data product coverage useful for data discovery. EPN-TAP is an implementation of EPNcore with TAP. There may be other protocols that will use EPNcore in the future, this is to be studied. Furthermore: EPN-TAP is a generic data discovery protocol for planetary sciences, it does not replace dedicated interfaces adapted to specific thematics and use cases (for instance GIS), but it can be used to discover what data exist relative to a scene (in a GIS tool or in 3Dview), or in a spectral range (in CASSIS). The EPN-TAP protocol can be used two ways: a context data discovery protocol (querying all services with parameters pre selected depending on the tool display), or direct access to known resources when suitable (for instance, access to APIS images for 3Dview).

Baptiste Cecconi: the VESPA portal is the main interface, where all parameters can be queried. It will be updated during the project to improve it. Among the improvement, we can list:

• select the units preferred by the user (e.g., spectral units)
• transform a geometric query on the client to transpose it into the service internal geometry.
• add a name resolver for instrument_host (observatories/spacecraft), instruments, reference frames...

JCMalapert: for reference frames, have a look to http://spatialreference.org/ 

•  Baptiste Cecconi, propose people to work with Jean-Michel Glorian, Myriam Bouchemit.