Time Domain DAL/DM/TDIG

Tue Jul 11 09:35:34 CEST 2017

Hi,

I do not think that the TS models must embrace a wide set of sub-domains meta data.
The purpose of the model, of any model, is to help for data discovery (obscore e.g.) or to describe a dataset with a set of 
common meta-data (NDCube e.g.)
This restriction is not blocking since there is a Swiss knife for people interested in dealing with specific meta-data, this is TAP.
The  Marco's use case can be solved with one (or more) TAP table containing a full description of the host stars.
The discovery search could then be achieved by joining it with the ObsTAP table.
The model used for the discovery step (extended ObsCore e.g.) must expose a quantity which  can be used to do the join however.

Thus would work for know, but in the future, we could imagine a extended TAP schema enable of to bind a model with a set of tables.

Cheers
LM

Le 11/07/2017 à 08:32, Marco Molinaro a écrit :
> Hi François,
>
> 2017-07-10 18:00 GMT+02:00 François Bonnarel
> <francois.bonnarel at astro.unistra.fr>:
>> 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 ?
>
> Searching sources and then time series around them is
> positional search after object query.
> I wonder if this is not another case where an exact cross-match
> is needed.
>
> Since "around" has to be specified somehow,
> having characterisation of the host star as metadata
> attached to the time series would allow for the opposite.
> Time series discovered by position and then filter (even
> locally) by host characteristics.
>
> So maybe it's simply additional metadata to get in the
> response that can do the trick and let everything to
> the client (for small/medium numbers it will work for sure).
>
> This'll solve Matthew's issue with excessive number of
> filtering metadata (also because most of the time they
> don't exist).
>
> But my point here was mostly about how to store
> multiple metadata having the same role but different
> physical observational origin.
>
> Probably better move this topic out of here, it really seems
> divergent with respect to time series.
>
>> Apparently this UCD doesn't exist. But it can probably be added in
>> phys.magField branch ?
>
> I'm not really concerned about what UCD to use, a solution
> there I suppose can be found at the proper stage (but yes,
> the suggested branch may be the one).
>
> Cheers,
>       Marco
>
>>
>> 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
>>>>
>>>>
>>

-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg