VOTable 1.5 Working Draft

[Laurent Michel]

Dear Apps,

Having just subscribed back to the channel, I've no other choice than opening a new thread,
sorry for that. I keep the same title anyway.

I understand the objections expressed by Pierre & Co about modifying the VOTable schema
to support both direction references.
I totally agree with the need of defining a standard way to implement the Epoch propagation
but I do not get the advantage of modifying the schema for this.
I'm suspicious that having both directions references may introduce ambiguities in the reference
processing in comparison with using GROUPs that simply connect both FIELDS and WHATEVERSYS.
It seems to me that this latest approach won't make any damage in the existing workflow
(Provider/VOTable/client) or bother client developers either.
There are perhaps some major twiks hidden somewhere, but I do not see any yet.

 From another hand If someone had asked me what was the best way for the VOTable to support
EPOCH propagation, I wouldn't have suggested  using COOSSYS->FELD ref or FIELD<-GROUP->COOSYS.

I'm not trying to negotiate a working  VOTable pattern against DM promises but
However I think it is important for the community to get the status of the ongoing work to assess
the opportunity of mentioning this approach in the document and may be to reconsider the scope
of the new COOSYS pattern, whatever it is.

The DM approach would provide a total flexibility for connecting columns with any sort of classes.
For this, we need MIVOT (we got it), code and models (we have them except one -MANGO-)
Below is a glimpse of the Today's DM landscape:

- MIVOT: VO REC
- Models:
   - Meas/Coords/PhotDM/... VO Rec now
   - MANGO: We need a better coverage of the usual physical quantities present in query responses.
    This is the purpose of MANGO. Basically it is a aggregator of Meas/Coords objects + instances
    of specific classes that are not easily covered by recommended models:
      - Status and flags
      - Photometric data
      - 6 Params position (Pos/pm/parallax/Rv == Epoch propagation).
        We will propose here a flat class with those 6 parameters such as requested
        by Markus and Gilles. This topic is less advanced because errors with
        multiple covariances are not a cakewalk.
- Astropy/PyVO
   - We have a PR (https://github.com/astropy/astropy/pull/15390)
    for enabling Astropy to operate the basic IO operations with  MIVOT annotations.
   - We are going to open PRs on PyVO to provide a science API similar to this proposed
     by Markus (https://github.com/msdemlei/astropy)

I won't be promoting this any further, but I think that the MIVOT workflow should
be taken into consideration at some point in VOTable 1.5.

Best
Laurent

--
English version: 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 --------------
A non-text attachment was scrubbed...
Name: laurent_michel.vcf
Type: text/vcard
Size: 406 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20231004/fa70775b/attachment.vcf>