Time Series markup up for testing

[Markus Demleitner]

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

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

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"/>

(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
(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.

(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.

(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).

       -- Markus