VOTable 1.5 Working Draft

[Adrian Damian]

Hi All,

Thank you, Laurent and others for offering different perspectives on the
COOSYS issue. It is an important issue and it's great to see all the
discussions that it generates. It will most certainly be discussed at the
Interop but Pierre and I were wondering if people prefer an earlier
opportunity to meet and discuss it. Please let us know and we can organize
a Zoom meeting next week or the week after depending on everyone's
availability.

Thanks,
Adrian & Pierre

On Wed, Oct 4, 2023 at 7:58 AM Laurent Michel <
laurent.michel at astro.unistra.fr> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20231006/4571dd89/attachment.htm>