Coords/Measurement model RFC comment response

[CresitelloDittmar, Mark]

All,

My apologies for the delay in getting things moving on these models.  I
have had very little time to put toward VO work since the last interop.

Below are responses to, and actions to take, based on the RFC comments for
the Measurement and Coordinate models.  I will be officially implementing
these, generating new example files, and working with the Transform team to
ensure their extended use case is satisfied.  Currently, the updates for
the coords, meas, and transform models have been modeled.  I needed to
adjust the plan from the Netherlands slightly to satisfy the integration
with the Cube model.  These went to the Transform folks for review, and I
have a followup issue from them to work still.  I'm fairly confident that
this will have NO effect on the coords or meas models, but will resolve the
details prior to re-submitting the documents.  I am currently updating the
model documents.

These notes will be added to the appropriate RFC pages.

Mark

Starting from the item having the greatest impact:
*Coords*:
  1) AST implementation project expansion in scope to "enable the
description of a complete WCS ( axes, frames, mappings between )
independent of the coordinates in that space".  With the current model, the
CoordSpace and CoordFrame are only related through the Coordinate itself.
      *ACTION:* Modify model to restore an element which combines
CoordSpace and CoordFrame, which is, presumably then referenced by the
Coordinate.
      *NOTE:* this action triggers subsequent changes in the model which
are in place, at least partially, to accommodate the separation.  For
example, with the singular access point to both CoordSpace and CoordFrame
information, there is no need for the Coordinate to separately reference a
CoordSpace axis and the Frame.  I will post an outline of the logic tree
for the change set to the twiki.
      *ACTION:* This will also require bringing an object from the Cube
model, or something similar, to either Coords or Transforms.  This object
associates 2 instances of this combined CoordSpace/Frame with a Mapping
defining the transform between them.  This is similar to objects already in
the cube model to define virtual axes and columns.

  2) SpaceFrame.planetaryEphem multiplicity is 1, should be [0..1]
      *ACTION:* change multiplicity to [0..1]

  3) URL's for vocabularies - should use 'http' not 'https'
      *ACTION:* make correction in document

  4) Appx C.3 - bad LaTex for TCG and TCB records.
      *ACTION:* make correction in document


*Measurement:*
   *) Request for additional 'catalogue data' use case
       *RESPONSE:*  The current model is based on long established use
cases related to Cube data;  this request is covered by the Source model
effort.  I will adjust the text in "Context and Scope" to clarify that the
scope of this version is limited to the described use cases, while the
larger scope is retained to inform design decisions.

   *) requirement meas.003: After reading the standard, I think I
understood what that means, although I'm not sure what the reason for the
requirement is (let alone which use case it is derived from). Let me try:
"Each error instance must only be referenced by a single measurement." Is
that what you mean? If so, why?
       *ACTION:*  clarify requirement text - "A value must not be
associated with more than one each of systematic and statistical/random
errors."

   *) Error model (several comments in this arena)
       + Error.statError and Error.ranError - unclear what the distinction
is, and if it is necessary
          *ACTION:* drop <Error.ranError>  (Markus professed a mild
preference to keep 'stat' since Char/ObsCore have 'stat' based elements)
          *ACTION:* associated issue, correct multiplicity bug in model (
Measure.error[0..1] not "*" )
       + Included elements and their descriptions
          o Have Bounds*D, Ellipse, Ellipsoid and CovarianceMatrix.
             - Most other forms can be represented by CovarianceMatrix, so
why include?
             - However, if we assume Gaussian, then we also need the
"confidence level", which is not specified nor a model element.
             - Additionally, the general modeling of CovarianceMatrix is
inefficient at best.  Unclear if Matrix or Cell or some other Correlation
element might be a better approach.
           *RESPONSE:* The various flavors of error types are basic error
representations which occur in our data, and come directly from STC-1.
Forcing data providers to convert their holdings to Matrix form is not a
reasonable expectation.
           *ACTION: *Drop CovarianceMatrix until we have an implementation
case which exercises it.
       + Distributions:
           o "we should say *something* about assumed or non-assumed
distributions"
           o "When we assume that errors are Gaussian (we probably need a
way to mention it explicitly)"...
           o Confidence Level: assuming Gaussian errors, should make a
statement about the confidence level in appropriate elements.
               eg: Error ellipse assuming 68% confidence level Gaussian
distribution unless otherwise specified.
            *ACTION:* Add text to descriptions indicating that this version
of the model forms a fundamental basis from which we can grow to include
more complex and varied use cases as they present themselves.  The current
model assumes Gaussian distributions with shapes defined at the 68%
confidence level.  The exact location and nature of the text updates is TBD.
            *ACTION:* add formal modeling of 'confidence level' to 'Next'
page for Measurement model.
       + Ellipse.posAngle - needs clarification on specification ( to
clarify agreement with IAU definition of "East of North" ).
          *ACTION:* add text describing spatial case where axis1 == North
Celestial Pole, axis2 == East, so position angle goes from axis1 toward
axis2, or "East of North"
       + Alternate Error representations in catalogues ( eg: 2 std
deviations + covariance )
          *ACTION:* add to 'Next' page for Measurement model for
consideration in next revision.
          *ACTION:* adjust phrasing of requirement [meas:006] to match
goals of this version of the model (eg: Gaussian distributions at 1-sigma
level)

    *) Domain specific Measurement types ("Time", "Position",
"Polarization" ) vs "GenericMeasure"
        *RESPONSE:*  We feel there is a distinct advantage to being able to
define that Field X is a "Time" and Field Y is a "Position", rather than
having everything be a generic measurement type.

    *) Frame specific types (GalacticPosition, EquatorialPosition, etc )
       *RESPONSE/ACTION:*  These will be removed/deprecated by the proposed
Coordinates model changes, in favor of a single Position type with Point
coordinate.

    *) Velocity.coordinate frames == "same SpaceFrame" is awkward,
"measurement doesn't really talk about frames"
       *RESPONSE/ACTION: *this constraint is not necessary after the
Coordinate model changes as the Point coordinate will have only 1 frame
reference.

    *) Specialized Positions have [1] multiplicity on each coordinate, not
convenient for describing (x,y) pair with CartesianPosition (for example)
       *RESPONSE/ACTION: *this issue is resolved after the Coordinate model
changes as the Point coordinate will have [0..1] multiplicity on each value.

    *) Gaia catalogue case where positions + proper motions are more
integrally related.
        *ACTION:* add to 'Next' page for Measurement model for
consideration in next revision, Gaia is a targeted provider in the Source
model effort.

    *) ProperMotion.lon - "it is common, though not universal, practice to
quote longitudinal PM pre-multiplied by cos(lat) so that the magnitude of
the quantity is not affected by its longitudinal position".  Some statement
about this should be made in the model.
        *ACTION:* add descriptive text regarding this 'standard', but not
universal definition for position errors in longitude.

    *) Typos
        o Sec 4.1.1, 7.2.1, 8.2.1: Multiplicity is quoted as "0..*" rather
than "*"
        *ACTION:* make corrections in document



*Implementation/Serialization:*
  This stems from the specific note in the RFC comments by Markus, and
follow-up discussion among the TCG at the interop.
  My point of view, is that the DM group approved a set of implementation
requirements which does not limit to any particular serialization standard.
This is important since the data models themselves are typically several
layers below the level of interoperable implementations of science
threads.  These models have been serialized using real-world data, in
multiple formats (VOT, Annotated VOT, XML) each validating against their
schema.  This demonstrates the usability of the models.  Interoperabile
implementations only requires multiple clients to select a common format.
There is no need to delay the model progress to REC pending the approval of
a specific annotation syntax.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200220/ab7998db/attachment.html>