IVOA Roadmap for 2017B

This outlines the roadmap for development activities by the various IVOA working and interest groups in 2017/2018 between the Santiago and Victoria Interops.

Applications

• HiPS
  • Usage: Continue to encourage the App members to declare their HiPS servers in VO registry according to the new HiPS standard REC
  • Deployement : Hips network extension
  • Standard: Nice to have a note on new ideas around HiPS (progenitors, polarized tiles, planeto...)
• VOTable
  • Erratum 2: "arraysize=1" : discussion, redaction
  • Standard: Awaiting VODML VOTable serialization consensus (see DM roadmap)

Data Access Layer

• TAP 1.1
  • New PR by end of November
  • RFC before Christmas
  • REC possibly before Spring interop
• ADQL 2.1
  • New version of the WD in November
  • PR should follow directly from it
• Datatype Consistency check among ADQL, TAP, DALI
  • Find a volunteers team ASAP
• SCS 1.1
  • lets' go on with discussion of WD in end 2017, early 2018
  • New WD in early 2018, if enough participated, PR after Spring interop
• SLAP 1.1
  • Publish the current WD
  • Revisit the DALI compliancy and upgrade rationale for a new WD in early 2018
• PROVDAL 1.0
  • WD end 2017/early 2018
  • PR before spring interop
• PROVTAP 1.0
  • WD end 2017/early 2018
  • reference implementation to be worked out for Spring interop
• DataLink discovery modifications
  • DAL chair note to be published early december
  • Endorsed note early 2018 ?
• DAL multi-D protocols (ObsCore, SIAV2, DataLink, SODA) upgrades or extensions : generic and TimeSeries-oriented
  • DAL chair and co-chair note end 2017
  • Follow-up to be coordinated with TDIG and DM WG.
• Errors detected by Validators in DAL services .
  • DAL chair and co chair to revisit this with Ops and validator operators and report at spring TCG teleconf

Data Model

Grid and Web Services

Below is the 6-month roadmap for the Grid and Web Services Working Group after a successful and productive interop meeting in Santiago. The work related to UWS is the outcome of a resolution of a Registry WG issue of discovering services with multiple interfaces.

• VOSpace 2.1
  • To adopt new UWS sync and async types in interfaces for transfers
  • Make clear in the standard capabilities the use of VOSpace standardIDs
  • Add standard registry records (2.0 & 2.1)
  • Goal: RFC / TCG approval before 2018

• New UWS standard registry records for interface types (uws:sync, uws:async)

• Complete KDD/GWS Machine Learning experiment for code-to-data
  • more needed! (see below)

• Group Membership Service Working Draft

• Contributors needed for:
  • Interoperable code-to-data prototypes
  • Recommendation for Federated Authentication — An IVOA recommendation on how to integrate with federated authentication systems
  • Note giving examples on how to use the SecurityMethods described in SSO 2.1
  • Into the VO: Probabilistic Kernel Density Classification?

• If time permits:
  • Note on the proper pattern of making VO Service calls

Registry

• Registry Interfaces 1.1, which in particular lets RegTAP operators register their services as registries, is ready for exec review now and should become REC within 2017.
• VOResource 1.1 (among other things, enabling DOI usage in the Registry): Has been in RFC since June; we will include some new changes to securityMethod (now 1:1 mapping to interface and allowing extensions through other schemas), so REC will probably have to wait until early 2018. Meanwhile, we will encourage takeup of the new features and terms among the authors of resource records.

• RegTAP 1.1, putting the new VOResource 1.1 features into RegTAP, will see a PR right after VOResource 1.1 becomes REC; prototype implementations already exist at GAVO and partially at ESAVO. The main change will forseeably be support for services requiring authentication; that will, in particular, require changes in common client queries to RegTAP services once these become more common.

• STC in the Registry: We will continue to roll out prototypes using the current footprint URI mechanism and, based on those, try a simple extension scheme for coverages on the axes in ObsCore. Whether or not this will be included in the VODataService schema or we will provide a standalone REC remains to be seen.

• Discovering Dependent Resources: This is a proposed endorsed note trying to solve the problem of properly discovering data collections that are published through other services, the prime use case so far being TAP tables. We still solicit takeup by operators of major data centers, with VizieR expected to publish complying resource records soon (cf. HowToEnableTableDiscovery). This also will help requirements and recommendations coming from Apps ("Aladin 10").

• Standards records: We will continue to work with the chairs of the other IVOA working groups to ensure that they register their standards as envisioned by StandardsRegExt (cf. WriteAStandardsRecord).

• TAPRegExt 1.1 will not be a dependency of TAP 1.1 any more, per agreements in Santiago. We will therefore probably delay a new PR until possible further requirements from ADQL materialise.

• Interest in developing a resource extension for VOEvent components has resurfaced; we will work towards having a revised working draft by Victoria (May 2018).
  

• Maintenance: We will keep making sure the registry system runs; in particular, we will address the remaining serious anomalies diagnosed by ESAVO and the grievances brought forth by the solar system IG.

Semantics

Data Curation & Preservation

The Data Curation \& Preservation IG will continue to be the place where liaison between the IVOA and the Research Data Alliance RDA is established, with regular discussion of RDA activities, their relevance to the IVOA, and the IVOA activities relevant to the RDA (eg Provenance). This is a standing item for the IG session at each IVOA Interoperability meeting. The DataCP IG also hosts discussions on topics such as DOI usage in astronomy.

Education

Knowledge Discovery

Operations

Monitoring activities at VO-Paris, ESA and the HEASARC will continue, though efforts will be somewhat lessened at the HEASARC.

A monthly mailing giving a summary of the validation and operational state of the VO will be started.

The Ops group will encourage the development of validation capabilities in the DataLink and VOEvent. The implementation of standalone validators for the simple DAL services would be valuable to developers who currently must deploy a service before it can be validated by the existing web based frameworks.

The Ops group will also continue to explore if and how we might extract and deseminate usage information to understand which protocols are enabling our communities. Understanding the differences in usage patterns may be very helpful in guiding both the development and deployment of standards.

Theory

Time Domain

Standard and Processes

Science Priorities