Coords/Measurement model RFC comment response
Laurent MICHEL
laurent.michel at astro.unistra.fr
Tue Feb 25 10:59:10 CET 2020
Dear all,
Thank you Mark for this RFC answser.
- The new design of the space coordinates with classes better matching
entities usually used by astronmers, is a big improvement.
- It is very valuable for the model to clearly state its limitations
(error modeling, use cases) in the spec.
- I agree with you that the model must be validated against real data
but that validation must not be bind to one specific annotation mechanism.
I propose to put a link to your message in the RFC pages instead of
copying your anwsers one by one, which would be a waste of time.
As you are proposing significant changes in the model design (I speak
for both Meas and Coord), I think we have to formally extend the RFC
cycle on a new Wiki page with document pointers and data samples fitting
the new model features.
Let me know whether you agree or not.
Laurent
Le 20/02/2020 à 20:11, CresitelloDittmar, Mark a écrit :
> 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.
>
>
>
--
---- Laurent MICHEL Tel (33 0) 3 68 85 24 37
Observatoire de Strasbourg Fax (33 0) 3 68 85 24 32
11 Rue de l'Universite Mail laurent.michel at astro.unistra.fr
67000 Strasbourg (France) Web http://astro.u-strasbg.fr/~michel
---
More information about the dm
mailing list