MANGO DM in working draft

CresitelloDittmar, Mark mdittmar at cfa.harvard.edu
Wed Jan 29 23:31:16 CET 2025 

Dear DM,

I would like to again encourage as many as possible to review the document,
provide feedback and participate in the issue discussions.
I opened a couple issues regarding the Mango-Meas interface back in October
which have had some attention.

Recently, I made a full review of the 20241020 document and am summarizing
the comments here.  I apologize in advance if any of these were resolved in
subsequent PRs.  There is a reasonably long list, but they are for the most
part rather small.
*Git Issues:*

   - Typos and Grammatical changes: (#63
   <https://github.com/ivoa-std/MANGO/issues/63>)
   - MangoObject.identifier: purpose unclear (#64
   <https://github.com/ivoa-std/MANGO/issues/64>)
   - MangoObject/AssociatedMangoObject: relation (#65
   <https://github.com/ivoa-std/MANGO/issues/65>)
   - EpochPosition: general description (#66
   <https://github.com/ivoa-std/MANGO/issues/66>)
   - Label: general definition (#67
   <https://github.com/ivoa-std/MANGO/issues/67>)
   - Status.allowedValues: composition or reference (#68
   <https://github.com/ivoa-std/MANGO/issues/68>)
   - VocabularyTerm: multiplicities and interaction of attributes (#69
   <https://github.com/ivoa-std/MANGO/issues/69>)
   - CalibrationLevel: mapping to ObsCore (#70
   <https://github.com/ivoa-std/MANGO/issues/70>)
   - ColorDef: relation to PhotometryFilter (#71
   <https://github.com/ivoa-std/MANGO/issues/71>)

*Use Cases/Requirements*
Between this section and the Appendix, there is a lot of detail on use
cases.  I'd like to see more clearly:

   - the assessment of the data to be associated by the MANGO model.
   -  ie: what kinds of data:  Properties ( Meas, Flags, Assigned .. );
       Data Products;  <other?>
      - and which are selected to be supported by this version of the model.

There are specific properties listed in the cases, and also broad
statements like "approximately 1,700 columns covering properties", and "set
of stellar host characteristics".  Clearly, MANGO isn't going to include
the specs for all of these Properties.  So seeing the assessment of the
Types of Properties to be supported, and an example from each (defined
either internally or externally but in such a way that they appear
external) seems important.

Requirements:
I think that several of the requirements on MANGO are not actually MANGO
requirements, though I think some of this is a difference in opinion about
MANGO’s scope.  MANGO should have requirements to support the various
flavors of property, but not the definition of those properties

   - eg: MANGO must support Properties of measured quantities, including
   associated coordinate systems and errors but it is not required "to attach
   relevant coordinate systems to any measured quantity"
   - eg: "MANGO must <snip> properties which attributes spread out on
   multiple columns (eg positions, errors)";  The Property (Measure) handles
   the multi-column associations, MANGO is merely responsible for connecting
   to the Measure.
   - eg: "MANGO must <snip> provide an accurate description of the epoch
   propagation. <snip> consists in constructing 6 parameter position
   vectors…";
   - The epoch propagation usage thread was selected for implementation, so
      it could be a requirement on MANGO to support the properties and
      associations necessary to fulfill that case.  But MANGO is not
required to
      construct a 6 parameter position vector.. There are multiple
ways to solve
      that problem.

I think that, for the most part, the Requirements for the Properties
themselves would fall to the standards for that type of property.

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

Sorry for the long content.
Mark




On Tue, Oct 22, 2024 at 11:40 AM Laurent Michel <
laurent.michel at astro.unistra.fr> wrote:

> Dear DM,
>
> We are pleased to announce the release of the first official MANGO working
> draft.
>
> WHAT IS MANGO
> ==============
> The purpose of MANGO, which stands for MO-del for AN-notating G-eneric
> O-objects, is to add an upper level of description to the tabular data of
> query responses.
> It allows metadata to be extended, complex quantities to be reconstructed
> from multiple
> column values and properties to be linked together.
> It also allows to specify the origin of the data.
>
> WHAT TO DO WITH MANGO
> =======================
> - The main application we are aiming for MANGO is to be used in
> conjunction
>   with MIVOT to annotate DAL responses.
> - It could also be used as a common schema for machine-readable messages
>   exchanged between different parties  (SAMP, REST...).
>
> WHERE TO GET DOCUMENTATION
> =============================
> - WIKI PAGE: https://wiki.ivoa.net/twiki/bin/view/IVOA/MANGO-1_0
> - GITHUB: https://github.com/ivoa-std/MANGO
> - PREVIEW: https://github.com/ivoa-std/MANGO/releases (take the most
> recent one)
>
> HOW TO CONTRIBUTE
> ===================
> You can:
> - Comment on the Wiki
> - Comment on the list
> - Open Github issues
> - Open Merge Requests
>
> WATCHOUT
> =========
> If you plan to open MRs, please read the Wiki carefully which explains the
> workflow that is used to build a bundle made of PDF/Latex/VO-DML/Mivot
> material and do not hesitate to ask questions.
>
> All the best,
>
> The authors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250129/681469e0/attachment.htm>

More information about the dm mailing list