MIVOT REC

Laurent Michel laurent.michel at astro.unistra.fr
Mon Feb 20 12:19:59 CET 2023


Dear DM and TCG,

There are 3 WGs telling us that, MIVOT is not ready get in REC. The main concern seems to be related to the reference implementations.
I won’t summarise here the discussion but it has to noted that this standard has specificities that lead  to many misunderstanding:
- The purpose of MIVOT is to define a syntax making a bridge between models and data, nothing more,
  nothing less
- This is a necessary step toward a valuable model handling.
-  MIVOT is a difficult challenge because we do not know a-priori what the structure of the models to be mapped are and the data either.
   From that perpective MIVOT is closer to a language than to an XML schema which is rather new in the VO context.
- There is no semantic in MIVOT. MIVOT never tell you what the radial velocity for the dataset is. 
   It will just tell  the client that this column can be interpreted as this leaf of that model (which is supposed to exist).

This is a new episode in the DM WG life which is a long eggs-and-chickens story:
The IVOA ask us to provide recommended models
 but to make REC models, we have to demonstrate that actual data can be mapped on them. 
 For this we need an annotation syntax which requires first REC models.
Breaking that loop is a permanent challenge for the WG.

The strategy we proposed to achieved this was the following:
1- Get the REC for ongoing models (MCT/PhotDM) [done]
2- Propose an annotation (MIVOT) syntax allowing to map data on those models [done]
3- Validate this syntax against the above models even if the added-value is low [here we are]
4- Propose more complex models  (MANGO, Cube)  that bring real added value 
     to the data and that can help to solve real science use cases.
5- Validate them with MIVOT

This approach has been presented several times at the Interop, and as a (leaving soon) chair I'm still endorsing it at 100%.

Now we are in between 2 and 3 and some people (semantic) require 4 to be complete before validating 3.
This is a step back to chicken/egg loop, but never give up: I’m still hoping the we can find a solution:

We have 2 options:
1- Merging standards 2 and 4 in one RFC process: honestly,  I propose this for the record because I would like to keep 
    a chance to see the end of story before to get retired (4 years).
2- Finalising 3 but with the assumption that 4 is OK. In other words working with model drafts (MANGO and/or Cube).

My proposal to move on is the following:
Asking the TCG which option should be taken
If this is 1), I let my successor handle this
If this is 2) I propose to
obtain a clear acceptance that the high level models being worked on are drafts
Improve the validator as requested by MD
Provide an had-hoc 6 params (ala Gaia) implementation (as requested by MD)
Conclude the MIVOT REC on the bases of all models (REC or draft)
While waiting for an official TCG notification, we’ll to stop working on this standard (matter of time saving). 

LM writing with both chair and editor hat.

—
Translate with https: //www.deepl.com/translator
-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230220/5f9ef04f/attachment.htm>


More information about the dm mailing list