IVOA Roadmap for 2017A

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




Applications

  • HiPS
    • Usage: Encourage the App members to declare their HiPS servers in VO registry according to the new HiPS standard REC
    • Standard: Nice to have a note on new ideas around HiPS (progenitors, polarized tiles, planeto...)
  • VOTable
    • Usage: Encourage the App members to apply Erratum 1.0 (re-introduce coordinate description asap)
    • Standard: Awaiting VODML VOTable serialization consensus (see DM roadmap)
  • Authentication
    • Continue to discuss on the requirements and impacts on App clients (ex: Aladin VOSpace access...)

Data Access Layer

SCS 1.1 :

  • internal WD for beginning of summer (M.Molinaro)
SLAP 1.1:
  • internal WD for end of September (N.Moreau)
Discussion on the mailing list on « recognizing DataLink outside DAL context »:
  • Summary (F.Bonnarel) ,
  • Decision in Santiago, implementation or endorsed note
ADQL 2.1:
  • ADQL 2.1 WD for July and PR by September (D.Morris)
  • ADQL PEG grammar in ADQL 2.2 draft later (W.Landry, D.Morris)
MOC in TAP (and ADQL):
  • Summary on the DAL future page (G.Mantelet), now
  • MOC prototyping wiki collaboration (D.Morris), now
DAL for Time Series (and other dataproducts types)
  • Create a Task group with TDIG and DM for requirements and design
  • Encourage prototypes development
  • First conclusions by Santiago
TAP 1.1:
  • PR by end of June.

Data Model

VO-DML-1.0

  • REC by end of summer
VO-DML Mapping-1.0
  • WD distributed to working group by early June
  • work example serializations in application, come to working group concensus on syntax, and elements included in 1.0 version
  • PR ready by September
DatasetMetadata-1.0/NDCube-1.0
  • Keep updated to any changes in STC or VO-DML
  • update examples in support of mapping evaluation effort
  • add validation to model capability to example generation script
  • otherwise.. considered ready for PR/RFC upon completion of STC
STC-2.0 (Coords, Meas, Trans)
  • evaluate models using cube example set and mapping syntax
  • fold in working group comments
  • goal is to have a generally accepted working draft, implemented in NDCube/Dataset models and ready for RFC by Santiago
Provenance-1.0
  • generate vo-dml compliant model
Source-1.0
  • no specified goals at this point
Time Domain
  • continue work with TDIG and DAL to gather requirements for supporting time domain data.

Grid and Web Services

Priority 1:

  • Remote Execution (Code to Data) -- The GWS Working Group will make an effort to make progress around the idea of executing code near to the data. We are aiming to have prototypes ready for Santiago. These will allow for a working draft to be developed.
Priority 2:
  • Recommendation for Federated Authentication -- An IVOA recommendation on how to integrate with federated authentications systems and identity providers.
  • Group Membership Service Working Draft -- Continue with the momentum from Shanghai on the mailing list and have a working draft ready by Santiago. Most of the key concepts have been settled.
  • VOSpace 2.1 – RFC period will be extended to allow for more feedback. It is uncertain at this point whether this version will need more work.
Nice to have:
  • Note on how to implement a very simple VOSpace
  • Note on pattern of making VO Service calls
  • Note giving examples on how to use the SecurityMethods described in SSO 2.0

Registry

Registry Interfaces 1.1, which in particular lets RegTAP operators register their services as registries (registration as TAP services with RegTAP data in them, of course, can continue). That, however, builds on the Discovering Dependent Resources note, so that would probably have to be endorsed before RI 1.1 can actually become REC.

VOResource 1.1: Should go to RFC in the next few weeks. We are still soliciting takeup of the new features. To make this more attractive, the RofR will investigate installing the new schema so registries already using new features do not become invalid.

RegTAP 1.1: This puts new VOResource 1.1 features into RegTAP. We have first implementations of a proposed extension of the schema. A working draft should be published July-ish.

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. The central concept here are auxiliary capabilities, essentially saying "this data can be accessed via TAP/SIAP/whatever in a services with the following access URL". There is some takeup of the proposed scheme, and TOPCAT already supports discovery through it. To make it a valid replacement for current workarounds (i.e., GloTS), more takeup is necessary; various registry operators have pledged to work towards it.

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 be kept in lockstep with TAP 1.1.

Maintenance: We will keep making sure the registry system runs; in particular, the anomalies diagnosed by the ESA registry have been diagnosed and, where there is a potential for later functionality problems, will be addressed in the coming months.

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

We intent to build a task force that identifies key activities / challenges to focus on

In addition important knowledge discovery uses cases should be identified and collected to be reported at the next interop meeting. If possible, prototype implementations of services should be developed and presented that cover some of the discussed topics at the Shanghai interop.

Operations

Theory

Work in the "Implemementation Note" for SimDAL.

We intend to describe several implementations, done by different groups, about different types of simulations.

It is expected to have the note finished by Spring, 2018.

Time Domain

Top priority for TDIG is the support the ongoing effort in the DAL and
DM working groups to standardize a data model and discovery & access
mechanisms for time series data within the context of the VO. TDIG
will focus on developing and curating scientific use cases and
engaging with the working groups to assist in developing and
evaluating prototype solutions.

In addition, we will begin to draft a modest revision to the VOEvent
to address non-urgent issues which have arisen over the six years
since VOEvent 2.0 was standardized. This will include clearer
definition of the semantics of the IVOID/IVORN in the context of
VOEvent and more powerful and expressive description of space-time
coordinates (e.g. by integrating STC2).

Finally, we will continue to work with the wider astronomical
community, and in particular major facilities, to assess our longer
term goal of evolving the VOEvent standard and associated
infrastructure to address the needs of future high-volume event
producers.

Standard and Processes

Follow-up of the Document Standards V2.0: real-life adjustment of the standardisation, endorsed notes and errata processes.

Science Priorities

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2018-06-20 - GiuliaIafrate
 
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