Timesys note review

[François Bonnarel]

Hi Markus, Tom, all


Le 05/12/2018 à 09:48, Markus Demleitner a écrit :
> 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.
Yes that was the reason, and also because have it the other way should 
lead to a repetition of identical TIMESYS for several colomns.
The main issue there is not (to my eyes) that ref can come in several 
contexts but that there is one single ref allowed on each element, which 
is coming from xml itself and not from VOTable properly.

the idea is that in many cases it's sufficient. If you really need to 
refer to several elements, then using GROUPs and refer to a GROUP is OK
>
> 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.
Allowing TIMESYS and COOSYS to be part of a GROUP and ref on this one, 
should solve this issue.

Cheers
François
>
> 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