| |
 |
| Paper: |
Object Oriented Data Model Strategy in the Context of IVOA Table Access Protocol Services |
| Volume: |
535, Astronomical Data Analysis Software and Systems XXXI |
| Page: |
307 |
| Authors: |
Bonnarel, F.; Louys, M.; Michel, L. |
| Abstract: |
The Table Access Protocol is a universal access standard for astronomical relational databases. The 127 TAP services registered in the IVOA registry, currently expose more than 22000 tables. It makes use of an astronomical query language, derived from SQL and 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 query responses in single-table VOTables. They extract data from the database following the structure given in the TAP_SCHEMA but provide only the selected columns. The elements queried in astronomical archives deal with photometry, coordinates, measurements, transformations, provenance and complex associations between 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) contains one single table. Thus, in practice, we are facing several issues in generating complex queries on one side, and in interpretation of the response on the other side. The poster will review different options which have been experimented or considered by the IVOA DM working group in order to connect TAP responses (tables) with DMs instances (sub-graphs). The solutions may 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 describe four possible solutions with examples: 1) 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; 2) On the fly table annotation in VOTable documents with a specific data-model-mapping syntax currently under development; 3) 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; 4) Actual data model instance retrieval by new extensions of ADQL. The poster also shows how the TAP specification can be completed to ensure the schema contains the metadata required to build table annotations, or a normalized view. |
|
|
|
|
|
