Laurent Michel

The speaker's profile picture


Engineer at the Observatory of Strasbourg - France
- Chair of the data model working group in the IVOA
- Local manager for the XMM-Newton survey science center
- Manager of the ground software of the MXT camera of the SVOM mission

Profile Picture adass-xxxi-2021/question_uploads/IMG_0447_2aUfOuD.jpg Affiliation

Astronomical Observatory of Strasbourg


Computer Ingeneer


GitHub ID


Postal address

Laurent Michel
Observatoire Astronomique
11 Rue de l'Universite
67000 Strasbourg


TAP and the Data Models
Laurent Michel, Mireille Louys, Dave Morris, Bonnarel François

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 .

Grand Ballroom
Annotating TAP responses on-the-fly against an IVOA data model
Laurent Michel, Mireille Louys, Bonnarel François

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.



(3) In development at

Object Oriented Data Model strategy in the context of IVOA Table Access Protocol services
Laurent Michel, Mireille Louys, Bonnarel François

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