<div dir="ltr"><div dir="ltr"><div>Markus,<br><br></div><div>Thanks for looking it over so quickly.. comment early and often!<br></div><div>Some comments in-line.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 20, 2019 at 9:10 AM Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear DM,<br>
<br>
On Fri, Sep 13, 2019 at 03:50:26PM +0200, Laurent Michel wrote:<br>
> This is especially true for Meas and Coords; you cannot read one<br>
> while ignoring the other. This is why the 2 RFC periods have been<br>
> both opened today for 6 weeks (21/10).<br>
> <br>
> - Meas <a href="https://wiki.ivoa.net/twiki/bin/view/IVOA/MeasRFC" rel="noreferrer" target="_blank">https://wiki.ivoa.net/twiki/bin/view/IVOA/MeasRFC</a><br>
<br>
I've had a first read of Measurements (not really Coords, yet), and<br>
since I probably won't find time to do some actual annotation to data<br>
I hold until early November, I've posted some first comments on the<br>
RFC page already. A few of these points I'd like to bring to the<br>
mailing list, since I feel there should be some community discussion<br>
about them, so here's the first installment.<br>
<br>
First, I am very much in favour of extending the RFC for this until<br>
we have the annotation syntax defined, at least at the level of a PR.<br>
<br>
True, for DMs the question of what "implemenation" means is always a<br>
bit tricky. In this particular case, however, it is very clear that<br>
most people will only properly look at things if they know what they<br>
will be doing with it. That is particularly true for client authors.<br>
I'd go as far as to say: I consider the DM implementation-proven if<br>
there's astropy-affiliated code consuming at least 60% of the model.<br></blockquote><div><br></div><div>I'll leave that up to the TCG/Chairs... I've shown the model is serializable in:<br></div><div> o VOTable - straight<br></div><div> o VOTable - annotated with the Mapping syntax<br></div><div> o XML <br></div><div>All validating against their schema.<br></div><div>It's also been shown that Astropy can invoke instances from a normal VOTable even with simplistic annotation (ucd, utype, name).. so can be only easier with any formalized syntax.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Having said that, there are also some more special points on the<br>
model, the most important of which is: I don't think there is a<br>
reason to have the subtypes of GenericMeasurement (except perhaps to<br>
tell discrete variables from continuous ones). The pertinent<br>
comments from my RFC response are:<br>
<br>
(4) I don't think I quite understand what requirement makes you<br>
introduce "Time" over "Generic Measure" -- as far as errors are<br>
concerned, is there anything special about time? Why would I use it<br>
rather than Generic Measure, which, as far as I can tell, works just<br>
as well? If it's just about the value representation, I'd much prefer<br>
if it were left to the serialisation format (like VOTable) -- it's<br>
always evil if the same information is represented in two different<br>
ways. Similar considerations apply to position, velocity, and<br>
polarization (see below, though).<br>
<br></blockquote><div>Primarily, there are times where you want to specify the type..<br></div><div> + Target.position MUST be a Position, a GenericMeasure does not satisfy this unless you add in the text that the coordinate MUST refer to a SpaceFrame, which is an extra step a validator and client must manually check.<br></div><div> + TimeSeries MUST have a 'column' of Time data. same detail as above.<br></div><div> + If you look at a serialization with just GenericMeasures, its really hard to know what it is, since you have to interrogate the Frame, which is somewhat separated (by reference). Having Position, and then the further specialized types (eg: EquatorialPosition with ra,dec ) make it very clear what you have.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(5) I'm totally against having different classes for coordinates in<br>
different frames. It makes the model a lot larger without helping<br>
anything over the simple provision of a frame. And you'll have to say<br>
what should happen if you annotate a GalacticPosition with an<br>
equatorial frame. I may be swayed to accept that error modelling is a<br>
bit different in curvilinear coordindates (spherical, cylindrical,<br>
whatever) versus plain cartesian. But then the classes should be,<br>
perhaps, CurvilinearCoordinate versus CartesianCoordinate.<br></blockquote><div><br></div><div>Well, the spec says the frame MUST specify a galactic reference frame, so a decent validator would flag it as invalid. The alternative is to have a GenericMeasure with a SpaceFrame.refFrame=ICRS and NO way to know that the 2 coordinate values, in deg, are actually galactic(l,b).<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
(7) Polarization -- again, I'd much rather not talk about concrete<br>
physics in Meas. If you really have to enumerate all the different<br>
things people can measure, that should be done somewhere else (and<br>
probably reuse resources like the UAT). Having some special treatment<br>
for Measurements over discrete domains sounds like a reasonable thing<br>
to want, though. For that, though, I'd say the diagram in sect. 9 is<br>
rather confusing. I read it as "Polarization inherits from Measure<br>
(which has 1:n to Error), and we somehow say n=0 here". To me, it'd<br>
feel a lot more natural if discrete observables inherited from<br>
something that doesn't have (numerical) errors in the first place.<br>
Also, of course, discrete distributions might make sound error<br>
models, too, so just saying "discrete values have no errors" is<br>
probably too limiting for a number of interesting use cases.<br></blockquote><div><br></div><div>Including discrete types like Polarization states as an extension of Measure was a conscious choice, which is pretty well justified, and allows that sort of data to be included in a Cube very easily.<br><br></div><div>We have polarization data, it needs to be included in a Cube, so the alternative would be to have a Parent to Measure with no Error, which can then also be extended to an "AssignedState" type for thinks like Polarization and other discrete types. This parent would then be used by Cube.<br></div><div><br></div><div>With Polarization specifically:<br></div><div> + Measure has 0..* Error-s, Polarization constrains this to [0]<br></div><div> + In working Polarization, we focused on the enumerated polarization states.<br></div><div> At the time, I did some looking about numerical polarization types, but they weren't in STC, nor being flagged as interesting, so didn't include them.<br></div><div> However, looking at CAOM2 yesterday, I see that it includes the following in addition to the typical enumeration set:<br></div><div> POLI - linear polarized intensity: sqrt(Q^2 + U^2)<br> FPOLI - fractional linear polarization: POLI/I<br> POLA - linear polarization angle: 1/2 arctan(U,Q)<br> EPOLI - elliptical polarization intensity: sqrt(Q^2 + U^2 + V^2)<br> CPOLI - circular polarization intensity: |V|<br> NPOLI - unpolarized intensity: I - EPOLI<br><br></div><div> I don't know anything about these, but the descriptions read very numeric, and presumably would have error. Migrating from where we are to include<br></div><div> those would be a small change to branch Polarization to a numeric type and a State type. And I'd much prefer to keep them under the same umbrella. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So -- perhaps I'm missing something big time, but if so, you'd need<br>
to hit me with a rather solid clue stick. <br>
<br>
On the other hand, if I'm not missing anything, I'd say the model<br>
should just consist of<br>
<br>
* Measure.value and Measure.error<br>
* Error.statError (and perhaps ranError, but there's another comment<br>
on this on the RFC page)<br>
* Error.sysError<br>
* and some way to model correlated errors (there's yet another<br>
comment on that).<br>
<br></blockquote><div><br></div>The goal here is to make a model which allows any 'Measure' to be described, but provides specializations to easily identify and use the most common types found in our data. Thus the Position, Time, etc. The discussions in recent interops regarding Source properties and such support this approach. I distinctly recall that it is a 'disgrace' that we cannot represent a ProperMotion with current models. The expectation going forward is that a SourceProperties model (or other models) would define new extensions of Measure as needed.<br></div><div class="gmail_quote">These would, automatically, be usable within a Cube.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">I'll take a look at the other comments on the twiki.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Mark<br><br></div></div></div>