Coordinates model - Working draft.

[Laurent MICHEL]

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>> 
> 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
      67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
---