DM running meeting contribution

[BONNAREL FRANCOIS gmail]

Dear all again,
One little point below
Le 18/02/2025 à 11:26, Laurent Michel via dm a écrit :
> Dear DM
>
> Unfortunately, I couldn't attend  the running meeting because of a friend's funeral.
>
> I apologise for this long message but it could feed the MANGO item of the agenda.
> If that occurs I look forward to read the meeting notes and to reply to them
>
> I would like first to thank the active contributors (especially Gilles, Mark T and CD)
>
> My report:
>
> STATUS OF THE DOCUMENT
> - I addressed most of the issues (#63 ->73) in the last PR (#76).
>
> IMPLEMENTATION UPDATE
> Mark CD has pointed out some omissions and inconsistencies that need to be addressed.
> I don't have the manpower to update the reference implementations or the services that
> provide them along with the GitHub issues.
> I'll do it once we've agreed on the model structure.
>
> GLOBAL ISSUES THAT NEED TO BE ADDRESSED
> 1- Label class:
>      o  This property needs to be either removed or linked to a vocabulary.
>      o  My point of view: Having a label as a property allows MANGO objects to be annotated globally.
>          This is not a strong requirement, so I'm happy with both options.
>
> 2- Referring to draft vocabulary
>      o Calibration levels refer to a draft vocabulary
>      o  My point of view: This is not a problem for MANGO, since the use of vocabularies allows
>          the set of accepted words to be able to evolve independently from the model version.
>          It is therefore not necessary to approve the vocabulary before using it in the model.
>
> 3- Use of MeasDM errors
>      o MANGO includes error classes imported from MeasDM, but extended with a confidence
>         level and a statistical distribution (cross match use-case).
>      o In addition, I've redesigned the Ellipse class to avoid associating roles with positions in a coordinate array,
>         which is a burden for both annotators and clients.
>      o My point of view: These MANGO error classes address the EpochPosition use case and there is
>         no rule that says the MANGO use cases must be enclosed in those of Meas/Coord.
>         So moving them back to Meas before setting MANGO as an RFC is something I really want to avoid,
>         as this would open a Pandora's box with little benefit.

About the above statement. I think we should consider that VO never 
progressed with a totally top down view. Some uses cases or science 
priorities drive new specifications standards or VO developments, which 
basically fulfill the specific goal (wich I think is the case of Mango 
with respect to epochPropagation). Then comes a larger perspective and a 
new more generic standard has to be developed. Or some integration 
between a specific standard and a generic one appears to be required.

But no absolute planning of the steps can be done before trying something.

So the development cannot be linear and is more a spiral one . Upwards !

Cheers

François


>        
>      o  My proposal (see #76) :
>          - Update MANGO to only use the specific error classes (mango:errors*)  in the EpochPosition context,
>          - Break the inheritance link between meas:Uncertainty and mango:PropertyError
>          - use the abstract class Meas:Uncertainty for the errors in the other places (photometry)
>
> Congratulation for those who reached the end.
>
> Laurent