DM in VizieR

[gilles landais]

Concerning the recent draft of VOTable that includes DM mapping element 
in the schema.
I'm in charge of the VizieR technical part and i would like to give you 
the advantages and the difficulties to provide DM as metadata in the 
VizieR context.
I will not talk about the technicals issues for the DM mapping in 
VOTable (nevertheless, my point of view is that more the format is 
readable, easier it will be to provide).

Before talking, i draw your attention that in a data center we make the 
difference between the data in Entry ingested in the Information System 
and which is given by the creator and the data that we provide (query 
response): both could be in VOTable.


1- Building up DM mapping compliant serialization output from a data 
center services
Today in VizieR, positions are systematically (when they are known) 
completed with equinox, coordinate System, epoch, errors, proper 
motions.  COOSYS are used today in the VOTable with their limitations 
(one single occurence per document for example).
Photometry is assigned for each new catalogue: an important effort was 
made to find the needed informations for some old catalogues (a part of 
them only is done).
DM mapping in VOTABLE could be an opportunity to add STC DM and 
photometry DM metainformation for VizieR catalogues. Currently the 
photometry output in VizieR used the VO working draft : "Photometry DM 
v1.0" : this format is well suited.

To build this capability needs to mapp available informations (with 
their current database representation) to the IVOA DM representation.
This kind of mapping needs that DM keywords are not mandatory, because 
the corresponding DM elements are not necessarily known in my system:
- metadata are the result of the documentalists work and depend of the 
informations available in the original resources
- it is impossible to make a mapping from currently existing metadata: 
UCD assigned in VizieR for each columns of tables and other metadata 
like type or titles are not enought to map with datamodels.
So, each mandatory informations to be added needs 
documentlists/astronomers expertise because the mapping can't be done 
automatically. It increases the maintenance of the database population.
The DM which can evolve over the time is to take also into consideration.

2- To provide resources in entry (given by creator) containing DM 
information.
That is, i think, what we expect.
In the VizieR context, it means to provide the original format (by FTP, 
SSA, ...) having embedded DM information. It needs pipelines, used by 
the data producers to integrate DM information at source: a nice 
perpective for VizieR.

However, in the context or preservation ; to provide resources (the 
original VOTable in Entry) needs format compatible with current softwares.
And so we should to adapt/migrate the original format archived with the 
different versions of DM when they become obsolete.

3- To provide resources in VOTable
VizieR provides results from queries in VOTable using TAP for example. 
In some case, depending of the query, it will be difficult/inapropriate 
to provide DM in the VOTable output:
- The result can be the result of a crossmatch, a subset a union or a 
join of differents tables coming from differents pipelines (and so, 
using different DM).
- In a subset, the result could miss some columns which are required by 
a DM.
I think that provinding DM in output is more adapted for the full 
resources than data which results from queries.