Error types and relation to Measurement model Uncertainty

[mcdittmar]

These comments are on version (commit 27c4bd3) and follow #59.

In this model:

• PropertyError: extends Meas:Uncertainty with "confidenceLevel"
  • In Ian's talk in Sydney, one of his conclusions was "Even quoting measurement and confidence limits don’t forget that the shape of the distribution (e.g., Gaussian) and the confidence level (e.g., 68%, 95%) must be captured for the measurement to be useful"
  • So this confidenceLevel should be proposed as an update to the Meas:Uncertainty type.

This would create a bit of a cascade, since Mango currently has all of the relevant error types for this use case extending PropertyError so that they have the confidenceLevel attribute.. however

• mango:error.Symmetric1D is equivalent to meas:Symmetrical
• mango:error.Asymmetric1D is equivalent to meas:Bounds1D
• mango:error.Ellipse is equivalent to meas:Ellipse
  There are variations in the attribute names and structure, but the definitions are the same. We should avoid such duplication of objects.

If confidenceLevel were moved into meas:Uncertainty, the only Error items needed in Mango would be the ErrorCorrMatrix and ErrorCovMatrix objects.. unless these are decided to be properly generic for migration to Measurements, but I think that is another topic.

[lmichel]

PropertyError: extends Meas:Uncertainty with "confidenceLevel"

We should add a distribution attribute (poisson, gaussian,... ) along with the confidence level.

[lmichel]

confidenceLevel should be proposed as an update to the Meas:Uncertainty type

This has been proposed by François Xavier Pineau (@fxpineau) in the RFC1 (post from 2019-09-24).
This proposal has been discarded because it didn't cover any model use-case (see thread). On the other hand, it's part of the MANGO's use-cases.
It's certainly a shame, but I don't think there's anything to be gained by starting a process to update Meas before MANGO is adopted. It would take an enormous amount of time for a hypothetical gain.

[lmichel]

mango:error.Symmetric1D is equivalent to meas:Symmetrical

Yes, this is a way to implement the model view we were talking about at last running meeting.
These Mango classes import concepts from Meas and apply them in its own context.

[lmichel]

mango:error.Ellipse is equivalent to meas:Ellipse

mango:ellipse is not exactly equivalent to meas:ellipse in a sense that the latter attaches roles (major axis vs minor axis) to vector coordinates (Ellipse.semiAxis card=2), whereas MANGO use explicit attributes for each of the axes.
After playing with MIVOT, it turned out that the attribute approach is easier to use.

However, MANGO imports Meas's definitions and uses them in its own context, so that both models keep compliant .

[mcdittmar]

confidenceLevel should be proposed as an update to the Meas:Uncertainty type

This has been proposed by François Xavier Pineau (@fxpineau) in the RFC1 (post from 2019-09-24). This proposal has been discarded because it didn't cover any model use-case (see thread). On the other hand, it's part of the MANGO's use-cases. It's certainly a shame, but I don't think there's anything to be gained by starting a process to update Meas before MANGO is adopted. It would take an enormous amount of time for a hypothetical gain.

Exactly.. at that time, I didn't have a use-case and example data which would allow for proper modeling of confidenceLevel, so it was delegated to a future update of the Measurements model. If the use-cases for Mango include an example which requires confidenceLevel, then that is a perfect opportunity to implement that element.

I still need to review the document to see how the use-case ties in with the current modeling in Mango. The recent addition of 'distribution', which I'm assuming is tied to the confidenceLevel, implies that it should be an Object/DataType and not a pair of attributes. There is also confidence intervals discussed in the use cases which must relate somehow.

[mcdittmar]

mango:error.Symmetric1D is equivalent to meas:Symmetrical

Yes, this is a way to implement the model view we were talking about at last running meeting. These Mango classes import concepts from Meas and apply them in its own context.

I understand why you might have local versions of the Measurement model uncertainty types.. IF they require the confidenceLevel attribute to satisfy your use cases. That 'copy' should duplicate the Measurement model element. To define an equivalent, but slightly different object is contrary to the spirit of vo-dml modeling where we have a single, reusable specification for the concept.

The more troubling conflict is the mango:error.Asymmetric1D maps to meas:Bounds1D rather than meas:Asymmetrical1D.

[mcdittmar]

mango:error.Ellipse is equivalent to meas:Ellipse

mango:ellipse is not exactly equivalent to meas:ellipse in a sense that the latter attaches roles (major axis vs minor axis) to vector coordinates (Ellipse.semiAxis card=2), whereas MANGO use explicit attributes for each of the axes. After playing with MIVOT, it turned out that the attribute approach is easier to use.

However, MANGO imports Meas's definitions and uses them in its own context, so that both models keep compliant .

Again, creating equivalent, but slightly different modeled objects is contrary to the vo-dml modeling practice.

The meas:Ellipse object is modeled the way that it is, so that there is a connection between the semi-axis value and the Coordinate Space axis that it is oriented with (at posAngle=0).

With the mango:Ellipse object, I believe this is expecting the 'major' axis to orient along axis2 (longitude) when angle=0, which I don't believe is a requirement.

[fxpineau]

With the mango:Ellipse object, I believe this is expecting the 'major' axis to orient along axis2 (longitude) when angle=0

There is a typo in the document, section 5.2.3 Ellipse.angle.
NCP should stand for North Celestial Pole, not for North Polar Cap.
So, the position angle is defined with respect to the north celestial pole, which has the advantage of being independent from the reference frame.

[mcdittmar]

With the mango:Ellipse object, I believe this is expecting the 'major' axis to orient along axis2 (longitude) when angle=0

There is a typo in the document, section 5.2.3 Ellipse.angle. NCP should stand for North Celestial Pole, not for North Polar Cap. So, the position angle is defined with respect to the north celestial pole, which has the advantage of being independent from the reference frame.

Thanks for noting that typo, and the clarification on the position angle.

Can you comment on the major/minor axis pieces as well? I'm mostly trying to make sure I don't have an error in the Measurements model, but I think the MANGO representation doesn't have enough information to properly define the ellipse.

I believe the semiMajor/Minor axis value needs to be associated with an axis in the reference frame in order to specify how to orient the ellipse before rotating it (i.e. is it | or -- ) .

The meas:Ellipse does this by having the user provide the values in the order of the axes in the coordinate space (coords: Standard Spherical Coordinate Space). The larger value would be the semiMajor axis value, and the smaller is the semiMinor axis value.

The mango:error.Ellipse doesn't allow for this association of semiMajor -> lat or lon axis (for example).
The description of mango:error.Ellipse.angle states this is the angle between the NCP and the 'major axis', which implies

1. the coordinate space is Celestial
2. the major axis is associated with the longitude axis; ie the ellipse major axis is oriented along the longitude axis when the angle == 0.
   This provides enough information to plot the ellipse, but I don't think users will appreciate/recognize the constraints unless they are trying to plot/use it.

[fxpineau]

Should section 5.2.3 Ellipse.angle also state that the angle value ranges from 0 degree (inclusive) to 180 degrees (exclusive), i.e. the "classic" definition of a position angle?

I believe the semiMajor/Minor axis value needs to be associated with an axis

PA = 0 correspond to a major axis pointing towards the north celestial pole.
I believe that as long as the center of the ellipse is not located on one of the two celestial poles, the position of the center of the ellipse on the unit-sphere (in any system related to the unit-sphere) plus major and minor semi-axis and the PA (all three are independent from the system), plus the position of the NCP in the particular system, describe unambiguously a particular ellipse on the unit-sphere.
No need to associate the ellipse parameters to a reference frame.

Although a reference frame must be provided for a covariance matrix (but it is complicated, since positional errors are defined in a local frame, e.g. the error is usually not on the longitude, but on the longitude*cos(latitude), except for some old catalogues if I am correct), it is not needed for an ellipse defined from both semi-axis and an angle related to the NCP.

[...] which implies

1. yes, the coordinate frame has to be related to the unit-sphere and we have to know how to compute the position of the NCP in the frame.
2. yes and no: the major axis is associated with the direction of the NCP (which depends on the coordinate frame), it correspond to the longitude axis if the NCP corresponds to the north of the coordinate frame. E.g., it is the case for ICRS, but not for Galactic.

I don't think users will appreciate/recognize the constraints unless they are trying to plot/use it

It is the way things have been defined in astronomy...
Now, you can make two kind of ellipse:

• astroEllipse defined with the astronomical conventions (i.e. NCP)
• localEllipse defined with the major-axis oriented along the local x-axis when the angle=0 and along the local y-axis when the angle=90 deg (but do not call such an angle a position angle).

[lmichel]

For the record: mango:ellipse is meant to be used in the context an EpochPropagation instance, where the space frame is defined as well as a flag telling the Cos(lat) has been applied.
We have to think about the dual definitions proposed by @fxpineau

[lmichel]

    mango:error.Symmetric1D is equivalent to meas:Symmetrical

Yes, this is a way to implement the model view we were talking about at last running meeting. These Mango classes import concepts from Meas and apply them in its own context.

I understand why you might have local versions of the Measurement model uncertainty types.. IF they require the confidenceLevel attribute to satisfy your use cases. That 'copy' should duplicate the Measurement model element. To define an equivalent, but slightly different object is contrary to the spirit of vo-dml modeling where we have a single, reusable specification for the concept.

The more troubling conflict is the mango:error.Asymmetric1D maps to meas:Bounds1D rather than meas:Asymmetrical1D.

I agree, we have to review the mango error classes to make them matching with their Meas counterparts.

About the VO-DML spirit and regarding my own experience with the annotations, I can say that building objects from components issued from different models is very tough (discouraging):

• It is acceptable to import classes from external models if they are isolated (association) on the host model as with the time/space frames.
• It is not workable to mix (composition) together elements from different models as we could do by e.g. inserting Meas:LonLatPosition in Mango:EpochPropagation .