DALI 1.1, time annotations
Mark Taylor
M.B.Taylor at bristol.ac.uk
Thu Feb 18 15:16:46 CET 2016
On Thu, 18 Feb 2016, Markus Demleitner wrote:
> Hi everyone,
>
> On Wed, Feb 17, 2016 at 04:25:21PM +0000, Mark Taylor wrote:
> > That's fine, but I would also like to be able to mark columns in a
> > VOTable that contain timestamps in other formats, e.g.: MJD, JD,
> > decimal year (maybe others ... Unix milliseconds???).
> >
> > At the moment there is no way to mark up a VOTable column in such a
> > way that you can tell this is what it contains.
> > Units are some help, as are UCDs which can (when present)
> > distinguish between an epoch and a duration. But none of these
> > can distinguish between a JD and an MJD, because they can't
> > specify a zero point.
> >
> > This seems to me like a prime use case for xtypes. So I would
> > suggest at least the following xtype values:
> >
> > xtype="mjd"
> > xtype="jd"
> > xtype="decYear" (?)
> >
> > Perhaps experts from CDS can advise on what forms timestamp
> > columns actually exist in in the wild.
>
> I have all of them in my database, for starters, and I'd dearly love
> to have some way to mark this stuff up in a way that clients actually
> understand it[1].
>
> And until DALI 1.1 I'd actually have agreed to using xtype like this.
> But DALI 1.1 defines the "interval" type using xtypes, and given
> that's already in use in SIAv2 (and the SODA draft) it's unlikely
> that we can banish that ghost back into the bottle again even if we
> could reach a consensus that's desirable (you'd have my vote,
> though).
>
> This means that anything that we may ever want to use as interval
> boundaries cannot be marked up using xtype (unless we made xtype a
> compound -- shudder). And at least for mjd that is very definitely
> the case (both SIAv2 and SODA already have cases).
Oh boy. I hadn't spotted that.
I could point out that strictly speaking this doesn't affect DALI 1.1
as written, since the current draft says both (sec 3.3.3):
"Date and time values must be represented using the convention
established for FITS" [which uses string literals]
and (sec 3.3.4):
"Numeric intervals are pairs of floating-point values (float or double)."
so you can't have time intervals (if it's an interval it has to be
numeric, and if it's numeric it can't be a timestamp).
But that doesn't seem like a very satisfactory escape, especially
since I'm complaining about at least one of those restrictions
in a different thread.
To me, xtype="mjd" is more persuasive than xtype="interval".
And DALI 1.1 isn't actually out of the bottle yet - I didn't even
know there was a draft until I saw it referenced in the
SODA WD announced on Christmas eve. But if xtype="interval"
is fundamentally baked in to the multi-D juggernaut I suppose
I'll have to lump it.
> My take on all this is: We need to stop heaping hacks upon hacks and
> finally do a usable *and used* STC data model including a VOTable
> serialisation for it. If we had had the courage to go the proper way
> through a parameter data model for interval, we wouldn't be in
> the fix we're in now. So, let's not repeat history here.
I'm not sure I wouldn't support hack-upon-hack here (compound xtype?
xtype="mjdinterval"?). But probably it wouldn't take much pressure
to embarrass me out of it.
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776 http://www.star.bris.ac.uk/~mbt/
More information about the dal
mailing list