DM Running Meeting Notes: 20250218

Laurent Michel laurent.michel at astro.unistra.fr
Thu Feb 20 17:16:49 CET 2025


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/20250220/71f74a5a/attachment-0001.htm>


More information about the dm mailing list