Time Domain DAL/DM/TDIG

Mon Jul 10 18:07:07 CEST 2017

And for most sources this will not be known. So can we put it in a v1.1 and just have a basic v1.0 which supports the absolute minimum and we can get out quickly and used within 6 months - 1 year?

— Matthew

> On Jul 10, 2017, at 12:00 PM, François Bonnarel <francois.bonnarel at astro.unistra.fr> wrote:
> 
> Dear Ada, Marco,
> 
> Dear all,
> 
> 
> Le 10/07/2017 à 09:22, Marco Molinaro a écrit :
>> Dear Ada,
>> dear TD/DM/DAL-ers,
>> 
>> you're right, the query by object type (target name, position, class,
>> subclass, ...) is definitely a must, but I got the impression that the
>> stellar activity is critical for exoplanets (at least).
>> 
>> So, this is a first requirement from my use case: we will need the
>> activity value associated with the activity index type. That is, we
>> have to leave room for queries that say
>> 
>> stellar activity within these boundaries measured with this index
>> 
>> I think (my case) I could live, e.g. having a source_activity column
>> annotated by one UCD among a set that describes the activity index.
>> I don't think there exist such UCDs, but I haven't checked either.
>> And maybe there exist other solutions.
>> Taking the worst case: how can I deal with multiple activity indexes
>> describing my host star?
> This is a very interesting statement. But I wonder if we can add this explicitly in the TimeSeries metadata itself. It's the "Source detailed description".
> 
> Isn't that typically a case wher we will query a star catalog for this kind of index using TAP and then query TimeSeries around the discovered sources ?
> 
> So this is probably nice combination of TAP queries and more generic time Series queries ?
> 
> Apparently this UCD doesn't exist. But it can probably be added in phys.magField branch ?
> 
> Cheers
> François
> 
>> 
>> As for the planets and their characteristics, constraining the search
>> on those can be a back end problem, but:
>> - planet (confirmed or supposed) existence
>> - (stats on?) mass, period, eccentricity
>> can be a minimal metadata starting set.
>> 
>> And about discovery methods, that's definitely something they need
>> to cross match planets (maybe more for catalogues than time series
>> themselves), and it would require a single element from a controlled
>> vocabulary. I didn't mean going into the single details of the methods,
>> for sure.
>> 
>> Finally, checking on François's metadata blocks, I'd say that
>> - object position
>> - time sampling characteristics and stats
>> - object class (activity augmented)
>> have to be in the minimal list.
>> 
>> Cheers,
>>     Marco
>> 
>> 2017-07-07 13:51 GMT+02:00 AdaNebot <ada.nebot at astro.unistra.fr>:
>>> Dear Marco,
>>> 
>>> Thanks for your input.
>>> 
>>> On 6 Jul 2017, at 14:47, Marco Molinaro <molinaro at oats.inaf.it> wrote:
>>> 
>>> Dear Ada,
>>> dear all,
>>> 
>>> regarding the "discovery" item, related to RV Time Series
>>> in the exoplanets domain, I had a meeting with people
>>> from the GAPS project.
>>> (if interested a quick summary can be found here:
>>> https://www.asterics2020.eu/dokuwiki/doku.php?id=open:wp4:wp4gapsinaf)
>>> 
>>> The main point I'd like to alert about here (other parts I think
>>> are nicely covered by your summary and review) is that a
>>> discovery for time series when doing research on exoplanets
>>> requires:
>>> - host star characterisation, especially stellar activity indexes
>>> 
>>> 
>>> Regarding the host star characterisation, I think this is in the lines
>>> "query by object type”.
>>> This is very important not only for exoplanets but for many other scientific
>>> cases.
>>> 
>>> - planet(s) ~existence~ and characteristics
>>>  [and this may be though because 1 stellar system potentially
>>>  means multiple planets]
>>> 
>>> I agree with you
>>> 
>>> 
>>> And, vice-versa, searching exoplanets having time series attached
>>> requires as discovery metadata the search method used (this can be
>>> a small vocabulary).
>>> 
>>> I'll try to work on the star/activity/planets part related to the GAPS
>>> project, the vice-versa requires other projects with different than
>>> spectroscopic RV method to join.
>>> 
>>> 
>>> There is a list of metadata needed to describe and discover TimeSeries that
>>> we came up with during the ASTERICS hackathon meeting,
>>> summarised by F. Bonnarel in Shanghai. I have rewritten that list under:
>>> http://wiki.ivoa.net/twiki/bin/view/IVOA/DAL_DM_TDIG_ShanghaiSession2017#Asterics_hackathon_report_F_Bonn
>>> 
>>> To my opinion some of the things there are too detailed/complicated, e.g.
>>> Fourier coefficients.
>>> And I think that we can build a restricted list of minimum requirements
>>> based on those.
>>> Please, have a look at the list and let me know among those fields which you
>>> think are a must.
>>> 
>>> Cheers,
>>> Ada
>>> 
>>> Cheers,
>>>    Marco
>>> 
>>> 2017-07-04 13:08 GMT+02:00 AdaNebot <ada.nebot at astro.unistra.fr>:
>>> 
>>> 
>>> Dear All,
>>> 
>>> In Shanghai it was decided that TimeSeries is a scientific priority of the
>>> IVOA. Based on the DAL/DM/TDIG session, here is a list of items to be
>>> discussed. Please feel free to add any other items you consider relevant to
>>> TimeSeries and you would like to discuss:
>>> 
>>> What is TimeSeries data? It is a temporal sequence of measurements
>>> containing a time coordinate and a flux (or similar - magnitude) / RV /
>>> position / polarisation / number of spots / spectra / images. Light-curves
>>> and RV curves dominate the landscape of TimeSeries.
>>> Concerning DM: there are models that work for representation of some of the
>>> science cases proposed by the SPC.
>>> 
>>> Modified SpectrumDM works fine for light curves with some modifications.
>>> The draft TimeSeriesCube serialisation examples work with SPLAT. But there’s
>>> still some discussion needed on the model.
>>> Feedback from people who have tried both models is appreciated in this
>>> respect.
>>> Although light-curves and RV curves dominate the landscape of TimeSeries,
>>> for which a modified version of SpectrumDM (or a similar for RVs) would
>>> work, we should have an extensible model towards other kind of data, perhaps
>>> built as a simple derivation/specialization of the SparseCube DM.
>>> 
>>> Discovery: Obscore/EpnCore + TAP could work if the time axis information
>>> would be extended. What are the minimum mandatory fields for TimeSeries data
>>> to be found by the user? For that collecting science cases is important. A
>>> set of minimum data has already been compiled during an ASTERICS meeting.
>>> Different communities need to be properly represented. Attending to
>>> astronomy meetings is important to hear the astro-community. See the series
>>> of meetings under:
>>> http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaVOEvent#Future_Events. Please
>>> if you plan to attend any of these meetings or any other related Time Domain
>>> meeting it would be useful to know it and to post it on the wiki.
>>> Format: Time has to be properly formatted to combine data coming from
>>> different surveys. See email from A. Rots (19 May 2017) sent to DM, DAL and
>>> TDIG + reference A&A 574, 36 (2015).
>>> 
>>> To keep track these items will be posted on the TDIG wiki, under the
>>> TimeSeries section:
>>> http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaVOEvent#Time_Series_Data
>>> 
>>> In particular under: http://wiki.ivoa.net/twiki/bin/view/IVOA/DAL_DM_TDIG I
>>> have already written these four items.
>>> 
>>> You can also find a summary of the different contributions in the
>>> DAL/DM/TDIG Shanghai session under:
>>> http://wiki.ivoa.net/twiki/bin/view/IVOA/DAL_DM_TDIG_ShanghaiSession2017
>>> 
>>> The intention of this email is to start productive discussions on each
>>> topic.
>>> 
>>> Thanks!
>>> Ada
>>> 
>>> 