Coordinates model - Working draft.

[CresitelloDittmar, Mark]

All,

Maybe we can bring this tread to a conclusion now?

re: 'side issue' on standardized, high usage coords (EclipticCoord,
GalacticCoord, etc).
  o this got no uptake in the thread, but ties in with a discussion which
has taken place when working the Measurement model.  There, it was
requested to fold velocities back in, specifically to support
ProperMotion.  That discussion leads me to believe that maybe these
standardized coordinates should maybe be more atomic and tied to the
standard coordinate spaces  ( Latitude, Longitude, Spherical_R,
Cartesian_X, Cartesian_Y, Cartesian_Z ).  These can be re-used in
Measurements model as  EquatorialPosition( ra:Longitude, dec:Latitude ) and
ProperMotion( delta_ra:Longitude, delta_dec:Latitude )
*ACTION:* I will start a new thread for this specifically... I need
direction in this in order to proceed with the Measurement model.

re: discussion on existence of distinct MJD, JD, ISOTime, TimeOffset classes
  o The objection seems to stem around the *annotation* in VOTable.  That
annotating data using this model and current VODML Mapping syntax for
VOTables would produce elements in the serialization which are redundant
and vulnerable to inconsistency.  A specific example is with the type being
'ISOTime' annotating a PARAM|FIELD with 'xtype=timestamp'.  I believe that
this is *not* a model problem, but rather a discussion for the Mapping
syntax, which I STRONGLY encourage take place on another thread.

re: the offset (time0) should be defined exclusively to be JD, thereby
allowing it to be a simple 'real'.
  o Will NOT be adopted in the model.  Specific applications (eg: DAL
protocols) can constrain the usage to JD, but a primary goal of the models
and corresponding annotation is to allow data providers to
annotate/describe the data as they currently exist in their data products.
For that, the model needs unambiguously identify each type.

re: use cases/requirements
  o Near the end of this thread, more appeals for detailed requirements
derived from the use cases and mapping to the model elements.  The models
were generated with a very specific use case and set of examples, nearly
all elements of the model are represented in the example serializations.
Some items are retained from the STC1.33 model, but are not directly
represented in the current cases (eg: SpaceFrame.planetaryEphem,
TimeFrame.refDirection, CustomRefLocation in the spatial domain ).  I have
the use case/requirements outlined in the twiki
<https://wiki.ivoa.net/twiki/bin/view/IVOA/STC2>, but not at the level of
detail needed to map the objects directly.  If there is a REC with that
level of detail already in our system, I'd appreciate a pointer to use as a
template.
  *ACTION:*  I will update and detail the cases; refine the derived
requirements to separate by model;  map the boxes to the requirements.  I
will add this to the document in Section 1 and the mapping as an appendix.

Thanks to everyone who participated, some of this was re-hashing old
discussion, but I think we all have the same goal of putting out a product
with the best possible chance of uptake.

I'd appreciate any further comments on the model...  perhaps in a new
thread though.
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20190118/3fcd793e/attachment.html>