Time Series markup up for testing

[Markus Demleitner]

Dear Ada,

On Fri, Aug 07, 2020 at 12:16:23PM +0200, ada nebot wrote:
> > On 5 Aug 2020, at 13:10, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> The filter identifier points to "SDSS r", but to uniquely identify the filter I would have chosen something like : 
> Facility/Subcategory.Band : VST/OmegaCAM.r_SDSS  
> 
> The effective wavelength I see under the ESO pages is not 6.12e-7 but 6.25e-7
> https://www.eso.org/sci/facilities/paranal/instruments/omegacam/inst.html <https://www.eso.org/sci/facilities/paranal/instruments/omegacam/inst.html>

Ah, ok.  Fixed this (I blindly copied the previous annotation which I
had blindly based on metadata the origin of which is lost in time).

But now that I think of it: Perhaps a "Do it in practice" appendix
that basically says: "For filter names and central wavelengths, do
yourself a favour and just check the SVO filter profile service"
might be another valuable appendix to the note?

> > http://dc.zah.uni-heidelberg.de/getproduct/gaia/q2/1000103304040175360/RP
> > http://dc.zah.uni-heidelberg.de/getproduct/gaia/q2/1000103304040175360/BP
> > http://dc.zah.uni-heidelberg.de/getproduct/gaia/q2/1000103304040175360/G
> > 
> 
> Repeated metadata (all in the example k2c9vst)… 
> Nothing important, but it seems redundant to see the same information twice. 
> I wonder if there is no other way of doing this to point to the two
> different columns in this type of data? 

I'd not worry about it -- it's a minute amount of bytes, but it helps
to keep the effort in producing and parsing the material low.  Also,
it will, in general, not be repetitive:

> FIELDref would solve that I guess but one is the mag the other the error? 

No, one is flux (in the k2c9vst example, a relative flux), the other
the magnitude; and it's just the metadata incompleteness that makes
things repetitive  here.  In the general case, for instance, the flux
GROUP wouldn't have a zero point -- it's just this particular case
where mag doesn't either.

Value and error would be in the measurements model (the VODML element
actually contains the annotation that I think we should have as a
baseline).  I still believe photometry as such doesn't need to know
about errors, and errors don't need to know that they happen to be on
photometry (although there *is* a point for annotating logarithmic
errors in general, one day).

> The units are missing for the effective wavelength. 

Oops, bug.  Fixed.

> > (1) Most importantly: Let's referse the referencing between the
> > photcal group and the field, meaning: Don't have
> > 
> >  <GROUP ID="p"/>
> >  <FIELD name="mag" ref="p"/>
> > 
> > but rather
> > 
> >  <GROUP ID="p">
> >    <FIELDref utype="adhoc:location" ref="mag"/>
> >  </GROUP>
> >  <FIELD ID="mag"/>
> > 
> 
> I thought about this for some time and I chose ref in the field
> instead of FIELDref.  I chose to use the same annotation as for
> TIMESYS and COOSYS with the hope of having the info defined in the
> same way as those two elements. Basically for consistency.  But as

Yeah -- we kept the wrong direction in TIMESYS because with thought
breaking with COOSYS' pattern would be too contentious and delay
TIMESYS.  I'm sure now is the time to break the pattern of
proliferating technical debt.

> > (a) annotation shouldn't change what's annotated
> 
> Agree on this point. But how does ref instead of FIELDref change
> what is annotated ?  In one case the reference goes from bottom to
> top in the other the other from top to bottom.  But both things do
> basically the same in a slightly different way. 

Well, with the COOSYS pattern you need to change the FIELD element
(its ref attribute).  With the new pattern, FIELD just stays as it
is; it doesn't need to know that it's referenced from an annotation at
all, and it can be referenced as often as necessary by as many groups
(or VODML elements) as necessary.


And while I'm talking: A constant source of woe at least in spectra
is that optical astronomers still like their air wavelengths.  Since
it's probably impossible to move the VO as a whole to frequency or,
even better, energy on the spectral axis (where this particular
problem would disappear), I'd like to see something on that topic
mentioned in the note.  Of course, I won't see the difference between
air and vacuum in my effective wavelenghts, but for narrowband
photometry the difference might very well matter.  

So... I think we want vacuum wavlengths here?  And the filter profile
service gives vacuum wavelenghts even where optical astronomers will
see them?

Thanks,

          Markus