IVOA Roadmap for 2023A

This outlines the roadmap for development activities by the various IVOA working and interest groups between the May 2023 and Nov 2023 Interops.

Applications WG

Data Access Layer WG

Primary:
ADQL

• 2.1 RFC - complete and get to REC
• 2.2 - PEG, INTERVAL support, MOC support, Array support, string functions, OFFSET

• RFC open - complete and get to REC

• PRec + RFC mid 2023

• User managed persistent tables
• Experiment with Open API spec for these changes

• RESPONSEFORMAT, MAXREC
• Allow services to reject unknown parameters
• Modernize required UCDs (UCD 1.0-> UCD 1+)
• PRec by next interop

• Proceed with renaming, expansion of supported data product types
• Miscellaneous changes
• Moving to WD status

• return extended metadata
• New transformation types
• Moving to WD status

• Client and server implementations progressing
• Raise PRec once implementations ready

• Examine renaming to avoid radio confusion
• Restart effort to complete the standard and get to PRec

• Issue errata for minor issues already noted in github

• Can functions be reconciled between GAVO and OAJ?

• Continuing work towards mature WD status

Data Model WG

Grid and Web Services WG

Pending upgrades

Pending Update SSO 2.1, including issues at:
https://github.com/ivoa-std/SSO/issues

Also, reformat of GitHub repository.

Cross-science platforms execution project

The GWS WG is going to start a project to identify the main changes and new standards to allow remote execution on different astronomical science platforms. The preliminary items to be analysed are:

Execution planner

Currently, a note has been prepared at
https://github.com/ivoa/ExecutionPlannerNote

This note should be either converted into a standard or, at least, upgraded making it a more powerful interface. To do that, it is necessary to standardise:
Characterisation of software (in terms not only of software dependencies but, also, dependencies that could affect execution like memory, requirements on computing architecture (e.g. CPUs and GPUs), data location, etc. Software should be exposed in a portable format
Metadata characterisation of the science platform node is also a requirement

Access to this metadata should be also characterised as per the definition of a software discovery service and a science platform resources discovery service. The execution planner could use metadata of both types to decide the best place to execute a certain workflow.

For the software characterisation and discovery, other CI/CD solutions could be expanded and already have the connections between code and containers. For the science platform node service, we need to have a dynamic service to capture the real-time status of the resources.

The execution planner and the science platform discovery service could be integrated into the same service and the software discovery looks to be a different one.

Endorsement of a standard for workflow serialisation

Identify one standard for workflow serialisation (e.g. CWL) and endorse it for the IVOA. This format should have software to parse and decompose a workflow in smaller executable elements in different languages if possible.

Execution interface

Identify an execution interface that could abstract the internal execution interfaces of the different science platforms. Probably something based on IVOA UWS could be used to control execution

Credentials Delegation

Review of related standards for authentication/authorisation combined with the execution interface. This could be a problem for a general approach as some computing centres have their local access policies

For this exercise, SKA Regional Centre Network members are available to collaborate, lead and implement although it would be also needed to have members of other projects that are implementing (or already have) running science platforms to create another independent implementation (candidates Vera Rubin, ESA, CADC, Gaia UK,...)

Registry WG

Semantics WG

Data Curation Preservation IG

Education IG

Knowledge Discovery IG

Operations IG

Radio IG

• Pushing ObsCore Radio data extension (inteferometry/visibility and single dish) to PR status by solving issues and pushing implementations
• Update implementation review note with recent progress and additional implementations (projects such as NRAO, GBT, SKA, IRAM, SpanifhVO, etc...)
• Work on a full draft for the Pulsar and FRB Radio Data Discovery and Access note
• Continue work on integhrating radio services and software in plaforms (python notebooks and whatever) for finding and downloading radio data through the VO.

Solar System IG

• Continue development on Observation Facility Codes
• Get some prototype planetary reference frames incorporated into the Reference Frames vocabulary
  • This tutorial explains how the Navigation and Ancillary Information Facility (NAIF) software defines (and uses) reference frames and coordinate systems: NAIF Frames and Coordinate Systems Tutorial
  • The list of IAU defined body-fixed frames is included in the NAIF software documentation on frames, as an appendix: direct link to "frames.html" second appendix
• Ensure convergence of the EPN-TAP dataproduct_type with the Data Product Type vocabulary.
• Support PDS/SBN efforts to exercise EPN-TAP and planetary additions to related protocols by implementing IVOA services on small data sets from several different planetary disciplines.

Theory IG

Time Domain IG

Standard and Processes

<!--
* Set ALLOWTOPICRENAME = TWikiAdminGroup
-->