md

md-proposal

Mark CD comments

Models

• The models used in these serializations do not map to any existing model/model-in-progress with the possible exception of Dataset.
  This makes it difficult to compare annotations since the basis is not the same.

Annotation

• Annotation syntax allows for duplicating content, or referencing PARAM|FIELD if ID is available, ie: LITERAL, CONSTANT.
  • so, I think this syntax has minimal impact on the native content.
  • FIELDs, I suppose, MUST have an ID. This is true with all of the annotation schemes?
• Relies on clients to use VOTable content to fully resolve model elements.
  • use FIELD ucd="phot.flux" or "phot.mag" to identify/destinguish the nature of the axis as Magnitude vs Flux
    The UCD value is the ONLY difference. Well, the PhotCal instance includes a reference to the respective columns, but that is not part of the PhotDM model.
• Allows for annotating multiple versions of any particular object
  • meas:Position may have different content in Measurement V1.0, V1.3 and V2.0. This scheme allows annotating multiple versions, with the expectations that users will find the one that they understand/prefer.
    • VODML modeling requires Model A imports a specific version of Model B. So a ds:Target.position expects a specific version of meas:Position.
    • this does not necessarily mean that the annotation must be so directly connected. In the other extreme, COOSYS and TIMESYS can be considered annotations of many versions of coords:SpaceSys and coords:TimeSys, but the mapping is less clear.
    • I don't have a suggested solution here, but I don't think the answer is to disassociate the models, so that it is not possible to specify that ds:Target.position MUST be a meas:Position instance rather than photDM:PhotCal or duplicating meas:Position within Dataset.
• Time series case, amended, has multiple representations of 'position' content within the same position ATTRIBUTE
  • as "ra", "dec"; and as a Dali "point"; the client can choose which they understand/prefer.
  • since the annotation reflects the model structure. Using the 2 annotations of "stc2:SphericalCoordinate", the underlying model would be:
    • SphericalCoordinate
      • frame
      • longitude
      • latitude
      • value: ssa_location (which includes longitude, latitude and some frame info) is assigned to this attribute which really should not be an attribute of SphericalCoordinate.)
  • I'm concerned that the approach is throwing in adhoc solutions (adding a 'value' attribute), when it hits a snag (Dali "point" cannot be directly annotated as a SphericalCoordinate).
• I'm still struggling to understand the relation between this annotation and the underlying models.
  • Markus mentioned python dynamic typing as a corollary, but it seems only partially considered.
    If I write a method which accepts a Position type argument; it is true that one can input ANY class type to the method, but you should expect the method to throw an Exception if the class does not behave as a Position.. have the right attributes and methods. If the code is written to expect version 1 meas:Position type specs, it will not automatically work on a Position type coded to meas:Position version 2 specs, or a Dali:Point" of any version.
  • If the model cannot specify that ds:AstroTarget.position is a meas:Position type (ie: latest minor version of the model owning the namespace "meas"). Then clients have no way to know what to expect at that attribute. I don't see how that facilitates interoperability.
  • In both code and models, there must be a migration when versions change.
• Q: how does this play out if an object "stc2:Coords" is made entirely of LITERALs? There will be no 'ref' content to match.

---