Measurements model

[Markus Demleitner]

Dear DM,

On Fri, Sep 13, 2019 at 03:50:26PM +0200, Laurent Michel wrote:
> This is especially true for Meas and Coords; you cannot read one
> while ignoring the other.  This is why the 2 RFC periods have been
> both opened today for 6 weeks (21/10).
> 
> - Meas   https://wiki.ivoa.net/twiki/bin/view/IVOA/MeasRFC

I've had a first read of Measurements (not really Coords, yet), and
since I probably won't find time to do some actual annotation to data
I hold until early November, I've posted some first comments on the
RFC page already.  A few of these points I'd like to bring to the
mailing list, since I feel there should be some community discussion
about them, so here's the first installment.

First, I am very much in favour of extending the RFC for this until
we have the annotation syntax defined, at least at the level of a PR.

True, for DMs the question of what "implemenation" means is always a
bit tricky. In this particular case, however, it is very clear that
most people will only properly look at things if they know what they
will be doing with it. That is particularly true for client authors.
I'd go as far as to say: I consider the DM implementation-proven if
there's astropy-affiliated code consuming at least 60% of the model.

Having said that, there are also some more special points on the
model, the most important of which is: I don't think there is a
reason to have the subtypes of GenericMeasurement (except perhaps to
tell discrete variables from continuous ones).  The pertinent
comments from my RFC response are:

(4) I don't think I quite understand what requirement makes you
introduce "Time" over "Generic Measure" -- as far as errors are
concerned, is there anything special about time? Why would I use it
rather than Generic Measure, which, as far as I can tell, works just
as well? If it's just about the value representation, I'd much prefer
if it were left to the serialisation format (like VOTable) -- it's
always evil if the same information is represented in two different
ways. Similar considerations apply to position, velocity, and
polarization (see below, though).

(5) I'm totally against having different classes for coordinates in
different frames. It makes the model a lot larger without helping
anything over the simple provision of a frame. And you'll have to say
what should happen if you annotate a GalacticPosition with an
equatorial frame. I may be swayed to accept that error modelling is a
bit different in curvilinear coordindates (spherical, cylindrical,
whatever) versus plain cartesian. But then the classes should be,
perhaps, CurvilinearCoordinate versus CartesianCoordinate.

(7) Polarization -- again, I'd much rather not talk about concrete
physics in Meas. If you really have to enumerate all the different
things people can measure, that should be done somewhere else (and
probably reuse resources like the UAT). Having some special treatment
for Measurements over discrete domains sounds like a reasonable thing
to want, though. For that, though, I'd say the diagram in sect. 9 is
rather confusing. I read it as "Polarization inherits from Measure
(which has 1:n to Error), and we somehow say n=0 here". To me, it'd
feel a lot more natural if discrete observables inherited from
something that doesn't have (numerical) errors in the first place.
Also, of course, discrete distributions might make sound error
models, too, so just saying "discrete values have no errors" is
probably too limiting for a number of interesting use cases.

So -- perhaps I'm missing something big time, but if so, you'd need
to hit me with a rather solid clue stick.  

On the other hand, if I'm not missing anything, I'd say the model
should just consist of

* Measure.value and Measure.error
* Error.statError (and perhaps ranError, but there's another comment
  on this on the RFC page)
* Error.sysError
* and some way to model correlated errors (there's yet another
  comment on that).

I even have ideas for what to do with the space freed up by that move
:-)

Sorry for the longish mail,

          Markus