• Mirreille Louys, Tom Donaldson Laurent Michel, Mark CD, Jesus Salgado, Gilles Landais, Francoise Genova, Kai Polsterer, Marco Molinaro, Francois Bonnarel , FX Pineau, Carlos Rodrigo, Sara Bertocco, Vincenzo Galluzzi, Markus Demleitner

• propose new use cases

• comment the use cases

• propose a solution

• comment proposed solutions

• End of April ?

• Etherpad [[https://pad.unistra.fr/p/pre-interop][link]

• Mapping Mango strucuture on top of Gaia and ZTF tables

• Usecase repository
• Coords model
• Measure model
• Cube model
• VODML repository
• VODML mapping ivoatex with this xsd and derived from mapping
• MANGO model
• ModelInstanceInVot mapping syntax
• ModelInstanceInVot test code

Interop Sessions

• - Provenance

• - Magnitude and system description

• - Groups for related meassure columns

• - Added values (e.g. coordinates into J2000)

• - Provenance information for filter origin

• - Provanence dublin core (DOI, authors, date)

• - Stable MANGO building block

• - VO validator

• Flux vs time lightcurves
• Physical properties: lightcurve, phase function, colors
• Heterogeneous time description (data, JD, MJD)
• Showing example file and client to filter properties
• Derived data: periods, lightcurve amplitude, shape
• Provenance

• MPC typical information shown
• Survey internal information

• Orbit information
• a, e_a, e, e_e, i, e_i, omega, e_omega, tperi, e_tperi and, in general, orbital elements information
• Also, phometric information, distance, etc
• Dynamics classification

• - This last session is more technical on mapping solutions
• - utypes useful for complex protocols but limited for complex cases
• - Complex mappings require architecture and techniques approaches
• - Quantities and roles
• - Annotation in VOTables without breaking exisiting VOTable structures
• - mapping written in pure XML
• - out of VOTable resources
• - allow nested structures
• - freedom to setup the schema
• - XML schema mapping imported into VOTable schema
• - Avoid name collisions between mapping and VOTable elements
• - VODML mapping 2017
• - 2019 MANGO mapping
• - 2020 ModelInstanceInVot

• - Mapping express how instances of data model are expressed on VOTable and TAP_SCHEMA
• - Based on the VODML standard
• - Example of a Source toy model to decribe the proposed mapping
• - Explanation of mapping for real catalogues tables
• - Complication of mapping is more than the syntax the impedance between data models and tabular data

• - tool that can read TAP_SCHEMA and VOTables
• - able to read data models
• - allow graphical connection between data elements and data model fields
• - generates mapping block

• - VO-DML is IVOA standard meta-model/language
• - goals: mapping at the meta-model level
• - mapping as much as possible 1-1

• Mapping syntax
• WG Roadmap
• Obscore for radio data

• - As the specification is a "language" it is difficult to validate

• - Decision to create snippets to check different areas of this pattern and using a unit test tools (python)

• - Revision of https://github.com/ivoa-std/ModelInstanceInVot

• GL: Should meta resource included into the results resource?

• LM: Yes, this is the way foreseen

• FB: Is this really valid or the correct way to add the resource "meta" inside "results"?

• LM: It was agreed that this was better during last meeting

• LM showing new xsd of the merged-syntax

• Dave M. propose to add a preamble on the python snippet with a description of the purpose of this test and also in the xml files

• DM: In particular a comment in the XML file for the rich examples to say what it represents

• e.g. https://github.com/ivoa-std/ModelInstanceInVot/blob/master/schema/validation/snippets/test_rich_instance_2_ok.xml

• GL: Multiple primary keys is a new feature? that could make things more complex.

• After clarification it is more multiple fields

• LM: In paralllel, a python client has been produced to have real instances of the model

• https://github.com/ivoa/modelinstanceinvot-code

• Proposal to merge with PyVO and connection to AStroPY investigated

• ADASS BoF: TAP and the DMs (to be prepared)

• Help wanted as the task is far beyond the VO time for the people involved

• Tom D. proposes to makes the contact with pyVO

• Next point Radio-Obscore

• Francois B. presents status of Radio extension of Obscore

• Present the ins and outs of Radio extension of Obscore

• list of columns to add to describe visibility data, list of authors, spec draft for Interop, status (endorsed note or full recomendation) ?

• List of possible additional columns : min max for spatial resolution and field of view, maximum angular scale, characterisation of the uv plane coverage, instrument description (nb of antennae eg), pointers fields to maps (uv coverage, beams, etc...)

• Should these extra columns inside obscore table or as another table? Not decided

• Marco M.: how to inform that this extra columns are empty?

• Francois B.: probably with a different extension Id?

• Mark T: For discovery it would be better to reuse the mechanism used by obscore

• Both approaches could work as these are only additional columns but not a modification of the basic Obscore table