<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 <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> 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>
> Meas-1.0 <<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>> (<br>
> 13/Apr/2020 )<br>
> * Updated to RFC comments<br>
> * Topics:<br>
> o I don't believe there are open topics here..<br>
<br>
Hm.... :-)<br>
<br>
So, from my RFC comments: I still don't understand why you have<br>
different types for Generic, Time, etc. Am I missing the rationale?<br>
For what we're doing in Meas (essentially, associating values and<br>
errors), how is just GenericMeasure not enough?<br></blockquote><div><br></div><div>I don't think you are missing the rationale, just that you don'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> "This TABLE has COLUMNS"</div><div> * with the property-based Measures, you are describing Entities</div><div> "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 'threads' often used in the wish-list for these models is to 'easily identify and plot the positions in a file, with appropriate/normalized Frame specs'.</div><div> o With Position objects using Coords, this is trivial.</div><div> o With GenericMeasure you'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'd be even harder (don'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'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'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'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 "half-Gaussians" will be discontinuous at the center<br>
if their widths are diffrent. That's not a disaster for a<br>
distribution, but it is still a bit funky.<br>
<br>
But really, I don't think we should try to be that precise at all.<br>
If we don'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'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 "action" 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'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'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'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>