MIVOT MANGO COOSYS and all that stuff

Laurent Michel laurent.michel at astro.unistra.fr
Thu Oct 19 13:40:52 CEST 2023


Dear dm and apps

Since MIVOT has been a REC we are working in Strasbourg on client implementations in either Py or Rust. 
This work will be presented at the next Interop as well as at ADASS (P112)

The roadmap I’ve been following last years has 3 milestones:
    • validate component models (PhotDM, Meas/Coord etc) [DONE]
    • have a standard mapping syntax (MIVOT) [DONE]
    • validate MANGO DM against uses cases that were not covered before [THIS MAIL]

For the record, MANGO  is a container model gathering classes modelling most of the quantities 
of interest one can found in data tables.
We can summarise the main MANGO features as follows:
    • Reuses classes of component models as much as possible
    • Attach vocabulary to complex (multi columns) quantities
    • Connect various quantities together
    • include classes that are not in the component models (Epoch propagation, photometry, flags and status,…)

I’m now working on this last item and especially on the Epoch propagation case.  
To be short the epoch propagation case consists in a complex sky position including 
the proper motion, the radial velocity and the parallax all attached to a given epoch. 
All that stuff comes with a mess of correlated errors.

This type of complex positions cannot be modelled with the models we have. 
Thus it must be described by a MANGO class.
    • The design of this class comes along with the VOTable 1.5 discussion where it is question 
      to create and ad-hoc serialisation of the epoch propagation based on COOSYS until we have a MIVOT/model solution.
    • It looks obvious to me that we have better to skip the COOSYS step to directly adopt a solution based on MIVOT/MANGO.
It turns out that this idea could be the basis of a good compromise if MANGO were to come up with an acceptable solution quickly.
This is why I propose a MANGO class (EpochPosition) for the epoch propagation pattern  with a flat structure as required
by Markus and Gilles.
This leads to a very comprehensive and clear mapping block.

I propose a 2 VOTable sample:
    • one without error: https://github.com/lmichel/MANGO/blob/master/examples/simple-annotation-votable.xml
    • another with errors: https://github.com/lmichel/MANGO/blob/master/examples/full_error_annotation_votable.xml

You can see here 

   https://github.com/lmichel/MANGO/tree/master/diagrams

 a few diagrams showing up MANGO as it is Today.

Comments are welcome

Laurent



More information about the apps mailing list