<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt">Hello All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I agree with this sentiment. Inferences add to client complexity, and therefor to the likelihood of mistakes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Tom<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black"><dm-bounces@ivoa.net> on behalf of Laurent MICHEL <laurent.michel@astro.unistra.fr><br>
<b>Date: </b>Tuesday, January 15, 2019 at 4:52 AM<br>
<b>To: </b>"dm@ivoa.net" <dm@ivoa.net><br>
<b>Subject: </b>Re: Coordinates model - Working draft.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Hello,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I believe that the scope of models must not be limited just because
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">there is a risk of de-synchronization between model stuff and data. This
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">risk is present in any case and it a part of the data provider
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">responsibility. A simple side effect in a loop building VOTable fields
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">can make a RA column tagged as magnitude. This never occurs just because
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">services are well validated. There no reason to assume that things will
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">get worse when dealing with models.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">A model cannot tell to the client "this quantity is a STC:TimeStamp and
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">do your best to get more information. I'm sorry I cannot tell more
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">because I'm afraid to contradict my host".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">In my opinion, a model must be self-consistent. It must be enable to
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">describe data without referring to any <FIELD> attribute and even
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">without referring to any specific file format (FITS, VOTABLE..).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">The best modeling process (including annotation) is the one that allows
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">clients to retrieve model instances without running inferences on
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">ucd/datatype/xtype.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Laurent<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Le 09/01/2019 à 17:15, CresitelloDittmar, Mark a écrit :<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<p class="MsoNormal" style="margin-left:.5in">I'd like to hear other opinions on this.. otherwise the discussion will
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">remain rather circular.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">more in-line<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Tue, Jan 8, 2019 at 7:44 AM Markus Demleitner
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a> <<a href="mailto:msdemlei@ari.uni-heidelberg.de%3e">mailto:msdemlei@ari.uni-heidelberg.de></a>>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">wrote:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Dear DM,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> On Fri, Dec 21, 2018 at 04:41:09PM -0500, CresitelloDittmar, Mark wrote:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > > Similarly (and this is quite a bit more itchy to me right now), I'm<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > > strongly advocating to make TimeInstant concrete and remove all its<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > > derived types (ISOTime, JD, MJD, TimeOffset). Instead, TimeFrame<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > > should grow a timeorigin attribute.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > ><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> ><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > Full disclosure, I haven't read the apps thread re: TIMESYS, but as I<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > recall, it works only because it requires that timeorigin is<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> expressed in<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > JD specifically.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Which is fine because it's metadata. In annotation, flexibility is<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> what we need on the *data* side -- in general you don't want to force<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> data providers into rigid conventions because that would typically<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> force them to change their data in non-trivial ways. That's why we<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> allow all kinds of time scales, reference positions, and (indirectly)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> serialisation formats.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> For *metadata*, that's a different thing -- this is part of the<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> annotation itself and is largely controlled by "us"; it is being<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> written at publication time by people looking at the VO. Flexibility<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> there only complicates both model and implementations without buying<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> anything (except possibly a tiny bit of conversion work for very few<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> numbers external to the data itself).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Hence, fixing time origin to a float (which certainly can be<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> represented in all conceivable serialisations) with a bespoke<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> interpretation (as a JD) doesn't hurt the generality of the model at<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> all but saves quite a bit of code (and hence bugs) in the clients.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I really don't think we want to fix the offset to a JD for all of VO.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > This is not OK for general usage, and without the restriction you<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> get a<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > cyclical problem in the model.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> The cyclicity (that you actually don't get rid of as is, you just<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> hide it a bit better) is another indication of the unnecessary<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> complexity inflation I'm hinting at above.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Where is the cycle? I think I've hidden it from myself!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> As soon as you attach time metadata to the time offset (which is<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> itself metadata), you have meta-metadata. There are situations when<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> you *have* to have extra levels, but these kinds of cycles<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> ("reification") always are potentical code bomb (i.e., apparently<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> inoccuous features that explode into many code lines in<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> implementations). Let's not do it unless we must, and as I argue<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> above, I'm sure we can do without meta-metadata here just fine.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > > The rationale here is that the concrete form of the timestamp is a<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > > *serialisation* issue, i.e., one of VOTable, FITS, or whatever<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> else.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > > If the serialisation provides for having ISO-like dates or a binary<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > > representation of civil dates or nothing of the sort shouldn't<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > > determine whether you can serialise STC instances into them.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > ><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> ><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > Not sure I would call it a serialization issue, but yes.. its<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> related. The<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > thing is, when we have time data, we need to convey how to<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> interpret that<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> > value (which on its face is just a 'real' ).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Well, the trouble is that at least VOTable already has a distinction<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> between ISO string and floating point representations, and I'd expect<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> any format powerful enough to carray VODML annotation will have<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> similar mechanisms (e.g., relational database tables). So, if you<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> put that distinction into the model, too, you have an immediate<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> conflict of responsibilities.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Which is bad for many reasons, the most urgent of which is that<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> client writers have to decide what should happen if a <FIELD<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> xtype="timestamp"/> is annotated as MJDDate (say).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I get concerned about discussion based on 'xtype'.. as I understand it,
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">this is more or less an alternate annotation to identify that the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">field/param is a time rather than basic string/real.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">If I'm reading DALI (pg 17) correctly, this applies to all 'flavors'..
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">ISO, MJD, JD. Presumably, a client then interprets the value:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> if (string) => ISO<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> else if (real)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> if (> 2,400,000.5) => JD<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> else => MJD<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">(I don't see a means for the client to distinguish between JD and MJD
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">other than the range)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">So the xtype="timestamp" maps more directly to the model "TimeInstant"
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">type.. which is fine.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Now, if the table also has VODML annotation, the field would be
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">identified as the particular sub-class (coords:domain.time.MJD), which
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">removes the need for interpreting the value.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Your argument seems to be that since VOTable already has an annotation
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">scheme for these time types (ISO,MJD,JD), that we shouldn't model them
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">more specifically because a provider may include<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">both annotations, and there is a possibility that they are
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">inconsistent. ( ie: votable xtype="timestamp"
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">value="2000-01-02T15:20:30Z" with vo-dml dmtype="coords:domain.time.MJD" )<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I agree this is a possibility.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I disagree that this is a model problem. The model supports the xtype
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">usage, but has an additional level of detail showing exactly what
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">implementations of TimeInstant should support.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">This argument holds true for both the TIMESYS and COOSYS elements as well.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">If a provider includes those, and vo-dml annotation for the time frame
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">and space frame, they had better be consistent.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Mark<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">-- <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">---- Laurent MICHEL Tel (33 0) 3 68 85 24 37<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Observatoire de Strasbourg Fax (33 0) 3 68 85 24 32<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> 11 Rue de l'Universite Mail
<a href="mailto:laurent.michel@astro.unistra.fr">laurent.michel@astro.unistra.fr</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> 67000 Strasbourg (France) Web <a href="http://astro.u-strasbg.fr/~michel">http://astro.u-strasbg.fr/~michel</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">---<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
</div>
</body>
</html>