Time series: Annotation of light curves in VOTable

[François Bonnarel]

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.



>>> 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
> Guessing some possible answers to that question, I'll note that
> using a table written in this form is likely to be quite a bit
> harder for clients than the proposal in the Note text.

A kind of ForeingKey or selection by row mechanism.

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.

Cheers

François

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