Coordinates model - Working draft.

[Tom Donaldson]

Hello All,

I agree with this sentiment.  Inferences add to client complexity, and therefor to the likelihood of mistakes.

On another angle, I want to ask about these models with respect to Astropy.  Forgive me if this has been covered, but has anyone assessed how straightforward it will be to create instances of Astropy time and coordinates (and other?) objects given instances of these models?  In my basic reading of the WD, I see a lot of parallels, but my domain knowledge is too weak to do a real analysis.

Cheers,
Tom




From: <dm-bounces at ivoa.net> on behalf of Laurent MICHEL <laurent.michel at astro.unistra.fr>
Date: Tuesday, January 15, 2019 at 4:52 AM
To: "dm at ivoa.net" <dm at ivoa.net>
Subject: Re: Coordinates model - Working draft.

Hello,

I believe that the scope of models must not be limited just because
there is a risk of de-synchronization between model stuff and data. This
risk is present in any case and it a part of the data provider
responsibility. A simple side effect in a loop building VOTable fields
can make a RA column tagged as magnitude. This never occurs just because
services are well validated. There no reason to assume that things will
get worse when dealing with models.
A model cannot tell to the client "this quantity is a STC:TimeStamp and
do your best to get more information. I'm sorry I cannot tell more
because I'm afraid to contradict my host".

In my opinion, a model must be self-consistent. It must be enable to
describe data without referring to any <FIELD> attribute and even
without referring to any specific file format (FITS, VOTABLE..).
The best modeling process (including annotation) is the one that allows
clients to retrieve model instances without running inferences on
ucd/datatype/xtype.


Laurent

Le 09/01/2019 à 17:15, CresitelloDittmar, Mark a écrit :
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<mailto:msdemlei at ari.uni-heidelberg.de> <mailto:msdemlei at ari.uni-heidelberg.de><mailto:msdemlei at ari.uni-heidelberg.de%3e>>
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

--
---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
      Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
      11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr<mailto:laurent.michel at astro.unistra.fr>
      67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
---

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20190115/b2082642/attachment-0001.html>