MCT - model document delivery.

[CresitelloDittmar, Mark]

On Mon, Sep 7, 2020 at 10:54 AM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi Mark,
>
> On Fri, Sep 04, 2020 at 10:52:27AM -0400, CresitelloDittmar, Mark wrote:
> > Meas-1.0 <http://www.ivoa.net/documents/Meas/20200413/index.html> (
> > 13/Apr/2020 )
> >   * Updated to RFC comments
> >   * Topics:
> >      o I don't believe there are open topics here..
>
> Hm.... :-)
>
> So, from my RFC comments: I still don't understand why you have
> different types for Generic, Time, etc.  Am I missing the rationale?
> For what we're doing in Meas (essentially, associating values and
> errors), how is just GenericMeasure not enough?
>

I don't think you are missing the rationale, just that you don't agree with
it.
The difference is basically:
  * with just GenericMeasure your data product will only be making the
statement
      "This TABLE has COLUMNS"
  * with the property-based Measures, you are describing Entities
      "This Cube has Position, Time, etc...

The current Measurement model has only the basic properties, with a generic
form to catch the rest.
The MANGO (Source Model) is looking to extend that to other properties.

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'.
  o With Position objects using Coords, this is trivial.
  o With GenericMeasure you'd have to interrogate each instance, you could
check for associated SpaceFrame to determine that it is spatial.
  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.

Even more importantly, I'm still rather strictly against using
> anything from coords in meas.  Having a value and an error is a lot
> more fundamental than having coordinates (which more or less imply a
> vector space if the word is to mean anything).  What we do now, on
> the other hand, links meas to coords without any profit I can discern.
>

The entire point of this work is to define a set of models which build on
each other to
form complex models.  The Coords model elements allow you to specify your
vector
space as needed.


> Then, while it's some progress to state
>
>   The current model assumes Gaussian distributions with shpes defined
>   at the 68% confidence level,
>
> that claims *a lot* more than you usually can, and thus I couldn't
> usually use this to annotate my value-error pairs; and it would
> probably require a bit of explanation with the asymmetrical error
> models, as the "half-Gaussians" will be discontinuous at the center
> if their widths are diffrent.  That's not a disaster for a
> distribution, but it is still a bit funky.
>
> But really, I don't think we should try to be that precise at all.
> If we don't speak about distributions a lot more, we should confess
> up and simply derive
>
> NaiveError
>
> from the (abstract) Uncertainty.  It would say something like
>
>   This error does not really specify anything about the underlying
>   distributions or confidence levels.  Essentially, it is intended to
>   support plotting of error bars with mild semantics.  For further
>   analysis, human interpretation or additional metadata (probably
>   from later versions of this model) is required.
>
> And I still think all the effort on the various multi-D errors should
> not be made at this point.  They're all special cases of correlated
> errors, and if we tackle correlations at this point at all, they
> should talk about individual errors.
>

What is in the current version reflects the overall RFC comments and
the "action" list that was distributed as a response to that.



> Hence, I'd still say the model should just have:
>
> Measurement:
>   value: float
>   error: Uncertainty
>
> Uncertainty (abstract class)
>
> NaiveError:
>   value
>
> and perhaps
>
> Correlation:
>   coefficient: float
>   err1, err2: Uncertainty
>
>
> As said in my original RFC comment, in contrast to the current model,
> that would allow a meaningful annotation of the Gaia result catalogue
> (and, I claim, many, many others).  Which is something I'd dearly
> like to do.
>
> And that step will also break the dependency of Meas on Coords.  Less
> entangled standards are always a big win, as they allow for
> independent development.  Which, given that we pretty certainly will
> want errors with more precise machine-readable semantics
> (distributions, their parameters, confidence levels...) once we can
> do the naive, simple things, is particularly important for Meas.
>

I can't disagree more.
IMO, the usefulness of Coords, is in the context of other objects (Meas).
What you suggest above is overly simplistic, and does not satisfy the
requirements of the Cube model (and probably the source model, but that is
TBD).

But.. if you really feel that model is what the community is looking for, I
encourage you to formalize it, apply it to the current projects, and submit
it for consideration.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200908/c5cba547/attachment.html>