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

Datalink 1.1

• RFC open - complete and get to REC

DALI 1.2

• PRec + RFC mid 2023

TAP 1.2

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

Conesearch 1.1

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

SIAP-2.0 -> Data Access Protocol v1

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

SODA 1.1

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

Secondary
LineTAP

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

ObjVisSAP

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

SSA

• Issue errata for minor issues already noted in github

ADQL User defined functions

• Can functions be reconciled between GAVO and OAJ?

ProvTAP

• Continuing work towards mature WD status

Data Model WG

Primary:

Spectrum 1.2 RFE:

• confirm implementations are sufficient for RFC; possibly drop 'relorder' attribute
• proceed to RFC

Transform 1.0:

• implement python workflow scripts as jupyter notebooks
• proceed to RFC

ObsCore extension for Radio domain

• working implementations
• meeting in September
• goal: RFC ready for next interop

Secondary:

Mango 1.0:

• reducing content/scope; working implementation
• goal: concrete WD for next interop

Dataset Metadata 1.0:

• revise model per discussion in Bologna interop
• define and execute appropriate implementations (in context of TimeSeries, Cube, Mango)
• goal: concrete WD for next interop

Modeling High Energy Datasets:

• Meeting June 28
• evaluate and report on compatiblity of current models (eg: Cube) with High Energy data.
• evaluate and report on possible ObsCore extension, following Radio example.
• identify workflow threads to exercise models in this context

Provenance, one step:

• finalize Note, see if this can become a WD
  • as 'view of Provenance' similar to ObsCore

Other:

VODML Toolkit

• integrate toolkit usage into model repositories
• utilize to generate code package of vo-dml compliant models.

NDCube 1.0:

• work on Dataset, and High Energy should define additional workflow threads which exercise this model in other contexts.
• goal: implement any defined workflow cases

Characterisation 2.0:

• VO-DML compliant version of Characterisation model
• goal: WD by Spring 2024

Field of View:

• formalizing model basis for Aladin FoV format used by STScI and others
• goal: no stated goals this semester

CAOM:

• continue discussions with CADC about how this model fits into the IVOA ecosystem, if at all.

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
-->