Coordinates model - Working draft.

[Markus Demleitner]

Hi DM,

On Wed, Jan 09, 2019 at 11:15:11AM -0500, CresitelloDittmar, Mark wrote:
> I'd like to hear other opinions on this.. otherwise the discussion will
> remain rather circular.

Yes, folks, please speak up!  STC annotation is important for so many
use cases (including in all likelihood yours), and we really can't
afford a re-run of the, to put it friendly, lackluster takeup of
STC1.  Please have a look at things *now* and think about how your
data would be annotated with this model.  And then perhaps consider
if there's a simpler way to effect the same thing[1]. 


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

But what kind of scenario do you envision where annotators can't just
write a JD with zero or negligible effort?

> > 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!

Ok -- I stand corrected.  The split of TimeInstant and TimeStamp does
indeed prevent a cycle in the graph.  But that in itself is a
significant complication of the model, which seems a high price to
pay for being able to write a piece of metadata in several different
forms.

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

No.  Generally, an xtype says "Dear VOTable parser -- in case you
have special code, you can interpret this field in a special way; if
you don't, just treat it as the normal datatype/arraysize you're
seeing and nothing bad happens even if you round-trip and keep the
xtype".

In the concrete case, what DALI says is: "If you know the xtype
timestamp, then parse the string using a pattern like
YYYY-MM-DD['T'hh:mm:ss[.SSS]['Z']] and return a native timestamp
object to your caller."

> 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

No, this is *not* the intention, and if the DALI text leads people to
believe it is, it needs to be fixed.

> So the xtype="timestamp" maps more directly to the model "TimeInstant"
> type.. which is fine.

No.  It would be conflated with your ISOTime, just with a somewhat
more precise syntax definition.

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

Why would such a model even want to say what serialisations should be
available?  And if you think you should say something about
serialisations, then what about times given as years?  Or the
perennial favourite J2015.5?  Am I not going to be allowed to
annotate these with STC2 even if my serialisation supports it (which
VOTable so far by and large doesn't, but others may)?

Everything will be simpler if you just leave serialisation alone.
VOTable has a well-established way to define how literals are
serialised and what their unit is, and presumably essentially all
other relevant formats have very similar capabilities.  It would be
highly unwise (not to mention restricting) to repeat these
definitions in the data model; it yields no additional information
but multiplies the ways in which inconsistencies can be introduced.

So, again, let's only add annotation that VOTable and comparable
formats don't have (well, yes, there's COOSYS, and there'll hopefully
be TIMESYS soon, but they'll hopefully die when there's widespread
adoption of STC2+VOTable).  

Specifically, that extra metadata in the time domain is what you now
have in TimeFrame plus the time offset (e.g., JD, MJD, or one of a
myriad others).  If you just absorb that time offset into your
TimeFrame, there's no need for extra time modelling at all.  Which
will increase the chances for the adoption of the model.  Which is a
good thing.

          -- Markus


[1] Because simplicity helps adoption by Demleitner's conjecture:
Each box in your UML diagram reduces the likelihood of the adoption
of the model by 1%.