Spectral Data Model V2.0 working draft

[Mark Cresitello-Dittmar]

My notes from meeting with Mireille Louys to review the SpectralDM 2.0 draft
against ObsCore and Char 2.0.  Specifically the UType set.

Only got through comparison of Spectral and ObsCore, but Char 2.0 is in close
agreement with that, so we should not have an issue.  It is agreed that we
should go through the Char 2.0 comparison before releasing.

General
   + Spectral model does not list generic 'CharAxis' utypes.. only the named types.
   Since it the spectral model works exclusively with the named types
   (e.g. SpectralAxis), this is not considered an issue.

   + Clarify Axis Requirements diagrams. and title.  The inclusion of
   “BackgroundModel” to the Char side of the diagram when it is not (ever) allowed
    is confusing.  In addition, modify the title to better indicate that this
    diagram shows axis requirements and not a relation of elements.

   + One comment already received on the model is the use of xmlns namespace
   declaration, and the term “namespace” in general.  To serve the desire to retain
   a connection between the serialization and the corresponding model, the
   following enhancement to Dataset.DataModel is suggested.
    * Dataset must allow 0:* (at least 2) DataModel objects to identify both core
      model and 'extended' model content.
    * Dataset.DataModel.Name
      Dataset.DataModel.Prefix
      Dataset.DataModel.uri

Comparison with ObsCore utypes
   Char.*Axis.Calibration:
    + ObsCore uses “calibStatus”
    + Spectral has the same enumeration set for each axis, while some values (like
      'normalized') applies only to the observable axis (FluxAxis)

   Char.*Axis.StatError:
    + ObsCore uses the full STC hierarchy for the value (StatError.refval.value).
      By simplifying the utype to the base element, there is no opportunity for
      extending in the future.  It is strongly suggested that we add the depth
      for the value attribute.  The model CAN still require that the units of
      these attributes MUST be the same as the corresponding value, and not define
      the utypes, but the list would become more consistent.

   Char.*Axis.Coverage.Bounds.Start/Stop
    + ObsCore uses stc 'limits' structure below 'bounds' to represent the interval.
      In this case, the simplified Start|Stop convention is preferable.
    + However, the description can be enhanced to specify the relationship to
      Min|Max as expressed in the attribute UCDs.

   Char.SpectralAxis.Resolution.refVal
    + This is more in agreement than StatError.  It should be noted that the
      ObsCore model uses this same utype for the time and spatial axes, so has
      this difference itself.

   Char.SpectralAxis.ResolPower.refval
    + Spectral model utype is wrong.. missing “Resolution” level and so does not
      agree with text. The corrected utype matches ObsCore.

   DataID.DatasetID
    + ObsCore uses ObservationID, but the Spectral value seems more appropriate.

   Curation.Date
    + When ObsCore adopted these elements, this attribute became 'releaseDate'.
      It is not certain that any action is suggested here.


Spectral vs Characterization 2.0
   SamplingPrecision
    + This node name is simplified to 'Sampling' in Char 2.0, which is a change
      from earlier versions.
    Q: Spectral is currently baselined to agree as much as possible with
       Char 1.?.  I would suggest leaving this as is until a minor update reconciles
       the the model against the updated Char, but we may want to go straight for
       this, which means a review of the Section 3.0 against the new model.