Difference: 2017BRoadmap (1 vs. 8)

Revision 82018-06-20 - GiuliaIafrate

 
META TOPICPARENT name="IvoaTCG"

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

Changed:
<
<

Data Curation & Preservation

>
>

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


<--  
-->

Revision 72018-05-27 - FrancoiseGenova

 
META TOPICPARENT name="IvoaTCG"

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

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


<--  
-->

Revision 62018-02-22 - PierreFernique

 
META TOPICPARENT name="IvoaTCG"

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

Changed:
<
<
>
>
Added:
>
>
    • 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.
Changed:
<
<
  • 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.
>
>
  • 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.
 
Changed:
<
<
  • 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.
>
>
  • 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.
 
Changed:
<
<
  • 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").
>
>
  • 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").
 
Changed:
<
<
  • 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).
>
>
  • 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).
 
Changed:
<
<
  • 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.
>
>
  • 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.
 
Changed:
<
<
  • Interest in developing a resource extension for VOEvent components has resurfaced; we will work towards having a revised working draft by Victoria (May 2018).
>
>
  • 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

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


<--  
-->

Revision 52017-11-13 - TheresaDower

 
META TOPICPARENT name="IvoaTCG"

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

Data Access Layer

Changed:
<
<
  • TAP 1.1
>
>
  • TAP 1.1
 
    • New PR by end of November
    • RFC before Christmas
Changed:
<
<
    • REC possibly before Spring interop
  • ADQL 2.1
>
>
    • REC possibly before Spring interop
  • ADQL 2.1
 
    • New version of the WD in November
Changed:
<
<
    • PR should follow directly from it
  • Datatype Consistency check among ADQL, TAP, DALI
>
>
    • PR should follow directly from it
  • Datatype Consistency check among ADQL, TAP, DALI
 
    • Find a volunteers team ASAP
Changed:
<
<
  • SCS 1.1
>
>
  • SCS 1.1
 
    • lets' go on with discussion of WD in end 2017, early 2018
Changed:
<
<
    • New WD in early 2018, if enough participated, PR after Spring interop
  • SLAP 1.1
>
>
    • 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
Changed:
<
<
  • PROVDAL 1.0
>
>
  • PROVDAL 1.0
 
    • WD end 2017/early 2018
    • PR before spring interop
Changed:
<
<
  • PROVTAP 1.0
>
>
  • PROVTAP 1.0
 
    • WD end 2017/early 2018
    • reference implementation to be worked out for Spring interop
Changed:
<
<
>
>
 
    • DAL chair note to be published early december
    • Endorsed note early 2018 ?
Changed:
<
<
>
>
 
    • DAL chair and co-chair note end 2017
    • Follow-up to be coordinated with TDIG and DM WG.
Changed:
<
<
  • 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
>
>
  • 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
 
Deleted:
<
<
 

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

Added:
>
>
  • 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.
 
Added:
>
>
  • 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

Education

Knowledge Discovery

Operations

Changed:
<
<
Monitoring activities at VO-Paris, ESA and the HEASARC will continue, though efforts will be somewhat lessened at the HEASARC.
>
>
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


<--  
-->

Revision 42017-11-13 - FrancoisBonnarel

 
META TOPICPARENT name="IvoaTCG"

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

Data Access Layer

Added:
>
>
  • 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

Semantics

Data Curation & Preservation

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


<--  
-->

Revision 32017-10-29 - TomMcGlynn

 
META TOPICPARENT name="IvoaTCG"

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

Data Access Layer

Data Model

Grid and Web Services

Changed:
<
<
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.
>
>
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.
 
Changed:
<
<
  • VOSpace 2.1
>
>
  • 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)
Changed:
<
<
  • Complete KDD/GWS Machine Learning experiment for code-to-data
    • more needed! (see below)
>
>
  • Complete KDD/GWS Machine Learning experiment for code-to-data
    • more needed! (see below)
 
  • Group Membership Service Working Draft
Changed:
<
<
  • Contributors needed for:
>
>
  • Contributors needed for:
 
    • Interoperable code-to-data prototypes
Changed:
<
<
    • Recommendation for Federated Authentication — An IVOA recommendation on how to integrate with federated authentication systems
>
>
    • 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?
Changed:
<
<
  • If time permits:
>
>
  • If time permits:
 
    • Note on the proper pattern of making VO Service calls

Registry

Semantics

Data Curation & Preservation

Education

Knowledge Discovery

Operations

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


<--  
-->

Revision 22017-10-29 - BrianMajor

 
META TOPICPARENT name="IvoaTCG"

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

Data Access Layer

Data Model

Grid and Web Services

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

Semantics

Data Curation & Preservation

Education

Knowledge Discovery

Operations

Theory

Time Domain

Standard and Processes

Science Priorities

Deleted:
<
<

 
<--  
-->
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback