Timesys note review

[Markus Demleitner]

Hi Tom,

On Tue, Dec 04, 2018 at 03:29:31PM +0000, Tom Donaldson wrote:
>   1.  In the note PDF, tables 1 and 2 are awkwardly interspersed
>   with the content describing the TIMESYS attributes.  Even a
>   footnote is split across two pages.

Yeah -- the inserts have grown a bit too large.  I'll see how I'll
improve presentation before pushing out version 1.1.

>   1.  My domain knowledge on this is weak, so I will have to defer
>   to others for the final word, but from a computing point of view,
>   I don’t yet understand the need for the timeorigin attribute.  Is
>   it just a convenience for values that are offsets, or is it a
>   fundamental part of the time scale or system?

Yes, operators could, in principle, just add whatever they have in
timeorigin to all values in the table and be done with it.  We'd like
to avoid forcing them to do that, though, for at least several
reasons:

(a) It's nice if you don't have to touch data (as opposed to
metadata) to make it VO-annotable.

(b) The actual time values might be in microseconds, seconds or
years, and in particular in the former cases making a JD (or even
MJD) from it may lose significant digits in a big way.

(c) There are many datasets out there with all kinds of time
notations, and most of them are easily described if you have
timeorigin, which (by itself) is cheap in implementation.

>      *   Although in the astropy Time class
>      (http://docs.astropy.org/en/stable/api/astropy.time.Time.html#astropy.time.Time.SCALES
>      ) I did see clear use of time scales nearly matching those
>      proposed here, I didn’t see any use of a time origin.  Again,

I'd not be too worried about that.  There *is* a simple map, though,
if you're willing to look into implemenation, and it's related to
point (b) above: Time in astropy (as in SOFA and friends) has *two*
JD-like things.  If you use jd1 as timeorigin and jd2 as the value
you pull from the table, you've got it: in a sketch:
Time(val=@timeorigin, val2=column)

Certainly, in the run-up to a VOTable update, as a reference
implementation some astropy code showing how to merge two time series
with different reference positions (adjusting errors where
appropriate) would be a good example.  Volunteers?

While we're at it, client support will be an issue elsewhere as well.
In AST, for instance, as far as I understand reference positions and
time scales are currently linked; this makes sense from a physical
perspective, but unfortunately is not what actual datasets out there
do (*cough* "HJD" *cough*).  So, yes, if this proposal goes into
VOTable, not all time problems will magically go away -- but at least
applications will then have a fair chance to detect if they better
shouldn't do a particular operation.

>  ii.      If the attribute is needed, I’d still need to be
>  convinced that the convenience values JD-origin and MJD-origin are
>  worth the added complexity.

Since I'd rather not have them either, I'd say those who want them
should again make their points. The one thing almost making me like
them is that it's easy to say 240000.5 instead of 2400000.5, whereas
NJD-origin is easily caught.

>   1.  I have never been super happy with the context-dependent
>   meaning of “ref” (it can refer to a COOSYS, TIMEDEF, TABLE,
>   GROUP, etc., depending on where you are, and not all the
>   reference semantics are clear).  I realize we’re kind of stuck
>   with that concept for now, so I’ll just ask the dumb question of
>   whether or not a FIELD that references a TIMEDEF may also want to
>   reference something else such as a GROUP.

Yes -- that is one of my serious concerns with (ab-) using @ref in
this way.  

In my original design, TIMESYS had a @time attribute referencing the
FIELD or PARAM designed.  In discussions between the authors, that
was struck down, essentially because we want to have TIMESYS fast and
not discuss about earlier design mistakes; also, I had to admit that
having different patterns between TIMESYS and COOSYS would not be
pretty, either.

So, yes, @ref is ugly and prevents many annotations we'd like to
have -- in particular: often, a time is part of a COOSYS ("this is
the epoch for which the coordinates are given"), and so the FIELD
should be referencing *both* TIMESYS and COOSYS.  

But unless there's more voices saying "yeah, let's start cleaning
this up now" I'll not re-open this discussion among the authors.

          -- Markus