Coordinates model - Working draft.

[François Bonnarel]

Hi all,

I wondered a bit where to enter into this discussion, and eventually I 
choosed to strt by this one, although there has been more material on 
the mailing list since this one was designed.


Le 08/01/2019 à 13:18, Markus Demleitner a écrit :
> Dear DM,
>
> 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.
>>>
>> 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.
> Which is fine because it's metadata.  In annotation, flexibility is
> what we need on the *data* side -- in general you don't want to force
> data providers into rigid conventions because that would typically
> force them to change their data in non-trivial ways.  That's why we
> allow all kinds of time scales, reference positions, and (indirectly)
> serialisation formats.
OK, fine.
>
> For *metadata*, that's a different thing -- this is part of the
> annotation itself and is largely controlled by "us"; it is being
> written at publication time by people looking at the VO.  Flexibility
> there only complicates both model and implementations without buying
> anything (except possibly a tiny bit of conversion work for very few
> numbers external to the data itself).
OK again. This is what we decied to do for ObsCore for example. We 
forced a lot of things in the standard for data DESCRIPTION and let the 
data as they are...
>   
>
> Hence, fixing time origin to a float (which certainly can be
> represented in all conceivable serialisations) with a bespoke
> interpretation (as a JD) doesn't hurt the generality of the model at
> all but saves quite a bit of code (and hence bugs) in the clients.

Well, here I don't follow you, Markus,  as you know from the discussion we had for TIMESYS. Time Origin is not simple generic metadata. IN a large collection of TimeSeries it may change also from DataSet to dataSet. Example by Mark which I copy paste here is exactly showing this.


> MCD , January the 14 th wrote :
> o one use case being served by these elements is the event list, where 
> we have
>      + creation time as FITS string (ISOTime)
>      + reference time for events MJDREF in (MJD)
>      + event times in sec from reference time (TIMEOFFSET)
>      In presenting this data, I want to explicitly identify what each 
> of these types are
>        * the string param 'DATE' == ISOTime type
>        * the real param 'MJDREF' == MJD date
>        * the real field "time" == TIMEOFFSET
>      We CAN have 1 type for JD, MJD, ISO ... what would be the 
> datatype of the value? presumably 'datetime'
>      which would need to take on the broader "string" or "real" 
> handling described earlier (if string =>ISOTime, if < 2400000.5... )
>      But, in my opinion, it is better to be explicit here.
>      A/*s trivial as it might be, it is not reasonable to force the 
> data providers to convert their reference times to JD.*/
... last sentence enhanced by me.


>
> ......................................................;
>>> 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, the trouble is that at least VOTable already has a distinction
> between ISO string and floating point representations, and I'd expect
> any format powerful enough to carray VODML annotation will have
> similar mechanisms (e.g., relational database tables).  So, if you
> put that distinction into the model, too, you have an immediate
> conflict of responsibilities.
>
> Which is bad for many reasons, the most urgent of which is that
> client writers have to decide what should happen if a <FIELD
> xtype="timestamp"/> is annotated as MJDDate (say).
STC ISOtime and timestamp are a little redondant (not totally, see 
below), but DALI doesn't say a word about JD, MJD, Offset etc...

So currently xtype allows to distinguish STC ISOTime from STC 
TimeInstant but not inside the latter.
>
> Just saying "it's invalid, refuse to work with it" is really
> unsatifactory -- probably the document would work just fine if the
> annotation is *removed* (because it's really a timestamp).  Telling a
> user a document that looks fine can't be processed just because of
> annotation that's superfluous in the first place (because the client
> already knows it's a timestamp) is highly annoying, and looking at
> the hacks clients writers currently make to let users work with
> half-broken data I'm sure we'd be seeing lots of ugly heuristics and
> conditional ignoring of annotation.
Well actually timestamp is also includind dates "civil in nature". see 
DALI 1.1 3.3.3

> /However, values that are civil in nature (e.g.//
> //when some processing was completed, when some record was last 
> modified)//
> //may include the time zone indicator Z to explicitly specify the UTC 
> time//
> //zone./
while obviosuly (see discussion on Z and UTC on this mailing list) STC 
ISOtime will not. xtype=timestamp has a wider extent.

So that STC ISOTime is excluding the Z and can be expressed in VOTable 
using xtype=timestamp.


>
> Why increase the number of errors document writers can make and
> clients writers have to handle when there's nothing to be gained by
> (in this case) the extra classes?
>
>
>> 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.
> Ha!  If you look at your phrase "format enumeration/flag" -- doesn't
> that already shout "serialisation"?  The point I'm making above is
> that the model simply shouldn't talk about formats, because that's
> another level of representation.  The model just has TimeInstant --
> done.
>
> Shorter model, less conflicts, same capabilities -- what's not to
> like?

The main issue is that I think we are dealing with "time representation" 
and not "serializations".
Time represention concept is presented in the Time WCS paper.
Each "time representation" involves various features : units and/or time 
origin, sometimes timescale...
Much more  than a "serialization" issue.
  SO I think the DataModel has to help defining this properly.
For this reason I agree with what has been done in the Coordinates WD.
Except on one point :

Why don't we have something for "Julian years" and "Besselian years" in 
addition ?
They are pretty common in astronomical data and seem to be well defined 
according to the same Time WCS paper.
I remember Arnold advocating against a couple of years ago, but I cannot 
remember the arguments ???

Cheers
François


>
>           -- Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20190116/5530d7e2/attachment.html>