mcd

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
    • TimeSeries case - Magnitude and Flux, need references to photDM:PhotCal instances, but Meas:GenericMeasure does not allow for this association. In theory, these types are defined in the Spectral model, with PhotCal added to a FluxFrame. But for the purposes of this exercise, they are unmodeled since they are not defined in Measurements or Mango.
      How often would this come up? (That a client/data provider, wants to annotate Measure types which are not yet formally modeled)
      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 )

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.

---