DM Running Meeting Notes: 20250218

[Laurent Michel]

Hello DM,

Last merged 
    https://github.com/ivoa-std/MANGO/pull/80

- Upgrade following he Mark’s suggestions(see below)
- The data origin package (mango:origin) has been modified to be closer to the vizier requirements.

Bye
LM

https://github.com/ivoa-std/MANGO/releases/tag/auto-pdf-preview
Release Auto PDF Preview · ivoa-std/MANGO
github.com


> On 20 Feb 2025, at 17:16, Laurent Michel <laurent.michel at astro.unistra.fr> wrote:
> 
> Mark,
> 
> 
> Thank you for the meeting notes.
> 
> I would just comment on the following point:
> 
>> On 20 Feb 2025, at 15:31, CresitelloDittmar, Mark via dm <dm at ivoa.net> wrote:
>> 
>>   o [MCD] restatement of concern..
>>        EpochPosition is a 2nd mode of representing content which can be done
>>        with the Measurement types.  This is generally considered bad practice.
>>        I would be MUCH happier with the object if it were associated with 
>>        GAIA data, more than the "Epoch Propagation" use case.  i.e. that it
>>        is an object which supports the very complex GAIA (or GAIA-like) data
>>        which the Measurements model is currently unable to support.
>>        That would give providers/clients a more clear picture of WHEN to use
>>        this Object over the PhysicalProperty representation.
>> 
> 
> - There is no doubt that the EpochPosition class complies with the GAIA use-case.
> But describing the position of stars in a 6D space is a physical reality that we need to model with something describing these vectors and the way their coordinates can be correlated.
> For this reason, I do not think we should rename the class “EpochPosition” as “GAIAsomething” (if this is what you propose) .
> PROPOSAL : make the link with GAIA  very explicit in the class description as well the reason why it is flatten.
> 
> - I  agree with you that having to different ways to model the same quantity is not desirable, but the fact is that one property (EpochPropagation) encloses the other (meas:LonLatPosition), thus, the use-cases overlap. 
>  Faced with this situation, I reaffirm that importing one model from another is done first by sharing the same description for the same quantities, which is done for EpochPosition vs Meas:*, and that making these imports machine-operable comes as an extra-feature which may cost a lot. Therefore, it is wise to keep EpochPropagation as a MANGO native (complicated) class and meas:LonLatPosition as an imported one.
> PROPOSAL: recommend to use meas:LonLatPosition for simple positions (but the model cannot enforce such a rule).
> 
> Laurent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250306/17e4dce5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auto-pdf-preview.png
Type: image/png
Size: 97192 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250306/17e4dce5/attachment-0001.png>