DM Running Meeting Notes: 20250218

[CresitelloDittmar, Mark]

Sounds good Laurent.. Thanks.
I'm looking forward to reading the revised document when I get back from
vacation ( I'm out this last week for February ).

Mark


On Thu, Feb 20, 2025 at 11:17 AM 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/20250221/4f9e7933/attachment.htm>