The International Virtual Observatory Alliance (IVOA) held its bi-annual Interoperability Meetings in May 2019, and in October 2019 following the ADASS XXIX conference. We provide a brief report on the status of the IVOA and the activities of the Interoperability Meetings.

The International Virtual Observatory Alliance (IVOA) held its bi-annual Interoperability Meeting over two and half days prior to the ADASS 2018 conference. We provide a brief report on the status of the IVOA and the activities of the Interoperability Meeting held in College Park.

Handling, processing and archiving the huge amount of data produced by the new generation of experiments and instruments in Astronomy and Astrophysics are among the more exciting challenges to address in designing the future data management infrastructures and computing services. We investigated the feasibility of a data management and computation infrastructure, available world-wide, with the aim of merging the FAIR (Findable, Accessible, Interoperable, Reusable) data management provided by IVOA standards with the efficiency and reliability of a cloud approach. Our work involved the Canadian Advanced Network for Astronomy Research (CANFAR) infrastructure and the European EGI federated cloud (EFC). We designed and deployed a pilot data management and computation infrastructure that provides IVOA-compliant VOSpace storage resources and wide access to interoperable federated clouds. In this paper, we detail the main user requirements covered, the technical choices and the implemented solutions and we describe the resulting Hybrid cloud Worldwide infrastructure, its benefits and limitations.

A joint project between the Canadian Astronomy Data Center of the National Research Council Canada, and the italian Istituto Nazionale di Astrofisica-Osservatorio Astronomico di Trieste (INAF-OATs), partially funded by the EGI-Engage H2020 European Project, is devoted to deploy an integrated infrastructure, based on the International Virtual Observatory Alliance (IVOA) standards, to access and exploit astronomical data. Currently CADC-CANFAR provides scientists with an access, storage and computation facility, based on software libraries implementing a set of standards developed by the International Virtual Observatory Alliance (IVOA). The deployment of a twin infrastructure, basically built on the same open source software libraries, has been started at INAF-OATs. This new infrastructure now provides users with an Access Control Service and a Storage Service. The final goal of the ongoing project is to build an integrated infrastructure geographycally distributed providing complete interoperability, both in users access control and data sharing. This paper describes the target infrastructure, the main user requirements covered, the technical choices and the implemented solutions.

The increase of astronomical data produced by a new generation of observational tools poses the need to distribute data and to bring computation close to the data. Trying to answer this need, we set up a federated data and computing infrastructure involving an international cloud facility, EGI federated, and a set of services implementing IVOA standards and recommendations for authentication, data sharing and resource access. In this paper we describe technical problems faced, specifically we show the designing, technological and architectural solutions adopted. We depict our technological overall solution to bring data close to computation resources. Besides the adopted solutions, we propose some points for an open discussion on authentication and authorization mechanisms.

This document describes the Server-side Operations for Data Access (SODA) web service capability. SODA is a low-level data access capability or server side data processing that can act upon the data files, performing various kinds of operations: filtering/subsection, transformations, pixel operations, and applying functions to the data.

The IVOA Data Access Layer (DAL) working group was created in 2002 to define protocols to homogenize data discovery, data description, data retrieval, and data access processes. We describe its history and status today, and look at current trends for future development of the DAL protocols.

The Simple Image Access protocol (SIA) provides capabilities for the discovery, description, access, and retrieval of multi-dimensional image datasets, including 2-D images as well as datacubes of three or more dimensions. SIA data discovery is based on the ObsCore Data Model (ObsCoreDM), which primarily describes data products by the physical axes (spatial, spectral, time, and polarization). Image datasets with dimension greater than 2 are often referred to as datacubes, cube or image cube datasets and may be considered examples of hypercube or n-cube data. In this document the term "image" refers to general multi-dimensional datasets and is synonymous with these other terms unless the image dimensionality is otherwise specified. SIA provides capabilities for image discovery and access. Data discovery and metadata access (using ObsCoreDM) are defined here. The capabilities for drilling down to data files (and related resources) and services for remote access are defined elsewhere, but SIA also allows for direct access to retrieval.

This document describes the linking of data discovery metadata to access to the data itself, further detailed metadata, related resources, and to services that perform operations on the data. The web service capability supports a drill-down into the details of a specific dataset and provides a set of links to the dataset file(s) and related resources. This specification also includes a VOTable-specific method of providing descriptions of one or more services and their input(s), usually using parameter values from elsewhere in the VOTable document. Providers are able to describe services that are relevant to the records (usually datasets with identifiers) by including service descriptors in a result document.

VOSpace is the IVOA interface to distributed storage. This specification presents the first RESTful version of the interface, which is functionally equivalent to the SOAP-based VOSpace 1.1 specification. Note that all prior VOSpace clients will not work with this new version of the interface.

We present, as a case study, a description of the partnership between an observatory (JCMT) and a data centre (CADC) that led to the development of the JCMT Science Archive (JSA). The JSA is a successful example of a service designed to use Virtual Observatory (VO) technologies from the start. We describe the motivation, process and lessons learned from this approach.

This document describes an XML encoding standard for metadata about services implementing the table access protocol TAP [TAP], referred to as TAPRegExt. Instance documents are part of the service's registry record or can be obtained from the service itself. They deliver information to both humans and software on the languages, output formats, and upload methods supported by the service, as well as data models implemented by the exposed tables, optional language features, and certain limits enforced by the service.

This document describes the Data Access Layer Interface (DALI). DALI defines the base web service interface common to all Data Access Layer (DAL) services. This standard defines the behaviour of common resources, the meaning and use of common parameters, success and error responses, and DAL service registration. The goal of this specification is to define the common elements that are shared across DAL services in order to foster consistency across concrete DAL service specifications and to enable standard re-usable client and service implementations and libraries to be written and widely adopted.

This document defines the core components of the Observation data model that are necessary to perform data discovery when querying data centers for observations of interest. It exposes use-cases to be carried out, explains the model and provides guidelines for its implementation as a data access service based on the Table Access Protocol (TAP). It aims at providing a simple model easy to understand and to implement by data providers that wish to publish their data into the Virtual Observatory. This interface integrates data modeling and data access aspects in a single service and is named ObsTAP. It will be referenced as such in the IVOA registries. There will be a separate document to cover the full Observation data model. In this document, the Observation Data Model Core Components (ObsCoreDM) defines the core components of queryable metadata required for global discovery of observational data. It is meant to allow a single query to be posed to TAP services at multiple sites to perform global data discovery without having to understand the details of the services present at each site. It defines a minimal set of basic metadata and thus allows for a reasonable cost of implementation by data providers. The combination of the ObsCoreDM with TAP is referred to as an ObsTAP service. As with most of the VO Data Models, ObsCoreDM makes use of STC, Utypes, Units and UCDs. The ObsCoreDM can be serialized as a VOTable. ObsCoreDM can make reference to more complete data models such as ObsProvDM (the Observation Provenance Data Model, to come), Characterisation DM, Spectrum DM or Simple Spectral Line Data Model (SSLDM).

VODataService refers to an XML encoding standard for a specialized extension of the IVOA Resource Metadata that is useful for describing data collections and the services that access them. It is defined as an extension of the core resource metadata encoding standard known as VOResource [Plante et al. 2008] using XML Schema. The specialized resource types defined by the VODataService schema allow one to describe how the data underlying the resource cover the sky as well as cover frequency and time. This coverage description leverages heavily the Space-Time Coordinates (STC) standard schema [Rots 2007]. VODataService also enables detailed descriptions of tables that includes information useful to the discovery of tabular data. It is intended that the VODataService data types will be particularly useful in describing services that support standard IVOA service protocols.

This document describes the Astronomical Data Query Language (ADQL). ADQL has been developed based on SQL92. This document describes the subset of the SQL grammar supported by ADQL. Special restrictions and extensions to SQL92 have been defined in order to support generic and astronomy specific operations.

The table access protocol (TAP) defines a service protocol for accessing general table data, including astronomical catalogs as well as general database tables. Access is provided for both database and table metadata as well as for actual table data. This version of the protocol includes support for multiple query languages, including queries specified using the Astronomical Data Query Language (ADQL [1]) and the Parameterised Query Language (PQL, under development) within an integrated interface. It also includes support for both synchronous and asynchronous queries. Special support is provided for spatially indexed queries using the spatial extensions in ADQL. A multi-position query capability permits queries against an arbitrarily large list of astronomical targets, providing a simple spatial cross-matching capability. More sophisticated distributed cross-matching capabilities are possible by orchestrating a distributed query across multiple TAP services.

Seventy-two grids of stellar evolutionary tracks, along with the capability to generate isochrones and luminosity/color functions from them, are presented in this investigation. Sixty of them extend (and encompass) the sets of models reported by VandenBerg et al. (2000, ApJ, 532, 430) for 17 [Fe/H] values from -2.31 to -0.30 and alpha-element abundances corresponding to [alpha/Fe] = 0.0, 0.3, and 0.6 (at each iron abundance) to the solar metallicity and to sufficiently high masses (up to ~2.2 solar masses) that isochrones may be computed for ages as low as 1 Gyr. The remaining grids contain tracks for masses from 0.4 to 4.0 solar masses and 12 [Fe/H] values between -0.60 and +0.49 (assuming solar metal-to-hydrogen number abundance ratios): in this case, isochrones may be calculated down to ~0.2 Gyr. The extent of convective core overshooting has been modelled using a parameterized version of the Roxburgh (1989, A&A, 211, 361) criterion, in which the value of the free parameter at a given mass and its dependence on mass have been determined from analyses of binary star data and observed color-magnitude diagrams for several open clusters. Because the calculations reported herein satisfy many empirical constraints, they should provide useful probes into the properties of both simple and complex stellar populations. [All of the model grids may be obtained from the Canadian Astronomy Data Center (http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/cvo/community/VictoriaReginaModels ).]