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".
• Dependencies:
  • There is concern about the 'building block' nature of these models and the ramifications this has on version updates.
    • if Coords has a major version update, what is the effect on the hierarchy of models which use it?
  • Effect
    • if the dependency endpoints are unchanged in the Using model, it would require a minor-version update to change the version of the imported Coords model.
    • if accommodating the dependent model updates is done in a backward compatible manor, this is a minor-version update to the Using model.
    • otherwise, a major-version update to the Using model would be required.
    • To fully integrate the dependent model update, new versions of the Using model hierarchy would need to be generated.
      • This could be handled by making the Annotation less dependent on model version: Is this an option?
      • This is true for any Standard. When a new version comes out, users must migrate. But is this chain too long?
  • Cost
    • decoupling the models
      • makes it impossible to validate a serialization since the Type at the dependency points is undefined
        • well, you could validate that each piece is valid per their model, but not that you have a valid 'ensemble' (TimeSeries).
      • it relies on providers to put reasonable content at each of these occurrences.
      • clients must search for instances which can be used at each of these occurrences... may or may not find something they understand.
        • Could this tag be something other than a PARAM|FIELD reference? maybe use the <COLLECTION> type annotation to provide the <INSTANCE> ids which satisfy this role.
          • note: this could be useful even within the current scheme, to provide the same information at different depths. we haven't covered regions (so out of scope?), but this overlaps with Markus' case.. describe the footprint as reg:Circle AND reg:Moc. In this case, they are different representations of the same attribute/type (Blah.footprint::Region[1]).
  • Scope
    • this discussion has centered on the model-dependency points (ds:Target.position -> meas:Position),(meas:Position.coord -> coords:Point)
      • these locations have the largest effect on implementations due to the strict model version dependency
      • however, the model boundaries are fairly arbitrary
        • we could reduce some of the issue by re-merging Meas and Coords models.
      • and the concept applies to elements within a model as well.
        • Radio has different definition of PhotometryFilter, do we make a major version update to PhotDM? or facilitate an override so that xyz:RadioPhotometryFilter can be used in place of phot:PhotometryFilter in a phot:PhotometrySystem or be referenced by phot:PhotCal.

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