MANGO DM in working draft

[CresitelloDittmar, Mark]

Laurent,

I agree that, in general, the annotation can be missing required elements..
a provider cannot annotate information that is not available.  This would
simply lead to an incomplete instance.

However, If you are referring to my comments on the reference
implementation serializations, I think I'm looking at these with a somewhat
higher bar.
These are representative of complete instances which can satisfy the use
case / usage thread .. so if something "required" in the model is missing
from these serializations, it implies that the element is not required for
the use case.

In the Vizier cone search output for example:
   o it is missing the pmCosLat_applied parameter.   We know from the
workshop experience that you CAN execute the propagation without this, but
you cannot rely on the results.  So I'd say this really must be in the
reference implementations to show the minimal set of attributes to execute
that thread.

In the GAIA example:
  o the EpochCorrMatrix object is missing the 'correlation' attribute, and
there is this whole other object (EpochPositionCorrelations) which seems to
take its place in the workflow.
     Since both of these objects are added to MANGO specifically for this
epoch propagation case, this really implies a problem with the modeling of
correlations.

I don't think it is necessary to put in the MANGO (or other) model, what
the annotation can do.  The comments are specific to these annotated files.

Mark




On Thu, Jan 30, 2025 at 10:58 AM Laurent Michel <
laurent.michel at astro.unistra.fr> wrote:

> Hello DM,
>
> Many, thanks Mark for having looked carefully at the implementations.
>
> There are many things to fix.
> -,Some of them are real errors that must be fixed.
> - Some others are due to the fact that the development of these
> implementations runs behind the model itself (must be fixed aniway).
>
> I have a general comment about the model vs the annotations.
> If a model defines a quantity as mandatory and that quantity is not in the
> dataset (not present at all, the data provider does not want to expose it,
> or the TAP query skipped it) it is perfectly legal, in my view, for the
> annotations to ignore this and provide an instance with missing mandatory
> components. The annotation process must be driven by the data, not the
> model.
>
> There are 2 ways to sort this out:
> 1- make all model elements optional.
> 2- state clearly that the annotations can ignore multiplicity=1 required
> by the mode if data are not present.
>
> I’m in favour of 2: Let the model describe things as they should be and
> the annotations as they are
>
> LM
>
>
> On 29 Jan 2025, at 23:31, CresitelloDittmar, Mark <
> mdittmar at cfa.harvard.edu> wrote:
>
> *Implementations:*
> Lastly, I'm not sure where to put this feedback.
> I compared the implementation examples noted on the twiki against the
> model and saw some discrepancies.  These are going to serve as examples, so
> I think they should be pretty solid.
>
>    - Vizier cone search service returns annotated VOTable for Epoch
>    Propagation Thread
>       - The coords:SpaceSys annotation is not correct, it is missing the
>       SpaceFrame INSTANCE which holds the SpaceFrame.spaceRefFrame ATTRIBUTE
>       - TimeSys is missing - since this example includes the epoch, the
>       associated timesys should be provided
>       - There is no EpochPosition.parallax, radialVelocity,
>       pmCosLat_applied.  Parallax and radialVelocity might be optional, but
>       pmCosLat is important (as we found when implementing this in the 2020
>       Workshop).
>       - The REFERENCE to the SpaceSys is not right..
>       dmrole="coords:Coordinate.coordSys" which is the dtype of the referenced
>       object.  the dmrole should be "mango:EpochPosition.spaceSys"
>       - Q: How does this work in the epoch propagation thread?
>
> OK, I’ll ask Vizier team to fix this.
>
>
>
>
>    - GAIA VOTable mapped to MIVOT (hand-mapping)
>       - Using PropertyError1D rather than Symmetric1D, which I think is a
>       fairly recent change.
>       - has the ErrorCorrMatrix object, but does not include the required
>       (multiplicity=1) 'correlation' attribute, representing the "correlation
>       coefficient between the 2 axes".  This concept appears to be embodied by
>       EpicPositionCorrelations which does appear and is complete.  (maybe this is
>       a Model topic)
>    - HE Data and Photometry:
>       - Has several PhotometryFilters defined in GLOBALS, which is fine.
>       - The PhotometryFilters which should be referenced from PhotCal are
>       annotated in-line as INSTANCES, this creates multiple instances of the same
>       filter.. including the same ID.
>       - includes EpochPosition but only populates (latitude, longitude,
>       spacesys)
>          - This is one of the reasons I have issues with EpochPosition in
>          general.. the intent here is to annotate a Position, and the EpochPosition
>          object is handy.  This should be a PhysicalProperty with an associated
>          Position instance.
>          - The EpochPosition in this example is useless for the Epoch
>          Propagation use-case that it targets.
>       - doesn't annotate any errors even though they are in the table.
>
> The links still fail, but the curl commands worked for me.
> `
>
>
>
> LM
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250130/31771867/attachment-0001.htm>