*IVOA DAL WG Running Meeting #4 *Wednesday 4 November 2020 - 10:00 UTC - vconf Participants: (15) Marco Molinaro, Carlos Rodrigo, Laurent Michel, Markus Demleitner, Ada Nebot, James Dempsey, Mark Taylor, Mireille Louys, Brent Miszalski, Gregory Mantelet, Patrick Dowler, Jesús Salgado, Enrique Solano, François Bonnarel, Dave Morris *Agenda: TimeSeries discovery & access *Notes: *1. Time Series Presentation by Ada (available at https://wiki.ivoa.net/internal/IVOA/IvoaDAL_RunningMeetings/DAL-RunningMeeting04NOV2020-TimeSeires.pdf) 3 discovery solutions from Bonnarel's 2018 IVOA Note: 1. source driven [my take: SSAP is already being used for that; let's keep that -- MD] 2. obscore-like driven 3. mixed solution: obscore + specific reqs. goal for today: review, discuss and try to move forward [see questions in the slides] ES: Naive question. If I want to build a VO tool to manage time series, what type of query should I make at registry level to identify the services providing time series? MD: Right now, the closest you have is look for SSAP services that declare the dataproduct type time series (that's in the new SimpleDALRegExt draft). Takeup by your CoRoT folks is pending some minor fixes in the ESAVO registry. MD: The discovery query for time series-carrying SSAP services (works already) is: select ivoid from rr.capability natural join (select ivoid from rr.res_detail where detail_xpath='/capability/productType' and detail_value='timeseries') as ts_ssa where standard_id='ivo://ivoa.net/std/ssa' (from http://mail.ivoa.net/pipermail/registry/2020-March/005425.html) ES: Thanks! ES: SSAP is fine (actually the two SVO time series services - OMC and COROT- are registered as SSAP services). But what about time series services not registered as SSAP? How to discover them? MD: Are there any? ES: I do not know but, according to Ada, time series services can also be registered using ConeSearch. MD: I'm not aware of any. AN: I meant we can discover sources using ConeSearch wich might have associated time series About the results: object, or list of, and URL pointer to time series - LINKwith VOTable and specific "content=timeseries" - DataLink {links} MD: What's wrong with plain SSA-Style accref? --MD Access to part or transformation of the Time Series: usage of SODA? PD: parameters in mime-types, this shouldn't be done but it should be in the original document describing the mime-type -> issue opened in VOTable repo. PD: DataLink agreed in using a new optional field for vocabulary term (starting from obscore dataproduct_type vocab) -> issue on DataLink added Extensions to obscore: at NDCube phase, it turned the added elements were useful to more use cases. PD: the idea should be identifying the needed extra params, add them to obscore if they fit a general scenario, leave them in a connected other table if not. PD+FB: check on 10-years old proposal for change to SSAP about an extra table to use. JS: (summary ) catalogues format is used to provide several time series at the same time ( reported by ML) not only focused on the query interface metadata of SSAP (e.g. coordinates and other basic metadata). With TAP, query could be done in a quite natural way on conditions/features on the data itself will write these points in a mail to the DAL List and possible problems found on the current SSAP for projects like, e.g. Gaia (of course, SSAP could be also extended to cover most (all?) of these use cases) AN: finding the best parameters to describe the time series, e.g. for "variability", is not trivial, it depends a lot on the use cases. JS: the project's content describes what function you need to decsribe for discovery. E.g. basic variablity concept can be defined and a more complex project-specific concept could be handle through a UDF (e.g. variability for Plato could be related to a classification on types of candidates for planets transits, something totally different than for other projects) MM: Are we heading to another simple protocol? PD: If we remove the I from SIAP2 we would have a general data discovery protocol. MM: This has been discussed before MD: A revision of SSA could also converge with SIA and potentially merge them, noting that SSA spec has a lot of quirks -- but that's really rather distinct from time series discovery as such; for that, I'd still have to see how SSAP isn't sufficient for what an S-protocol can do in the first place. BM: I like the suggestion to unify SIA and SSA, it would make maintenance a lot easier, instead of having to maintain two different (but essentially very similar services). The way SIA handles the parameters is much better than SSA SIA interface on top of TAP : many project use this: from chat discussion JS , 'I have implemented both SIA and SSA for a project by defining a table into ivoa schema with the parameters (and transforming the query interface). I think CADC architecture is also similar to this (a translator from S*AP interfaces to a TAP on TAP tables)' JamesDempsey: 'Our SIA, probably like many is just a translate layer for queries against ObsCore and I think it can return non images' CADC, ESO also has this strategy. PD: CADC allows both TAP (via Obscore etc) and Simple protocols depending on the user's needs. FB: While SIA returns slightly different fields than TAP/ObsCore it would be useful to add spectra and time series to SIA FB: TIMESYS in ObsCore may be different ot the timesys of the data (i.e reference or time scale in votable 4) AN: For some use cases you need to know the timescale - hard to put in a response MD: This is really not a discovery problem - the level of precision is not needed. Recommend use TCB, fall back to UTC - should be close enough, in discovery one shouldn't worry about a few 10s of seconds. Recommend barycentric and tell clients to deal with the 10 min that topocentric times around the earth will be off.