<div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>All,<br><br></div>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.<br><br></div><div>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.<br><br></div><div>These notes will be added to the appropriate RFC pages.<br></div><div><br></div>Mark<br><br><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>Starting from the item having the greatest impact:<br></div><b>Coords</b>:<br>
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.<br></div></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:</b></span>
Modify model to restore an element which combines CoordSpace and
CoordFrame, which is, presumably then referenced by the Coordinate.<br></div><div> <span style="color:rgb(153,0,255)"><b>NOTE:</b></span>
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.<br></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:</b></span>
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.<br><br></div><div> 2) SpaceFrame.planetaryEphem multiplicity is 1, should be [0..1]<br></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:</b></span> change multiplicity to [0..1]<br><br></div><div> 3) URL's for vocabularies - should use 'http' not 'https'<br></div><div> <b><span style="color:rgb(255,0,0)">ACTION:</span></b> make correction in document<br><br></div><div> 4) Appx C.3 - bad LaTex for TCG and TCB records.<br> <b><span style="color:rgb(255,0,0)">ACTION:</span></b> make correction in document<br></div><div><br></div><div><b>Measurement:<br></b></div><div> *) Request for additional 'catalogue data' use case<br></div><div> <span style="color:rgb(0,0,255)"><b>RESPONSE:</b></span>
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.<br><br></div><div> *) 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?<br> <span style="color:rgb(0,0,255)"><b><span style="color:rgb(255,0,0)">ACTION:</span></b><span style="color:rgb(0,0,0)">
clarify requirement text - "A value must not be associated with more
than one each of systematic and statistical/random errors."<br></span></span></div><br><div> *) Error model (several comments in this arena)<br></div><div> + Error.statError and Error.ranError - unclear what the distinction is, and if it is necessary<br></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:</b></span> drop <Error.ranError> (Markus professed a mild preference to keep 'stat' since Char/ObsCore have 'stat' based elements)<br></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:</b></span> associated issue, correct multiplicity bug in model ( Measure.error[0..1] not "*" ) <br></div><div> + Included elements and their descriptions<br></div><div> o Have Bounds*D, Ellipse, Ellipsoid and CovarianceMatrix.<br> - Most other forms can be represented by CovarianceMatrix, so why include?<br></div><div>
- However, if we assume Gaussian, then we also need the "confidence
level", which is not specified nor a model element.<br></div><div>
- 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.<br></div><div> <span style="color:rgb(0,0,255)"><b>RESPONSE:</b></span>
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.<br></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:<font color="#000000"> </font></b><font color="#000000">Drop CovarianceMatrix until we have an implementation case which exercises it.</font></span> <br></div><div> + Distributions:<br> o "we should say <b>something</b> about assumed or non-assumed distributions"<br></div><div> o "When we assume that errors are Gaussian (we probably need a way to mention it explicitly)"...</div><div>
o Confidence Level: assuming Gaussian errors, should make a statement
about the confidence level in appropriate elements.<br></div><div> eg: Error ellipse assuming 68% confidence level Gaussian distribution unless otherwise specified.<br></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:</b></span>
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.<br></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:</b><font color="#000000"> add formal modeling of 'confidence level' to 'Next' page for Measurement model.</font></span> <br></div><div>
+ Ellipse.posAngle - needs clarification on specification ( to clarify
agreement with IAU definition of "East of North" ).<br></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:</b></span>
add text describing spatial case where axis1 == North Celestial Pole,
axis2 == East, so position angle goes from axis1 toward axis2, or "East
of North"<br></div><div> + Alternate Error representations in catalogues ( eg: 2 std deviations + covariance )<br></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:</b></span> add to 'Next' page for Measurement model for consideration in next revision.<br></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:</b></span>
adjust phrasing of requirement [meas:006] to match goals of this
version of the model (eg: Gaussian distributions at 1-sigma level)<br></div><div><br></div><div> *) Domain specific Measurement types ("Time", "Position", "Polarization" ) vs "GenericMeasure"<br></div><div> <span style="color:rgb(0,0,255)"><b>RESPONSE:</b></span>
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. <br><br></div><div> *) Frame specific types (GalacticPosition, EquatorialPosition, etc )<br></div><div> <b><span style="color:rgb(0,0,255)">RESPONSE/</span><span style="color:rgb(255,0,0)">ACTION:</span></b>
These will be removed/deprecated by the proposed Coordinates model
changes, in favor of a single Position type with Point coordinate.<br></div><div><br></div><div> *) Velocity.coordinate frames == "same SpaceFrame" is awkward, "measurement doesn't really talk about frames"<br> <b><span style="color:rgb(0,0,255)">RESPONSE/</span><span style="color:rgb(255,0,0)">ACTION: </span></b><span style="color:rgb(255,0,0)"><span style="color:rgb(0,0,0)">this constraint is not necessary after the Coordinate model changes as the Point coordinate will have only 1 frame reference.</span></span><br><br>
*) Specialized Positions have [1] multiplicity on each coordinate, not
convenient for describing (x,y) pair with CartesianPosition (for
example)<br></div> <b><span style="color:rgb(0,0,255)">RESPONSE/</span><span style="color:rgb(255,0,0)">ACTION: </span></b><span style="color:rgb(255,0,0)"><span style="color:rgb(0,0,0)">this issue is resolved after the Coordinate model changes as the Point coordinate will have [0..1] multiplicity on each value.<br><br></span></span></div> *) Gaia catalogue case where positions + proper motions are more integrally related.<br> <span style="color:rgb(255,0,0)"><b>ACTION:</b></span>
add to 'Next' page for Measurement model for consideration in next
revision, Gaia is a targeted provider in the Source model effort.<br><br></div><div> *) 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.<br> <span style="color:rgb(255,0,0)"><b>ACTION:</b><span style="color:rgb(0,0,0)"> add descriptive text regarding this 'standard', but not universal definition for position errors in longitude.</span></span> <br><br> *) Typos<br> o Sec 4.1.1, 7.2.1, 8.2.1: Multiplicity is quoted as "0..*" rather than "*"<br></div><div> <span style="color:rgb(255,0,0)"><b>ACTION:</b></span> make corrections in document<br></div><div dir="ltr"><div dir="ltr"><div><br><br></div><div><b>Implementation/Serialization:<br></b></div><div> This stems from the specific note in the RFC comments by Markus, and follow-up discussion among the TCG at the interop.<br></div><div>
My point of view, is that the DM group approved a set of implementation
requirements which does not limit to any particular serialization
standard.<b> </b>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.<br><br><br><br></div></div></div></div></div></div>