MANGO DM in working draft

[Laurent Michel]

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/5a09052c/attachment.htm>