Coordinates model - Working draft.

[Markus Demleitner]

Mark,

On Fri, Dec 21, 2018 at 04:41:09PM -0500, CresitelloDittmar, Mark wrote:
> > Similarly (and this is quite a bit more itchy to me right now), I'm
> > strongly advocating to make TimeInstant concrete and remove all its
> > derived types (ISOTime, JD, MJD, TimeOffset).  Instead, TimeFrame
> > should grow a timeorigin attribute.
> >
> 
> We've beat around this bush a couple times.
> 
> Full disclosure, I haven't read the apps thread re: TIMESYS, but as I
> recall, it works only because it requires that timeorigin is expressed in
> JD specifically.
> This is not OK for general usage, and without the restriction you get a
> cyclical problem in the model.

Um -- what exactly is wrong with "time origins are given as single
floating point numbers in JD for the given timescale and time origin"
for, well, general usage?  What kind of notation or use case would
break with if we defined that?

I guess you won't argue that making this definition simplifies the
model quite a bit. If such a simplification comes for free (meaning:
doesn't restrict the expressiveness of the model), what's not to
like?

> > The rationale here is that the concrete form of the timestamp is a
> > *serialisation* issue, i.e., one of VOTable, FITS, or whatever else.
> > If the serialisation provides for having ISO-like dates or a binary
> > representation of civil dates or nothing of the sort shouldn't
> > determine whether you can serialise STC instances into them.
> >
> 
> Not sure I would call it a serialization issue, but yes.. its related.  The
> thing is, when we have time data, we need to convey how to interpret that
> value (which on its face is just a 'real' ).

Well, or it could be something else than a real, depending on the
serialisation (floating point, ISO, RFC 1123, ANSI C asctime, US
Date, UK Date... -- most of these we don't support (yet) in VOTable,
but casting that implementation detail of VOTable into a DM (without
getting a lot in return) means needlessly limiting the DM's
applicability (not to mention inviting errors).

Plus of course, if it *is* a real, it needs a unit, too (see Pierre's
recent post on what kind of fun they have in VizieR in this
department:
http://mail.ivoa.net/pipermail/apps/2018-December/001331.html).  

At least in the VO, we've decided to deal with both serialisation
format and unit in VOTable, and I suspect essentially all other
scientific data formats will sport a similar separation of concerns.
We're not helping anyone if we needlessly break it.

> This modeling makes it easy to convey that info.. you have a Column or
> Param which you identify as type "coords:domain.time.JD".  The alternative
> is to have a single Type (TimeInstant), and a format enumeration/flag.

What would the values of that enumeration be?  I can't quite see what
you'd want to express with it.


> Which means you need 2 bits of information to interpet the value instead of
> 1.  Both of those bits would need to be in the model, and have a vodml-id.

Well, at the application level, realistically, you need 

 * a serialisation format 
 * a unit (for floats), 
    [- border between serialisation and DM -]
 * a reference position, 
 * a time scale, and 
 * a time origin

to get from a serialized string to a "universial" conceptual time
stamp (which, ok, not all applications need, but clearly enabling
this kind of thing is what this whole effort is about).

You *can* package several of these up if you want and give the whole
thing a fixed name. This does help applications.  For instance,
VODataService will probably say that the limits of your time coverage
have to be in MJD for the BARYCENTER in TCB (if memory serves); only
this lets people efficiently do interval comparisons in the database.

But this kind of packaging should be done on the application level,
not on the level of a data model.  On the application level you know
what compromises are ok.  A DM is too general for an informed guess.
And again, linking serialisation (and units) with DM items means
entangling elements of the Model and (for us) VOTable.  Hurting both.

Exiting into a holiday slumber,

           Markus