Time Series markup up for testing

[ada nebot]

Markus, 

Good point on the air / vacuum wavelengths. Yes, we want vacuum and this needs to be specified.  

Cheers,
Ada


> On 7 Aug 2020, at 13:11, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> 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