<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 7, 2020 at 10:54 AM Markus Demleitner &lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Mark,<br>
<br>
On Fri, Sep 04, 2020 at 10:52:27AM -0400, CresitelloDittmar, Mark wrote:<br>
&gt; Meas-1.0 &lt;<a href="http://www.ivoa.net/documents/Meas/20200413/index.html" rel="noreferrer" target="_blank">http://www.ivoa.net/documents/Meas/20200413/index.html</a>&gt; (<br>
&gt; 13/Apr/2020 )<br>
&gt;   * Updated to RFC comments<br>
&gt;   * Topics:<br>
&gt;      o I don&#39;t believe there are open topics here..<br>
<br>
Hm.... :-)<br>
<br>
So, from my RFC comments: I still don&#39;t understand why you have<br>
different types for Generic, Time, etc.  Am I missing the rationale?<br>
For what we&#39;re doing in Meas (essentially, associating values and<br>
errors), how is just GenericMeasure not enough?<br></blockquote><div><br></div><div>I don&#39;t think you are missing the rationale, just that you don&#39;t agree with it.</div><div>The difference is basically:</div><div>  * with just GenericMeasure your data product will only be making the statement</div><div>      &quot;This TABLE has COLUMNS&quot;</div><div>  * with the property-based Measures, you are describing Entities</div><div>      &quot;This Cube has Position, Time, etc...</div><div><br></div><div>The current Measurement model has only the basic properties, with a generic form to catch the rest.</div><div>The MANGO (Source Model) is looking to extend that to other properties.</div><div><br></div><div>One of the &#39;threads&#39; often used in the wish-list for these models is to &#39;easily identify and plot the positions in a file, with appropriate/normalized Frame specs&#39;.</div><div>  o With Position objects using Coords, this is trivial.</div><div>  o With GenericMeasure you&#39;d have to interrogate each instance, you could check for associated SpaceFrame to determine that it is spatial.</div><div>  o With your proposal (below) it&#39;d be even harder (don&#39;t see Frame info).. so there is only the units(?) to make that determination.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Even more importantly, I&#39;m still rather strictly against using<br>
anything from coords in meas.  Having a value and an error is a lot<br>
more fundamental than having coordinates (which more or less imply a<br>
vector space if the word is to mean anything).  What we do now, on<br>
the other hand, links meas to coords without any profit I can discern.<br></blockquote><div><br></div><div>The entire point of this work is to define a set of models which build on each other to</div><div>form complex models.  The Coords model elements allow you to specify your vector </div><div>space as needed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Then, while it&#39;s some progress to state<br>
<br>
  The current model assumes Gaussian distributions with shpes defined<br>
  at the 68% confidence level,<br>
<br>
that claims *a lot* more than you usually can, and thus I couldn&#39;t<br>
usually use this to annotate my value-error pairs; and it would<br>
probably require a bit of explanation with the asymmetrical error<br>
models, as the &quot;half-Gaussians&quot; will be discontinuous at the center<br>
if their widths are diffrent.  That&#39;s not a disaster for a<br>
distribution, but it is still a bit funky.<br>
<br>
But really, I don&#39;t think we should try to be that precise at all.<br>
If we don&#39;t speak about distributions a lot more, we should confess<br>
up and simply derive<br>
<br>
NaiveError<br>
<br>
from the (abstract) Uncertainty.  It would say something like<br>
<br>
  This error does not really specify anything about the underlying<br>
  distributions or confidence levels.  Essentially, it is intended to<br>
  support plotting of error bars with mild semantics.  For further<br>
  analysis, human interpretation or additional metadata (probably<br>
  from later versions of this model) is required.<br>
<br>
And I still think all the effort on the various multi-D errors should<br>
not be made at this point.  They&#39;re all special cases of correlated<br>
errors, and if we tackle correlations at this point at all, they<br>
should talk about individual errors.<br></blockquote><div><br></div><div>What is in the current version reflects the overall RFC comments and </div><div>the &quot;action&quot; list that was distributed as a response to that.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Hence, I&#39;d still say the model should just have:<br>
<br>
Measurement:<br>
  value: float<br>
  error: Uncertainty<br>
<br>
Uncertainty (abstract class)<br>
<br>
NaiveError:<br>
  value<br>
<br>
and perhaps<br>
<br>
Correlation:<br>
  coefficient: float<br>
  err1, err2: Uncertainty<br>
<br>
<br>
As said in my original RFC comment, in contrast to the current model,<br>
that would allow a meaningful annotation of the Gaia result catalogue<br>
(and, I claim, many, many others).  Which is something I&#39;d dearly<br>
like to do.<br>
<br>
And that step will also break the dependency of Meas on Coords.  Less<br>
entangled standards are always a big win, as they allow for<br>
independent development.  Which, given that we pretty certainly will<br>
want errors with more precise machine-readable semantics<br>
(distributions, their parameters, confidence levels...) once we can<br>
do the naive, simple things, is particularly important for Meas.<br></blockquote><div><br></div><div>I can&#39;t disagree more.</div><div>IMO, the usefulness of Coords, is in the context of other objects (Meas).</div><div>What you suggest above is overly simplistic, and does not satisfy the</div><div>requirements of the Cube model (and probably the source model, but that is TBD).</div><div><br></div><div>But.. if you really feel that model is what the community is looking for, I </div><div>encourage you to formalize it, apply it to the current projects, and submit it for consideration.</div><div><br></div><div>Mark</div><div><br></div></div></div>