Coordinates model - Working draft.

Wed Jan 9 17:15:11 CET 2019

I'd like to hear other opinions on this.. otherwise the discussion will
remain rather circular.

more in-line

On Tue, Jan 8, 2019 at 7:44 AM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> 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.
>
> 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).
>
> 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.
>

I really don't think we want to fix the offset to a JD for all of VO.

> > This is not OK for general usage, and without the restriction you get a
> > cyclical problem in the model.
>
> The cyclicity (that you actually don't get rid of as is, you just
> hide it a bit better) is another indication of the unnecessary
> complexity inflation I'm hinting at above.
>

Where is the cycle? I think I've hidden it from myself!

> As soon as you attach time metadata to the time offset (which is
> itself metadata), you have meta-metadata.  There are situations when
> you *have* to have extra levels, but these kinds of cycles
> ("reification") always are potentical code bomb (i.e., apparently
> inoccuous features that explode into many code lines in
> implementations).  Let's not do it unless we must, and as I argue
> above, I'm sure we can do without meta-metadata here just fine.
>
>
> > > 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).
>

I get concerned about discussion based on 'xtype'.. as I understand it,
this is more or less an alternate annotation to identify that the
field/param is a time rather than basic string/real.
If I'm reading DALI (pg 17) correctly, this applies to all 'flavors'.. ISO,
MJD, JD.  Presumably, a client then interprets the value:
  if (string) => ISO
  else if (real)
     if (> 2,400,000.5) => JD
     else => MJD

(I don't see a means for the client to distinguish between JD and MJD other
than the range)
So the xtype="timestamp" maps more directly to the model "TimeInstant"
type.. which is fine.
Now, if the table also has VODML annotation, the field would be identified
as the particular sub-class (coords:domain.time.MJD), which removes the
need for interpreting the value.

Your argument seems to be that since VOTable already has an annotation
scheme for these time types (ISO,MJD,JD), that we shouldn't model them more
specifically because a provider may include
both annotations, and there is a possibility that they are inconsistent.  (
ie: votable xtype="timestamp" value="2000-01-02T15:20:30Z"  with vo-dml
dmtype="coords:domain.time.MJD" )

I agree this is a possibility.
I disagree that this is a model problem.  The model supports the xtype
usage, but has an additional level of detail showing exactly what
implementations of TimeInstant should support.

This argument holds true for both the TIMESYS and COOSYS elements as well.
If a provider includes those, and vo-dml annotation for the time frame and
space frame, they had better be consistent.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20190109/05d1c720/attachment.html>