Skip to content
Mark Cresitello-Dittmar edited this page Mar 12, 2021 · 9 revisions

Mark Cresitello Dittmar's Implementations

Mark CD comments

Models

  • Dataset:
    • Regretting the "Party|Role" levels in this model, would advocate reverting these to simple strings when we get back to working this model
  • Meas:
    • Limitations for 'unmodeled' types
      • Whose has responsibility for declaring the specific type a GenericMeasure contains? The meas:GenericMeasure does not currently have any elements to identify the flavor (eg: "magnitude", "luminosity", "temperature", etc. ). Mango has added a 'ucd' element to Property which identifies the flavor of the contained Measure. It would seem more appropriate for that to be in the Measure itself, so that clients can always expect to determine the Measure flavor from the Measure itself.
      • Photometry data (Magnitude and Flux), need references to photDM:PhotCal instances. If there is no modeled Photometry Measure type, it would be covered by meas:GenericMeasure. However, there is no means to ADD the PhotCal association using GenericMeasure. My feeling is that ADDing associations is outside the scope of the Measure model.
        How often would this come up? (That a client/data provider, wants to annotate Measure types with dependencies, which are not yet formally modeled). For this particular case, Mango has stubbed Photometry extensions to Meas/Coords to cover the case, but if there are many such cases, this would be a serious problem and annoyance to providers. What do we expect them to do instead?
    • Proper Motion: different representations in use cases, this model only supports one.
      • ProperMotion( pm_ra, pm_dec )
      • ProperMotion( pm_magnitude, position_angle )
  • Coords:
    • concept of 'epoch' vs 'equinox' was dropped at some point
      • some examples (Standard Properties; GAIA data) have ICRS frame (no equinox) at epoch="2015.5".

Annotations

  • Impact on native files:
    • HAD to add ID to VOTable TABLE node for the TEMPLATES annotation.
      • “TEMPLATES must refer to a TABLE through the tableref attribute. “
      • so this annotation scheme is not necessarily a zero-impact additive addition to data provider content
    • Used LITERALs rather than CONSTANT since native PARAMs did not have ID either
      • this duplicates the PARAM content, but avoids changing the native VOTable elements
  • VOTable version changes:
    • Native VOTable in v1.4, VODML annotation schema linked with VOTable v1.3 schema.. so my output using VOTable 1.3 namespace, which means that some elements are now invalid (TIMESYS).
      • Question regarding connection/link of VODML schema to VOTable schema.. the pair must be unique?
  • Annotating complex PARAMs: example in time-series case, ssa_location element
    • <PARAM name="position" datatype="double" arraysize="2" ref="_icrs" value="123.222 -10.000" />
    • the Mapping syntax does not allow for annotating into array elements (tag which is longitude and which latitude), not does it (I think) permit annotating the PARAM to represent the complex type coords:SphericalPosition as a whole, leaving the client to interpret the content.
    • instead, this must be annotated with LITERALs, duplicating the individual values in the annotation.

Clone this wiki locally