*IVOA November 2020 Interoperability Meeting *Data Access Layer - session 1 *Tuesday 17 November 2020 - 13:30 UTC participants: 84 *Aitor Ibarra *ObjVisSAP status & discussion To support observatory coordination with standards. Requirement for multi-messenger coordination of observations (increasing demand). What can be improved in planning an observation: check target visibility and if it has been already observed. Facilities have these info, but not in a standardised way. ObjVisSAP deals with the visibility periods for the facilities. ObsLocTAP deals with the previous and planned observations. Standards have been developed engaging the communityas much as possible. XMM-Newton, Integral, Gaia, Chandra, NuSTAR already implemented the current version of the standards. Implementation can be more difficult with a long running observatory, where tailoring of the information to the protocol can be more complicated. Feedback from the workshops held: - moving targets? - facilities with multiple telescopes? Tools (python+Django for ObjVisSAP and Docker containers for PostgreSQL+pgsphere and a TAP server for ObsLocTAP) available and re-usable to start new implementations. A client also exists that can consume both ObjVisSAP and ObsLocTAP services. Q&A M. Dem: a TAP-based + a SAP solution. It makes queries harder. A. Iba: it depends on the requirements that fit two different solutions. It can be re-thought. C. Arv: the decision to have these two standards was taken a couple of interoperability meetings ago and I think we should avoid to have again this discussion, considering the current takeup so far and the wish of space and ground projects to get these standards as Recommendations so they can finilaze their operational implementations and start using them. B. Cec: FoV can play a role, depending on the obs.band (e.g. radio). All em are in energy, where in the VO is usually not. em threshold is not defined. A. Iba: this can be changed to make it uniform. [Markus' take: a nice ADQL UDF converting to/from the preferred units would, I think, solve a lot of the discipline-specific concerns][Jesus: Units in ObsLocTAP are consistent with the rest of VO protocols. It is ObjVisSAP probably the one to be ammended and it is still in WD so we are in time] A. Neb: curious on how you made the engagement happen? A . Iba: Jan-Uwe Ness contacted all the facilities to start from and response was nearly immediate. T. Don: comment on successful story. Reaching operations group is an interesting new approach. Reaching many facilities and getting response and implementation is also important, with 1 response it is difficult to see progress. J. Eva: agree with Tom on the successful story. (some comment I lost about the accuracy of te visibility. A. Iba: accuracy of the response (in terms of how long the visibility holds trues) has been added in response to this. *Markus Demleitner *Vocabularies 2 and DAL * DataLink VEPs * pyVO extension * data product types The words, list and hierarchy of vocabularies requires review and upgrades. VEPs are there for this, providing also a discussion place for the proposed terms. VEP-006 is currently open. pyVO DataLink interface. A PR on pyVO will add querying/changes to ".bysemantics" method. dataproduct_type in ObsCore is so far a should on the document content. Proposal to allow extension without touching the standard itself, i.e. move it into a vocabulary. Possibly allowing hierarchy, that could be useful, e.g. in time series. Would also allow out-of-obscore re-use (MD did it in TAPRegExt, e.g.) and make the terms machine readable. Vocabularies in the VO 2 is under review. LSJ: may I declare my interest/curiosity for Continuous Integration things, now as reader/voluntary. F. Bon: comment on time series content of the proposal. Also on DataLink the dataproduct type is under convergence with the proposed solution. A. Mic: The ADQL query: SELECT … FROM ivoa.ObsCore WHERE dataproduct_type=‘time series’ would not return products whose type is ‘photo-timeseries’, hence I do not understand the proposal. M. Dem: vocabulary matching to be discussed (maybe in a next DAL running Meeting). Implemented right now on http://dc.g-vo.org/tap: select top 5 * from ivoa.obscore where 1=gavo_vocmatch('product-type', 'timeseries', dataproduct_type) B. Cec: epncore has an extended list of product types. have a look at it and maybe try to merge it. MireilleLouys: +1 for this converging effort *Stéphane Erard *EPN-TAP 2.0 Working Draft including EPNcore Solar System data access in general (not only archive but also from research publications) Difficulties: moving target, resolved targets, diverse type of measurements. TAP plus ObsCore were a good start but more parameters were needed. WD-EPN-TAP-2.0 recently submitted to IVOA documents repo. 55 data services, ~20 teams -> makes it a mature solution. EPN-TAP exposes 1 table (.epn_core). 1 row == 1 product URL access can be a file or a web service, including DataLink. Uses min/max couples of parameters w.r.t. direct range values Value listings are #-separated Mandatory parameters are there for interoperable queries to all services There are ~180 params (mandatory + optional) Custom parameters are allowed. Similarities and differences w/ ObsCore (on mandated parameters, observational axes descriptions, positional and time frames). Open issues: need for more UCDs, growing vocabularies, ADQL flexibility, extra standards for various contexts... F. Bon: about DataLink issue. Was it already knows to DAL or is it a new one to be added to v.1.1 progress? S. Era: will attend DataLink session to comment. M. Tay: time_origin -> VOTable.ref_position? Need to check. S. Era: could still be changed (requires investigation). MT: In VOTable (sec 3.5), there is a TIMESYS element with attributes 'refposition' (giving the spatial location associated with the time measurement, e.g. 'BARYCENTER') and 'timeorigin' (giving the zero point of the time coordinate, a numeric JD value). The EPN-TAP 'time_origin' looks like it corresponds more or less to VOTable 'refposition' and not to 'timeorigin'. So if it's relatively painless to reconsider the naming in EPN-TAP, that could be a good idea.