WP7 Task 5: Associations/Extensions in S*AP Jes ú s Salgado Jesus.Salgado@sciops.esat

1. WP7 Task 5: Associations/Extensions in S*AP Jesús Salgado Jesus.Salgado@sciops.esa.int ESAVO Team European Space Astronomy Centre (ESAC) European Space Agency

2. WP7 Task 5 member listwp7_t5_assocsap@euro-vo.org Including CNRS/CDS and ESAVO • Francois Bonnarel (co-lead) - CNRS • Thomas Boch - CNRS • Keith Noddle (as DAL chairman) - UEDIN • Pedro Osuna (as WP7 coordinator) - ESAVO • Jesus Salgado (co-lead) - ESAVO Objective: Clients and servers use associations and extensions in a marginal way in the S*AP context. Analyze reasons and find possible solutions

3. Associations and Extensions discussion (I) Discussions held between SIAv2 core members at IVOA level • Need of specific examples inside specifications • In favour: Typically, clients are not making use of associations or extensions and they are ignoring extra information. Possible reason, not enough information inside the specs • Against: There are too many associations/extensions. The enumeration is out of the scope of the specs • Resolution: Some examples will be provided, with a disclaimer (not all the cases can be foreseen). Possible a better location for this discussion could be the DAL2 architecture document

4. Associations and Extensions discussion (II) • Is the way to associate or extend the flat/basic S*AP response correctly described in the S*AP documents? • In favour: Description of a general mechanism for associations is already present in the SSAP specification. This description includes: • Association.Type: Type of association • Association.ID: Unique ID identifying the association instance • Association.Key: Unique key different for each element association • Only a predefined case (Multiformat association) is described; where several records refer to the same dataset which is available in several different output data formats

5. Associations and Extensions discussion (II) • (continue) Is the way to associate or extend the flat/basic S*AP response correctly described in the S*AP documents? • Against: A description of a general mechanism is included in the SSAP but the level is too abstract to be used by a final software developer for the server or, more in particular, for the client side • A fine grain description is still needed. About extensions, there are not many details in the specification • Resolution: Same as previous. Some examples will be provided, with a disclaimer (not all the cases can be foreseen). Possible a better location for this discussion could be the DAL2 architecture document

6. Associations and Extensions discussion (III) & Use cases • When to use the association mechanism and/or extensions? “If it is heterogeneous kind of data it would be in the extension” • complex data ( multiimages, MOS, Echelle, more for Generic data Set ?) • complex metadata (Photometry, Provenance, characterization level 3 (FOVs) and 4 (variability maps)) • Use cases: We will update the AIDA pages with some use cases found + description. Please feel free to suggest/comment • Echelle spectra: It could be described either by association of multiple 1-D spectra or use a multi-segment spectral representation. It this enough? • Usually the entire spectra is also accessible in one of the links. The hierarchical structure is not defined in the association type (Association Type=hierarchical?) (standard way to link the records including the hierarchical information?)

7. Use Cases (II) • Transmission curves/response matrixes linked in the SSAP response to SED • Records associated using association mechanism. Link to the curve/matrix using the extension mechanism. This is particularly important to include high energy spectra in the VO, so a review of the spectral data model is needed • Images and sub-images: In SIAP, one image per observation + images for different energy bands or instrument. Example XMM images • It could be done by association. Same problem like in the Echelle spectra to describe the hierarchical information. It can be also done as extension, although this could increase the level of complexity in the interpretation of the response for the client • Some multiband surveys examples. Check and select one as a reference implementation

8. Use cases (III) • Multi-position query • Records associated using the association mechanism. Extension (if needed) to give target details • Confidence Maps (McMahon) “a normalised inverse variance weight map defining the "confidence" associated with the intensity value in each pixel, this also encodes for hot pixels, bad pixels, dead pixels and so on”. Provenance example • Photometry data server response • Description of the filter could be attached or detached in the response: • Case A: Information attached • Records associated using the association mechanism. Extension used to describe filter (linked to the main table by the association id). Data model used • Case B: Information detached • Records associated using the association mechanism. Filter description present in the Filter Profile Service. That implies that the association identifier should be the unique Filter Profile ID