<div dir="ltr"><div>Hi All,</div><div><br></div>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. <div><br></div><div>Thanks,</div><div>Adrian & Pierre</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 4, 2023 at 7:58 AM Laurent Michel <<a href="mailto:laurent.michel@astro.unistra.fr" target="_blank">laurent.michel@astro.unistra.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Dear Apps,<br>
<br>
Having just subscribed back to the channel, I've no other choice than opening a new thread,<br>
sorry for that. I keep the same title anyway.<br>
<br>
I understand the objections expressed by Pierre & Co about modifying the VOTable schema<br>
to support both direction references.<br>
I totally agree with the need of defining a standard way to implement the Epoch propagation<br>
but I do not get the advantage of modifying the schema for this.<br>
I'm suspicious that having both directions references may introduce ambiguities in the reference<br>
processing in comparison with using GROUPs that simply connect both FIELDS and WHATEVERSYS.<br>
It seems to me that this latest approach won't make any damage in the existing workflow<br>
(Provider/VOTable/client) or bother client developers either.<br>
There are perhaps some major twiks hidden somewhere, but I do not see any yet.<br>
<br>
From another hand If someone had asked me what was the best way for the VOTable to support<br>
EPOCH propagation, I wouldn't have suggested using COOSSYS->FELD ref or FIELD<-GROUP->COOSYS.<br>
<br>
I'm not trying to negotiate a working VOTable pattern against DM promises but<br>
However I think it is important for the community to get the status of the ongoing work to assess<br>
the opportunity of mentioning this approach in the document and may be to reconsider the scope<br>
of the new COOSYS pattern, whatever it is.<br>
<br>
The DM approach would provide a total flexibility for connecting columns with any sort of classes.<br>
For this, we need MIVOT (we got it), code and models (we have them except one -MANGO-)<br>
Below is a glimpse of the Today's DM landscape:<br>
<br>
- MIVOT: VO REC<br>
- Models:<br>
- Meas/Coords/PhotDM/... VO Rec now<br>
- MANGO: We need a better coverage of the usual physical quantities present in query responses.<br>
This is the purpose of MANGO. Basically it is a aggregator of Meas/Coords objects + instances<br>
of specific classes that are not easily covered by recommended models:<br>
- Status and flags<br>
- Photometric data<br>
- 6 Params position (Pos/pm/parallax/Rv == Epoch propagation).<br>
We will propose here a flat class with those 6 parameters such as requested<br>
by Markus and Gilles. This topic is less advanced because errors with<br>
multiple covariances are not a cakewalk.<br>
- Astropy/PyVO<br>
- We have a PR (<a href="https://github.com/astropy/astropy/pull/15390" rel="noreferrer" target="_blank">https://github.com/astropy/astropy/pull/15390</a>)<br>
for enabling Astropy to operate the basic IO operations with MIVOT annotations.<br>
- We are going to open PRs on PyVO to provide a science API similar to this proposed<br>
by Markus (<a href="https://github.com/msdemlei/astropy" rel="noreferrer" target="_blank">https://github.com/msdemlei/astropy</a>)<br>
<br>
I won't be promoting this any further, but I think that the MIVOT workflow should<br>
be taken into consideration at some point in VOTable 1.5.<br>
<br>
Best<br>
Laurent<br>
<br>
--<br>
English version: https: //<a href="http://www.deepl.com/translator" rel="noreferrer" target="_blank">www.deepl.com/translator</a><br>
-- <br>
jesuischarlie/Tunis/Paris/Bruxelles/Berlin<br>
<br>
Laurent Michel<br>
SSC XMM-Newton<br>
Tél : +33 (0)3 68 85 24 37<br>
Fax : +33 (0)3 )3 68 85 24 32<br>
Université de Strasbourg <<a href="http://www.unistra.fr" rel="noreferrer" target="_blank">http://www.unistra.fr</a>><br>
Observatoire Astronomique<br>
11 Rue de l'Université<br>
F - 67200 Strasbourg</blockquote></div>