<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Markus, <div class=""><br class=""></div><div class="">Thanks a lot for comments and sending those examples around. </div><div class="">I had a quick look to you examples and spotted few things. </div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 5 Aug 2020, at 13:10, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Dear TDIG,<br class=""><br class="">I've just taught DaCHS to produce what I hope is close to what Ada<br class="">had in mind in<br class=""><br class=""><a href="http://ivoa.net/documents/Notes/LightCurveTimeSeries/" class="">http://ivoa.net/documents/Notes/LightCurveTimeSeries/</a><br class=""><br class="">It would now be nice if people could have a look at it with a view to<br class="">where I've not been paying attention, and also if this proposal would<br class="">work for them.<br class=""><br class="">There are currently three SSAP services pushing out such time series<br class="">files (the access URLs would work in SPLAT or TOPCAT's SSAP client):<br class=""><br class="">* k2c9vst -- that's differential photometry with largely<br class=""> untrustworthy conversion to uncalibrated mags: <br class=""> http://dc.zah.uni-heidelberg.de/k2c9vst/q/ssa/ssap.xml?<br class=""> Look in Baade's window.<br class="">* BGDS light curves -- that's your run-of-the-mill ground-based<br class=""> photometry where at least I don't have even the beginnings of a<br class=""> flux calibration:<br class=""> http://dc.zah.uni-heidelberg.de/bgds/l/ssa/ssap.xml?<br class=""> Data is available in the southern Milky Way plane.<br class="">* Gaia DR2 light curves -- no comment necessary, except I'm using the<br class=""> calibration from SVO's filter profile service (or think I do):<br class=""> http://dc.zah.uni-heidelberg.de/gaia/q2/ssa/ssap.xml?<br class=""><br class="">In case you'd like to jump to sample files directly: <br class=""><br class="">k2c9vst: http://dc.zah.uni-heidelberg.de/getproduct/k2c9vst/data/OGLE-2016-BLG-0968_VST_r_SDSS68.t<br class=""><br class=""></div></div></blockquote><div><br class=""></div></div><div>The filter identifier points to "SDSS r", but to uniquely identify the filter I would have chosen something like : </div><span class="">Facility/Subcategory.Band : VST/OmegaCAM.r_SDSS <br class=""></span><div><br class=""></div><div>The effective wavelength I see under the ESO pages is not 6.12e-7 but 6.25e-7</div><div><a href="https://www.eso.org/sci/facilities/paranal/instruments/omegacam/inst.html" class="">https://www.eso.org/sci/facilities/paranal/instruments/omegacam/inst.html</a></div><div><br class=""></div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">BGDS in SDSS i: <a href="http://dc.zah.uni-heidelberg.de/bgds/l/tsdl/dlget?ID=BGDS-1825-1423-i-277.1723680-14.3354807" class="">http://dc.zah.uni-heidelberg.de/bgds/l/tsdl/dlget?ID=BGDS-1825-1423-i-277.1723680-14.3354807</a><br class="">BGDS in SDSS r: <a href="http://dc.zah.uni-heidelberg.de/bgds/l/tsdl/dlget?ID=BGDS-0744-2158-r-115.2631363-22.6573959" class="">http://dc.zah.uni-heidelberg.de/bgds/l/tsdl/dlget?ID=BGDS-0744-2158-r-115.2631363-22.6573959</a><br class=""><br class=""></div></div></blockquote></div><div><blockquote type="cite" class=""><div class=""><div class="">Gaia DR2, in the three Gaia bands: <br class=""><a href="http://dc.zah.uni-heidelberg.de/getproduct/gaia/q2/1000103304040175360/RP" class="">http://dc.zah.uni-heidelberg.de/getproduct/gaia/q2/1000103304040175360/RP</a><br class="">http://dc.zah.uni-heidelberg.de/getproduct/gaia/q2/1000103304040175360/BP<br class="">http://dc.zah.uni-heidelberg.de/getproduct/gaia/q2/1000103304040175360/G<br class=""><br class=""></div></div></blockquote><div><br class=""></div>Repeated metadata (all in the example k2c9vst)… </div><div>Nothing important, but it seems redundant to see the same information twice. </div><div><div>I wonder if there is no other way of doing this to point to the two different columns in this type of data? </div><div class="">FIELDref would solve that I guess but one is the mag the other the error? </div><div class="">The units are missing for the effective wavelength. </div><div class=""><br class=""></div></div><div><blockquote type="cite" class=""><div class=""><div class="">The files also contain Jiri-type VODML-inspired annotation. Ignore<br class="">it for this purpose (which is easy: just blank out the VODML<br class="">element). Or let me know if you'd team up with me to develop that<br class="">further.<br class=""><br class="">As I said: Any and all feedback is welcome -- and I apologise in<br class="">advance that I couldn't put more time into this, which means it'll be<br class="">easy to spot dumb mistakes.<br class=""><br class="">Meanwhile, three points on the spec itself:<br class=""><br class="">(1) Most importantly: Let's referse the referencing between the<br class="">photcal group and the field, meaning: Don't have<br class=""><br class=""> <GROUP ID="p"/><br class=""> <FIELD name="mag" ref="p"/><br class=""><br class="">but rather<br class=""><br class=""> <GROUP ID="p"><br class=""> <FIELDref utype="adhoc:location" ref="mag"/><br class=""> </GROUP><br class=""> <FIELD ID="mag"/><br class=""><br class=""></div></div></blockquote><div><br class=""></div>I thought about this for some time and I chose ref in the field instead of FIELDref. </div><div>I chose to use the same annotation as for TIMESYS and COOSYS with the hope of having </div><div>the info defined in the same way as those two elements. Basically for consistency. </div><div>But as you also know, I gave up on the idea of a FILTERSYS. So I guess, without thinking </div><div>much about it, it makes no more sense now to have the discussion on FIELDref or not, </div><div>so unless someone else has a strong opinion on the topic I’d be ok with the modification. </div><div>Before making any modifications to the text, I’ll give some time so people can react. </div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">(the sample files currently do both). I've regretted quite often<br class="">already to not have insisted on doing this right in TIMESYS, and I'm<br class="">not sure whether I have to make the points why FIELD/@ref has been<br class="">the wrong choice even for COOSYS again; still, just two key points:<br class=""><br class="">(a) annotation shouldn't change what's annotated<br class=""></div></div></blockquote><div><br class=""></div>Agree on this point. But how does ref instead of FIELDref change what is annotated ?</div><div>In one case the reference goes from bottom to top in the other the other from top to bottom. </div><div>But both things do basically the same in a slightly different way. </div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">(b) the ref scheme fails miserably as soon as there's a second<br class="">annotation on the FIELD; in this case, this could expectably<br class="">measurement, i.e., linking value and error, but it could also be a<br class="">second version of photometry annotation.<br class=""></div></div></blockquote><div><br class=""></div></div><div>True that for linking a value and its error we can use the GROUP and combine with FIELDref. </div><div>And that usage is quite common by now… </div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">(2) We need to make clear which of the items (if any) in photcal are<br class="">mandatory and which can be left out. I'm rather sure that for the<br class="">clients' sake we should make the band name mandatory. I *think*<br class="">having at least an estimate of the effective wavelength would help<br class="">all around, although there's a certain risk people will make things<br class="">up out of thin air (e.g., time series derived from plate scans where<br class="">all you have is an emulsion name). Anything else I don't think we<br class="">can really demand.<br class=""></div></div></blockquote><br class=""><div>Yes, this is a good point. Sometimes we have uncalibrated magnitudes, </div><div>and we should be able to annotated them. So some flexibility should be given </div><div>there. </div><br class=""><blockquote type="cite" class=""><div class=""><div class="">(3) Continuing this, I think it would be good to have a section that<br class="">comments on what to do in a few typical situations, like:<br class=""><br class="">(a) Ground-based photometry of the shoot-sextractor-calibrate-on-some-<br class="">selected-catalogue type (e.g.: can I copy the zero point from SVO in<br class="">these cases? I've not done this in BGDS: should I?).<br class=""><br class="">(b) Gaia (which has linear fluxes but has them in e-/s). Btw., Gaia<br class="">also gives zero points, but these are false friends in this context.<br class="">Since we'll see a lot more of Gaia in the next couple of years, I'd<br class="">say it's reasonable to special-case that even in the Note.<br class=""><br class="">(c) Properly calibrated data in optical (i.e., F_lambda) and radio<br class="">(i.e., F_nu).<br class=""><br class="">(d) Data that gives some sort of relative flux (as in differential<br class="">photometry or perhaps in x-ray, in case someone is confronted with<br class="">fluxes coming in mCrabs -- no idea if they still do that).<br class=""><br class="">(e) Photometrically ill-defined data (my plate scan example above<br class="">might serve as an inspiration).<br class=""><br class=""></div></div></blockquote><br class="">I think this are all valid examples and yes, we can add those cases in the doc. </div><div><br class=""></div><div>Cheers,</div><div>Ada</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> -- Markus<br class=""></div></div></blockquote></div><br class=""></div></body></html>