MANGO DM in working draft

[Laurent Michel]

Mark

> On 30 Jan 2025, at 17:26, CresitelloDittmar, Mark <mdittmar at cfa.harvard.edu> wrote:
> 
> 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.`


I see :-)

> 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.

The exercise with Vizier is to show what we can do on the fly with existing data.
The red line for Vizier is not to do any mining to discover what can be mapped or not for a given catalogue.
The model part mapped by Vizier are a subset of this shown in GAIA. There is no need to bother Vizier people ti make major changes to implement features that are already in GAIA.
I don’t speak here about the SpaceSys
> 
> 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’n afraid you are working with an obsolete model. Do you use this on my branch?
(all of your comments are relevant indeed, whatever the branch)

> 
> 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.

I see

Laurent

> 
> Mark
> 
> 
> 
> 
> On Thu, Jan 30, 2025 at 10:58 AM Laurent Michel <laurent.michel at astro.unistra.fr <mailto: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 <mailto: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/a567082b/attachment.htm>