Timesys note review

[Markus Demleitner]

Hi,

[Followups to apps at ivoa.net, please]

I've slightly updated the Timesys note, incorporating some feedback; in
particular, this fixes a broken example and updates descriptions of the
time scales (volute revs. 5235 and 5236).  Before we publish version 1.1:
does anyone have other changes?  Or corrections to the changes? 

A pre-built PDF is available on
http://docs.g-vo.org/timesys-draft.pdf, the source is still available
from
https://volute.g-vo.org/svn/trunk/projects/time-domain/timesysnote.

Let me use this opportunity to reply to two of Arnold's points:

On Tue, 6 Nov 2018 15:10:15 -0500, Arnold Rots <arots at cfa.harvard.edu> wrote:
> Whether or not you want to include orbit ephemerides depends on the
> question: what timing accuracy is needed?
> If a dataset specifies TOPOCENTER and requires, say, a microsecond
> accuracy, one will have to provide the location of the instrument, whether
> it is earth-bound, in low-earth orbit, in L3, or wherever. There is no
> escaping this.
> On the other hand, if second-accuracy is required, the timestamps can
> simply be converted to GEOCENTER by changing the systematic time error
> parameter to (roughly) 25 ms for earth-based, 30 ms for LEO, 400 ms for
> Chandra, etc., without touching the actual timestamps values.

I like the pragmatic approach proposed here which, I think, would work
well as a default mode for interoperable clients that (I think) can't in
general be expected to do orbit integrations or even know orbits.  I
think it would be great if the note at some point included
explanatory text on the and would gratefully accept contributions.

There's one thing missing, though: TOPOCENTER as a such doesn't tell you
if you're on Earth or in L2, so a client can't automatially fix
errors.  

If we keep refpositions in a vocabulary, that's a good place to
repair this.  Our vocabulary mechanism lets you to define a hierarchy
of terms in a machine-readable way; so, clients incorporating or
retrieving the vocabulary would work their way "up" to a term they
understand if they saw a <TIMESYS refposition="MAUNA_KEY">, say.

Consider (as a concept):

TOPOCENTER
   +------- EARTH_SURFACE
   |             +-------------- LA_SILLA
   |             +-------------- MAUNA_KEA
   |             `-------------- CAMBRIDGE_UK
   +------- LEO
   |         +------------ ISS
   |         `------------ ROSAT
   `------- EARTH_L2
                +------------ GAIA
                `------------ JWST

and so on.  If a client happens to know MAUNA_KEA, it can use a proper
transformation.  If not, it can *from the vocabulary* (i.e., from a
resource maintained by "us") figure out that it's EARTH_SURFACE and that
it therefore has to bump the systematic error by 25 ms.  If it
doesn't know about EARTH_SURFACE, it can still figure out that the
times are TOPOCENTER and that it should be careful.

There is, of course, no need to have (m)any "terminal" nodes (i.e.
observatory/probe names) from the start (or even ever).  There are
initiatives on the way for collecting a vocabulary of known
observation platforms (ground-based and space-borne) -- the terms
there could simply have a defined relationship (how about
http://ivoa.net/rdf/relationships#approximate-location?) to one of our
TOPOCENTER children.

That would still mean that having a solid collection of first-level terms
(LEO, EARTH_L2, ...) together with a bit of implementation advice if and
when TIMESYS goes into VOTable REC would be great.  Volunteers?

And then:

On Thu, 1 Nov 2018 15:37:14 -0400, Arnold Rots <arots at cfa.harvard.edu> wrote:
> I maintain that the better way to indicate the actual time stamp value
> (i.e., not the TIMESYS) is to use well established representations.
> Both JD and MJD are officially recognized by the IAU, while the limited
> ISO-8601 is a convenient user-friendly representation that has the blessing
> of the ISO.
> [...]
> So, I would suggest adding to TIMESYS an attribute like
> origintype=JD|MJD|ISO and to the timestamp an attribute like
> timetype=JD|MJD|ISO|ELAPSED and requiring the timeorigin and the unit only
> to be present for timetype=ELAPSED.

JD, MJD, fractional years and much more are, in essence,
*presentations*, i.e., what a client or a library exposes to its
user.  I totally agree that for most clients, it is highly desirable
to offer "Display in JD", "Display in MJD", and "Display as civil
date" (and probably much more).

For a transport or annotation format, on the other hand, it is highly
desirable to (a) avoid equivalent representations -- each equivalent
representation is a source of bugs you get nothing for.  And it's
important to (b) avoid conflicts of responsibility between various
layers wherever possible.

So, TIMESYS gives time *metadata*.  It therefore has no business
declaring serialisation formats (such as whether the time is written as
an ISO string or a fractional year) – in VOTable, we already have FIELD
attributes for that (datatype, arraysize, unit, and xtype), and they
do a reasonably good job at it.

Trying to second-guess that FIELD metadata in a different VOTable
element would violate rule (b); all you get are more ways to write
invalid VOTables: It doesn't let us write anything valid in addition
to what we already can write.

Defining some special annotation for timeorigin=0 and
timeorigin=2400000.5 then violates rule (a) -- it just introduces
different ways to express the same semantics.  

With these two equivalent representations you open a can of
unpleasant questions: how should a client decide whether to
annotate an MJD column with <TIMESYS origintype="MJD"> or with
<TIMESYS timeorigin="2400000.5">?  Should the second form be
outlawed?  What happens if a client encounters that declaration?

So, while giving choice on the presentation layer certainly is a good
idea (and I'd be open to recommending certain patterns to client
writers), choice on the transport layer is an implementation
liability and therefore better avoided.  Since it seems that
timeorigin is enough to cover all cases that were mentioned, I've not
changed the TIMESYS model in the note-1.1 draft.

           -- Markus