<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi all,</p>
<p>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.<br>
</p>
<br>
<div class="moz-cite-prefix">Le 08/01/2019 à 13:18, Markus
Demleitner a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20190108121826.e52zyw66x2utdmde@victor">
<pre wrap="">Dear DM,
On Fri, Dec 21, 2018 at 04:41:09PM -0500, CresitelloDittmar, Mark wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
OK, fine.<br>
<blockquote type="cite"
cite="mid:20190108121826.e52zyw66x2utdmde@victor">
<pre wrap="">
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). </pre>
</blockquote>
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...<br>
<blockquote type="cite"
cite="mid:20190108121826.e52zyw66x2utdmde@victor">
<pre wrap="">
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.</pre>
</blockquote>
<pre wrap="">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.
</pre>
<br>
<blockquote type="cite">
<div>MCD , January the 14 th wrote :<br>
</div>
</blockquote>
<blockquote type="cite">
<div>o one use case being served by these elements is the event
list, where we have</div>
</blockquote>
<blockquote type="cite">
<div> + creation time as FITS string (ISOTime)</div>
<div> + reference time for events MJDREF in (MJD) </div>
<div> + event times in sec from reference time (TIMEOFFSET)</div>
<div> In presenting this data, I want to explicitly identify
what each of these types are</div>
<div> * the string param 'DATE' == ISOTime type</div>
<div> * the real param 'MJDREF' == MJD date</div>
<div> * the real field "time" == TIMEOFFSET</div>
<div> We CAN have 1 type for JD, MJD, ISO ... what would be
the datatype of the value? presumably 'datetime'</div>
<div> which would need to take on the broader "string" or
"real" handling described earlier (if string =>ISOTime, if
< 2400000.5... )</div>
<div> But, in my opinion, it is better to be explicit here.</div>
<div> A<i><b>s trivial as it might be, it is not reasonable to
force the data providers to convert their reference times to
JD.</b></i></div>
</blockquote>
... last sentence enhanced by me.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:20190108121826.e52zyw66x2utdmde@victor">
<pre wrap="">
</pre>
......................................................;<br>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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' ).
</pre>
</blockquote>
<pre wrap="">
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).</pre>
</blockquote>
STC ISOtime and timestamp are a little redondant (not totally, see
below), but DALI doesn't say a word about JD, MJD, Offset etc...<br>
<br>
So currently xtype allows to distinguish STC ISOTime from STC
TimeInstant but not inside the latter.<br>
<blockquote type="cite"
cite="mid:20190108121826.e52zyw66x2utdmde@victor">
<pre wrap="">
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.</pre>
</blockquote>
Well actually timestamp is also includind dates "civil in nature".
see DALI 1.1 3.3.3<br>
<br>
<blockquote type="cite"><i>However, values that are civil in nature
(e.g.</i><i><br>
</i><i>when some processing was completed, when some record was
last modified)</i><i><br>
</i><i>may include the time zone indicator Z to explicitly specify
the UTC time</i><i><br>
</i><i>zone.</i></blockquote>
while obviosuly (see discussion on Z and UTC on this mailing list)
STC ISOtime will not. xtype=timestamp has a wider extent.<br>
<br>
So that STC ISOTime is excluding the Z and can be expressed in
VOTable using xtype=timestamp. <br>
<br>
<br>
<blockquote type="cite"
cite="mid:20190108121826.e52zyw66x2utdmde@victor">
<pre wrap="">
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?
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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?</pre>
</blockquote>
<br>
The main issue is that I think we are dealing with "time
representation" and not "serializations".<br>
Time represention concept is presented in the Time WCS paper.<br>
Each "time representation" involves various features : units and/or
time origin, sometimes timescale...<br>
Much more than a "serialization" issue.<br>
SO I think the DataModel has to help defining this properly.<br>
For this reason I agree with what has been done in the Coordinates
WD.<br>
Except on one point :<br>
<br>
Why don't we have something for "Julian years" and "Besselian years"
in addition ?<br>
They are pretty common in astronomical data and seem to be well
defined according to the same Time WCS paper.<br>
I remember Arnold advocating against a couple of years ago, but I
cannot remember the arguments ??? <br>
<br>
Cheers<br>
François<br>
<br>
<br>
<blockquote type="cite"
cite="mid:20190108121826.e52zyw66x2utdmde@victor">
<pre wrap="">
-- Markus
</pre>
</blockquote>
<br>
</body>
</html>