<div dir="ltr"><div dir="ltr"><div>All,<br><br></div><div>Maybe we can bring this tread to a conclusion now?<br><br></div><div>re: &#39;side issue&#39; on standardized, high usage coords (EclipticCoord, GalacticCoord, etc).<br></div><div>  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 )<br></div><div><span style="color:rgb(255,0,0)"><b>ACTION:</b></span> I will start a new thread for this specifically... I need direction in this in order to proceed with the Measurement model.<br></div><div><br>re: discussion on existence of distinct MJD, JD, ISOTime, TimeOffset classes<br></div><div>  o The objection seems to stem around the <b>annotation</b> 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 &#39;ISOTime&#39; annotating a PARAM|FIELD with &#39;xtype=timestamp&#39;.  I believe that this is <b>not</b> a model problem, but rather a discussion for the Mapping syntax, which I STRONGLY encourage take place on another thread.<br></div><div><br></div><div>re: the offset (time0) should be defined exclusively to be JD, thereby allowing it to be a simple &#39;real&#39;.<br></div><div>  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.<br><br></div><div>re: use cases/requirements<br></div><div>  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 <a href="https://wiki.ivoa.net/twiki/bin/view/IVOA/STC2" target="_blank">twiki</a>, 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&#39;d appreciate a pointer to use as a template.<br></div><div>  <span style="color:rgb(255,0,0)"><b>ACTION:</b></span>  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. <br></div><div><br></div><div>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.<br><br></div><div>I&#39;d appreciate any further comments on the model...  perhaps in a new thread though.<br></div>Mark<br></div></div>