Mireille Louys
I have been working in the Data model and Semantics Working groups of the IVOA Virtual Observatory project.
I am assistant professor at Strasbourg University in computer science and image processing, and a collaborator scientist with CDS at Strasbourg Astronomical Observatory.
My research deals with Image processing in astronomy, metadata for open distribution of research data, data models and vocabularies.
Profile Picture – adass-xxxi-2021/question_uploads/MireilleLouys2015_CqnkN1n.jpg Affiliation –
Strasbourg University, ICube &CDS
Position –Assistant Professor
Postal address –Observatoire de Strasbourg , 11 rue de l Université, 67000 STRASBOURG -FRANCE
Sessions
TAP is one of the big achievements of the VO. This protocol gives any relational database a high level of interoperability thanks to several IVOA standards:
- The TAP_SCHEMA : a description of the tables, their columns and the way they can be joined.
- ADQL: a query language, subset of SQL, with some astronomy-specific features
- UWS: a specification for a REST API to be used to handle service requests
These features provide a common way to discover the content of TAP services and to query them.
This works very well with relational data and we propose to investigate the possibility for TAP services to map searched data on data models. Indeed several data models have been developed by IVOA in order to tackle the complexity of the relationships between astronomical data features. Among those we can quote Photometry Data Model, Coordinates, Measurements, Transforms or MANGO that is well suited to describe source properties and relations to some datasets representing these sources. TAP services are able to host complex data bound with joins but the standard still misses important features to serve real model instances:
- A meta-data endpoint telling which models are available per table
- Storage of model meta-data into the TAP_SCHEMA
- Storage of coordinate frames in the TAP service
- Mechanism specifying the model on which the requested data must be mapped
- Mechanism returning multi-table responses for complex objects
- Preservation of model annotations in uploaded tables
The purpose of the BoF is to discuss the relevance of enabling TAP services to deal with Data Models and to refine the functionalities required to implement such a capability.
We will be able to present a proof of concept based on the VOLLT framework that can annotate on the fly query responses on two archive tables using the MANGO data model. Any other contribution and point of view on this topic will be is welcome and helpful to lift up and enrich the debate .
With the success and widespread of the IVOA Table Access Protocol (1) for discovering and querying tabular data in astronomy, about one hundred of TAP services exposing altogether 22 thousands of tables are accessible from the IVOA Registries at the time of writing.
Currently the TAP protocol presents table data and metadata via a TAP_SCHEMA describing the served tables with their columns and possible joins between them.
We explore how to add an information layer, so that values within table columns can be gathered and used to populate instances of objects defined in a selected IVOA data model like Photometry, Coords, Measures, Transform or MANGO. This improves data interoperability by adding a model view common to all services.
This information layer is provided through annotation tags, that are defined by the service which tells how the columns' values can be interpreted as attributes of instances of that model.
Then when a TAP query is processed, our server add-on interprets the ADQL query string and produces on-the-fly, when possible, the TAP response as a VOTABLE document, decorated with the annotation of the object's fields present into the query and corresponding to the model elements templated for this service.
This has been prototyped in Java, using the VOLLT (2) package library and a template annotation document representing elements from the MANGO(3) data model. This has been exercised on examples based on Vizier and Chandra catalogs.
(1) https://www.ivoa.net/documents/TAP/20190927/
(2) https://github.com/gmantele/vollt
(3) In development at https://github.com/ivoa-std/MANGO
Object Oriented Data Model strategy in the context of IVOA Table Access Protocol services
François Bonnarel (CDS, ObAS, CNRS Strasbourg), Mireille Louys (CDS, ICube, Unistra), Laurent Michel (ObAS, CNRS Strasbourg)
Table Access Protocol is an universal access standard for astronomical relational databases . TAP services registered in the IVOA registry, currently expose more than 22 thousands tables.
It makes use of an astronomy extended SQL-like query language called ADQL. The database content is described in a standardized schema called the TAP_SCHEMA. Rich standardized metadata are included in the description.
TAP services build up a query response in one single table. They extract data from the database following the structure given in the TAP_SCHEMA but provide only the selected columns.
Beside this, IVOA developed a set of standardized object-oriented data models allowing a logical description of relationships between various pieces of data or metadata in astronomy.
The elements queried in astronomical archive deal with photometry, coordinates, measurements, transformations, provenance and complex associations of those.
These are described in various IVOA data models, following an Object Oriented strategy: Coords MEAS , Mango etc …. VO-DML is the IVOA recommendation to which IVOA data models should comply in order to be represented in a standard vodml-xml format.
Mapping an object oriented-model in a relational database is a problem theoretically solved under the scope of ORM principles and rules.
However the result of an ADQL query (as would be the case of the underlying SQL one in each specific database) is a single table. So in practice we are facing several issues for generating complex queries on one side, and for interpreation of the response on the other side.
The poster will review different solutions which have been experimented or considered by the IVOA DM WG in order to connect TAP responses (tables) with DMs instances (sub-graphs). The solutions vary according to the actual features of the data model and data structure. They should work when the database is following a predefined data model but also when we try to map a data model on legacy data. We will describe four possible solutions with examples:
- simple flat views built on top of the data model and the data. In that case the TAP schema covers the needs. An example is the ObsCore data model.
- on the fly table annotation In VOTable documents with a specific data model mapping syntax currently under development (ModelInstanceINVotable)
- organization of the ADQL query response as a normalized view with several tables and joins in the same VOTable documents with annotations delivered as quoted above.
- actual data model instance retrieval by new extensions of ADQL
The poster will also show how TAP specification can be completed so that the TAP_SCHEMA contains metadata required to build table annotations or renormalisation
CASSIS and Aladin interfaced for a VO-compliant spectral data cube analysis tool
J.M Glorian, P. Fernique, T.Boch, M.Boiziot, F.Bonnarel, C.Bot, S.Bottinelli, E.Caux, A.Coutens, M.Louys, C.Vastel
Spectral cubes are becoming usual data products in astronomy. This is true in various spectral domains due to the high rate data production of large projects such as MUSE in optical, LOFAR, ALMA, VLA, NOEMA or ASKAP in radio astronomy, or Chandra and XMM in Xray. And this is only a hint of what will happen with the emergence of SKA or other Petascale projects in a near future. These cubes are generally on line and easy to be found and accessed due to the great number of VO services which distribute them. Efficient Display and Analysis of such spectral cubes is a big challenge.
In this context the CASSIS team at IRAP (http://cassis.irap.omp.eu) and the Aladin team at CDS (https://aladin.u-strasbg.fr/) decided to work together on the combination of their VO applications in order to create a tool able to explore both spatial and spectral dimensions of the cubes.
CASSIS is a java tool able to discover spectra in remote services via the SSAP protocol and analyse them. It provides functionalities such as spectrum display, spectral line identification, prediction of spectra from any telescope, comparison of spectra with various models and determination of the physical parameters of the sources.
Aladin is also a java tool able to discover images and cubes and display them (either in standard bitmap format or in the IVOA HiPS format (https://www.ivoa.net/documents/HiPS/) and catalogs available in the Virtual Observatory landscape. It allows transformation, overlays and comparison of data. Data discovery makes use of specific VO features such as MOCs (https://www.ivoa.net/documents/MOC/20210324/index.html) both in spatial and time dimension.
The focus demo will show how the two Desktop applications have been extended by a common dedicated interface in such a way that they behave together like a spectral cube analysis tool. For example CASSIS can analyse a spectrum built on the fly by Aladin after hand selection and combination of voxels in a specific area of a spectral cube. Reversely CASSIS allows to select spectral ranges on such spectra and ask Aladin to display 2D images combining the corresponding spectral planes in the cube.
The tool can work both on local data available on the user's disk or on cubes discovered via the VO registry and within VO services. We will demonstrate both modes.
More sophisticated developments will occur in the future and will be announced at the end of the demo.