Time Series markup up for testing

[ada nebot]

Hi Markus, 

Thanks a lot for comments and sending those examples around. 
I had a quick look to you examples and spotted few things. 

> On 5 Aug 2020, at 13:10, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Dear TDIG,
> 
> I've just taught DaCHS to produce what I hope is close to what Ada
> had in mind in
> 
> http://ivoa.net/documents/Notes/LightCurveTimeSeries/
> 
> It would now be nice if people could have a look at it with a view to
> where I've not been paying attention, and also if this proposal would
> work for them.
> 
> There are currently three SSAP services pushing out such time series
> files (the access URLs would work in SPLAT or TOPCAT's SSAP client):
> 
> * k2c9vst -- that's differential photometry with largely
>  untrustworthy conversion to uncalibrated mags: 
>  http://dc.zah.uni-heidelberg.de/k2c9vst/q/ssa/ssap.xml?
>  Look in Baade's window.
> * BGDS light curves -- that's your run-of-the-mill ground-based
>  photometry where at least I don't have even the beginnings of a
>  flux calibration:
>  http://dc.zah.uni-heidelberg.de/bgds/l/ssa/ssap.xml?
>  Data is available in the southern Milky Way plane.
> * Gaia DR2 light curves -- no comment necessary, except I'm using the
>  calibration from SVO's filter profile service (or think I do):
>  http://dc.zah.uni-heidelberg.de/gaia/q2/ssa/ssap.xml?
> 
> In case you'd like to jump to sample files directly: 
> 
> k2c9vst: http://dc.zah.uni-heidelberg.de/getproduct/k2c9vst/data/OGLE-2016-BLG-0968_VST_r_SDSS68.t
> 

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>


> BGDS in SDSS i: http://dc.zah.uni-heidelberg.de/bgds/l/tsdl/dlget?ID=BGDS-1825-1423-i-277.1723680-14.3354807
> BGDS in SDSS r: http://dc.zah.uni-heidelberg.de/bgds/l/tsdl/dlget?ID=BGDS-0744-2158-r-115.2631363-22.6573959
> 

> Gaia DR2, in the three Gaia bands: 
> 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? 
FIELDref would solve that I guess but one is the mag the other the error? 
The units are missing for the effective wavelength. 

> The files also contain Jiri-type VODML-inspired annotation.  Ignore
> it for this purpose (which is easy: just blank out the VODML
> element).  Or let me know if you'd team up with me to develop that
> further.
> 
> As I said: Any and all feedback is welcome -- and I apologise in
> advance that I couldn't put more time into this, which means it'll be
> easy to spot dumb mistakes.
> 
> Meanwhile, three points on the spec itself:
> 
> (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 you also know, I gave up  on the idea of a FILTERSYS. So I guess, without thinking 
much about it, it makes no more sense now to have the discussion on FIELDref or not, 
so unless someone else has a strong opinion on the topic I’d be ok with the modification. 
Before making any modifications to the text, I’ll give some time so people can react. 

> (the sample files currently do both).  I've regretted quite often
> already to not have insisted on doing this right in TIMESYS, and I'm
> not sure whether I have to make the points why FIELD/@ref has been
> the wrong choice even for COOSYS again; still, just two key points:
> 
> (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. 

> (b) the ref scheme fails miserably as soon as there's a second
> annotation on the FIELD; in this case, this could expectably
> measurement, i.e., linking value and error, but it could also be a
> second version of photometry annotation.

True that for linking a value and its error we can use the GROUP and combine with FIELDref. 
And that usage is quite common by now… 

> (2) We need to make clear which of the items (if any) in photcal are
> mandatory and which can be left out.  I'm rather sure that for the
> clients' sake we should make the band name mandatory.  I *think*
> having at least an estimate of the effective wavelength would help
> all around, although there's a certain risk people will make things
> up out of thin air (e.g., time series derived from plate scans where
> all you have is an emulsion name).  Anything else I don't think we
> can really demand.

Yes, this is a good point. Sometimes we have uncalibrated magnitudes, 
and we should be able to annotated them. So some flexibility should be given 
there. 

> (3) Continuing this, I think it would be good to have a section that
> comments on what to do in a few typical situations, like:
> 
> (a) Ground-based photometry of the shoot-sextractor-calibrate-on-some-
> selected-catalogue type (e.g.: can I copy the zero point from SVO in
> these cases?  I've not done this in BGDS: should I?).
> 
> (b) Gaia (which has linear fluxes but has them in e-/s).  Btw., Gaia
> also gives zero points, but these are false friends in this context.
> Since we'll see a lot more of Gaia in the next couple of years, I'd
> say it's reasonable to special-case that even in the Note.
> 
> (c) Properly calibrated data in optical (i.e., F_lambda) and radio
> (i.e., F_nu).
> 
> (d) Data that gives some sort of relative flux (as in differential
> photometry or perhaps in x-ray, in case someone is confronted with
> fluxes coming in mCrabs -- no idea if they still do that).
> 
> (e) Photometrically ill-defined data (my plate scan example above
> might serve as an inspiration).
> 

I think this are all valid examples and yes, we can add those cases in the doc. 

Cheers,
Ada

>       -- Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/voevent/attachments/20200807/54caea67/attachment.html>