Time series: Annotation of light curves in VOTable

[Mark Taylor]

On Tue, 5 May 2020, François Bonnarel wrote:

> Hi Mark, all
> 
> Le 04/05/2020 à 18:13, Mark Taylor a écrit :
> > Francois,
> > 
> > On Tue, 21 Apr 2020, François Bonnarel wrote:
> > 
> > > after discussion with Laurent Michel and Ada I have two points  to
> > > address.
> > > 
> > > 1 ) I think it's better to mark the VOTABLE as being a timeseries right at
> > > the
> > > beginning of the document instead of putting the utype="timeseries"
> > > information at the beginning of the TABLE.
> > I don't understand this comment - I don't see utype="timeseries"
> > anywhere in the current text.
> 
> You are right. I wrongly reproduced a comment I made on an earlier version
> which circulated among authors at the time of the ESCAPE Tech Forum in
> February.
> 
> I didn't notice that Ada removed this utype which was set on the main TABLE in
> the version she made public
> 
> Sorry for that, but most of what I say is still valid I think. See below.
> 
> >   There is utype="timeseries:PhotometryPoint"
> > (along with a sidenote that it needs more explanation), but that's
> > not (necessarily) at the beginning of the TABLE, it's in the
> > PHOTCAL GROUP.
> > In any case I don't agree that the start of the document is the right
> > place to specify that a timeseries is included - perhaps somebody
> > wants to put some time series tables and some other tables in the
> > same VOTABLE document.  Why do you want to do this?
> 
> The discussion went on on this point outside this mailing list. It's on github
> : https://github.com/AdaNebot/TimeSeries/ issues#8 and #29
> 
> It has long been a pain that VOTAble documents don't identify themselves at
> the beginning by saying what spec they are consistent with, and that
> application developpers have to look deep inside the docupment to find out
> what they are expecting to find.
> 
> I agree that this actually a different issue than tagging an element in the
> document (RESOURCE, GROUP or single  TABLE) and claim this way that it is a
> TimeSeries. Also because we don't have a full DataModel for TimeSeries at the
> moment. The latter can be solved (as the discussion on #8 shows) by adding a
> PARAM with utype obscore:dataproduct_type and value "timeseries" at the
> appropriate level.
> 
> For the spec adverizing we now follow DALI and propose an INFO tag at the very
> beginning stating the document is following it.
> 
>     If you find the App developper knows she has to look for TIMESY, COOSYS, a
> GROUP photcal, one or several TABLES where a FIELD with
> ucd="time.epoch;meta.main" plays a special role (independant varibale) etc
> ....
> 
> This doesn't prevent to add other RESOURCES/TABLES in the document for
> additional information.

Thank you for the clarification, I hadn't followed the discussion
on github.  OK I see that restricting the possible content of the
VOTable document has pros as well as cons.

> > > > 2 ) In the current note the multiband case is serialized as 3 tables
> > > > written 
> > > in sequence. Each table has its own PhotCal GROUP attached. In the
> > > attached
> > > example (discussed with Ada) we propose an alternative: a single table
> > > with a
> > > "FilterIndentifier" column. 3 different Photcal GROUPS are attached to
> > > this
> > > tabel and the appropriate Filteridentifier PARAM in each of these group is
> > > referring to the column with the same name  in the TABLE. The assumption
> > > is
> > > that photometric metadata given in the GROUP are valid for all roaws where
> > > values of FilterIndentifier in the row and in the GROUP PARAM match.
> > By the "FilterIndentifier" column I presume you mean the one with
> > name="photometric_filter" in the example.
> Yes. Example fixed on github since then.
> > What values actually go
> > in this column? there's nothing written in the example.
> filter names = GAIA/GAIA2.G, GAIA/GAIA2.Gbp, GAIA/GAIA2.Grp

Filter name is a reasonable choice.  Then that example contains
a large number of unused ref and ID attributes, which I would argue
make it unnecessarily confusing.

> The main discussion is around this:
> 
> Considering that for multiband lightcurve you can imagine at least three
> solutions
> 
>     a ) 3 distinct but similar table
> 
>     b ) a table giving the filter value in a column in addition with mag/flux
> columns
> 
>     c ) a table with different  mag/flux columns per filter
> 
> and that for example  for gaia VizieR had a ) and ESAC had b) do we force
> everybody to have a ) or do we look for solutions allowing a ) , b) (and even
> c ) )
> 
> This is the main question. As you can see on github other solutions are
> currently discussed.  So the one I posted 2 weeks ago is not favoured among
> authors at the moment
> 
> This is still ongoing discussion because the issue is real.

I agree that in some cases the data are more conveniently represented
in a way that requires per-row reference to wavebands.
As I say, that's likely to make the implementation more complicated,
but perhaps not unreasonably so.  I'll watch this space.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/