(r10) 2023ARoadmap < IVOA

IVOA Web>IvoaTCG>2023ARoadmap (revision 10) (raw view)~~EditAttach~~
---+ 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.

%TOC%

---++ Applications WG

---++ Data Access Layer WG

<b>Primary:</b><br />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-&gt; UCD 1+)
   * PRec by next interop
SIAP-2.0 -&gt; 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
<b>Secondary</b><br />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:<br />https://github.com/ivoa-std/SSO/issues<br /> <br />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<br /> https://github.com/ivoa/ExecutionPlannerNote <br /> <br />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:<br />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<br />Metadata characterisation of the science platform node is also a requirement<br /> <br />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.<br /> <br />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.<br /> <br />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,...)_
<div id="likes-and-labels-container"> </div>
---++ 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 [[https://www.ivoa.net/rdf/refframe/2022-02-22/refframe.html][Reference Frames]] vocabulary
      * This tutorial explains how the Navigation and Ancillary Information Facility (NAIF) software defines (and uses) reference frames and coordinate systems: <a href="https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/Tutorials/pdf/individual_docs/17_frames_and_coordinate_systems.pdf" target="_blank" title="NAIF Frames and Coordinate Systems Tutorial">NAIF Frames and Coordinate Systems Tutorial</a>
      * The list of IAU defined body-fixed frames is included in the NAIF software documentation on frames, as an appendix: <a href="https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/req/frames.html#Appendix.%20%60%60Built%20in''%20PCK-Based%20IAU%20Body-Fixed%20Reference%20Frames" target="_blank">direct link to "frames.html" second appendix</a>
   * Ensure convergence of the EPN-TAP _dataproduct_type_ with the [[https://www.ivoa.net/rdf/product-type/2021-11-18/product-type.html][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

&lt;!--<br /> * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup <br />--&gt;
Topic revision: r10 - 2023-06-20 - MarkCresitelloDittmar
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema