Recently the International Virtual Observatory Alliance (IVOA) released a standard to structure provenance metadata, and several implementations are in development in order to capture, store, access and visualize the provenance of astronomy data prod
ucts. This BoF will be focused on practical needs for provenance in astronomy. A growing number of projects express the requirement to propose FAIR data (Findable, Accessible, Interoperable and Reusable) and thus manage provenance information to ensure the quality, reliability and trustworthiness of this data. The concepts are in place, but now, applied specifications and practical tools are needed to answer concrete use cases. During this session we discussed which strategies are considered by projects (observatories or data providers) to capture provenance in their context and how a end-user might query the provenance information to enhance her/his data selection and retrieval. The objective was to identify the development of tools and formats now needed to make provenance more practical needed to increase provenance take-up in the astronomical domain.
We present the last developments on the IVOA Provenance data model, mainly based on the W3C PROV concept. In the context of the Cherenkov astronomy, the data processing stages imply both assumptions and comparison to dedicated simulations. As a conse
quence, Provenance information is crucial to the end user in order to interpret the high level data products. The Cherenkov Telescope Array (CTA), currently in preparation, is thus a perfect test case for the development of an IVOA standard on Provenance information. We describe general use-cases for the computational Provenance in the CTA production pipeline and explore the proposed W3C notations like PROV-N formats, as well as Provenance access solutions.
The International Virtual Observatory Alliance (IVOA) developed numerous interoperability standards during the last several years. Most of them are quite simple to implement from the technical point of view and even contain SIMPLE in the title. Does
it mean that it is also simple to build a working VO resource using those standards? Yes and no. Yes because the standards are indeed simple, and no because usually one needs to implement a lot more than it was thought in the beginning of the project so the time management of the team becomes difficult. In our presentation we will start with a basic case of a simple spectral data collection. Then we will describe several examples of small technologically advanced VO resources built in CDS and VO-Paris and will show that many standards are hidden from managers eyes at the initial stage of the project development. The projects will be: (1) the GalMer database providing access to the results of numerical simulations of galaxy interactions; (2) the full spectrum fitting service that allows one to extract internal kinematics and stellar populations from spectra of galaxies available in the VO. We conclude that: (a) with the existing set of IVOA standards one can already build very advanced VO-enabled archives and tools useful for scientists; (b) managers have to be very careful when estimating the project development timelines for VO-enabled resources.
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 guid
elines 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).
