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

---

LM comments

Annotations

• We had a lot of discussions about possible syntax simplifications, a though job anyway. I've a couple of questions:

  • Why using a COMPOSITION each time an INSTANCE is nested in another. The spec says p 50 the For multiplicity greater than 1 the attribute must be interpreted as an array of fixed size.. My interpretation is that for multiplicity = 1 The attribute is not interpreted as an array. I guess that INSTANCE element could be nested.
  • Why using 2 nested element to refer to another instance where one INSTANCE with a dmref coud do the job.
  • The ATTRIBUTE element is different on whether it is populated with a LITERAL or with a COLUMN. It is consistant but my trouble that, in this case, the hierarchy of the XML elements depends on the data structure which is not desirable. If a quantity required by the model is not present in the columns, we have ot use LITERAL or COLUMN otherwise.

• Table iteration

  • In the identity case, the annotation implicitely says that one mango:Source instance has to be set per table row.
  • In the time series case, only one TS instance has to be set for the whole table and this instance contains an array of points (one per table row).
  • To get this distinction I had to infer on the nature of the models (or I miss something). The problem is that the annotation syntax does not tell the parser when it has to iterate on the table. This the major difference with my syntax proposal (TABLE_ROW_TEMPLATE element).