Comments on Spectrum Data Model 0.9

[Francois Bonnarel]

Here are some comments on the Spectrum data model
I hope it'not too late, because this document has been 
presented in Pune allready, but the documents says 
remarks are due for October 1st!

I am not really competent in spectra, that's the reason why I give only
general purpose remarks, as a participant to DAL and DM working groups.
Detail remark:
    In section 5.5 Data Identification Model the table "Packaging Fields" should be
named "Data Identification fields". The Packaging section itself is described later
in the text.  The same misnaming occurs also in the xml schema at the end of the draft.

The main point I have about this draft is about the VOTable serialization.
Actually I think the proposed Serialization is not exactly adapted to an
SED with several segments (and therefore several data tables)
It is also not adapted to the metadata description of several SED, which
is actually something we need under SSA at the data discovery / data retrieval 
level (like in SIAP 1.0 and the proto SSA developped for the AVO 2nd demo).
The draft  proposal will work of course with an SED with one single segment, 
which may be the scope of the document.
The reason for that limitation is obviously coming from  mapping the model 
attributes/xml elements to PARAMS, and not to FIELDS in a (VO) TABLE.

   But if we think to generalize (page 22) a more general mapping from a model
(classes, associations, aggregations) or its xschema representations and 
VOTABLE, the basic assumption is that a class (an xml type/element) is a table.
Each lower level attribute/element of a class/element  is a VOTABLE FIELD
Each instance of a class (a complex element) can then be a row in the table.
aggregations are indeed well represented by groups of FIELDS
Links between rows in different tables (model associations or composition)
can be represented by using index columns and reference mechanisms
or by using the recurrent definition of the RESOURCE eelemnt in VOTABLE.
Using PARAMS can be seen as a specific implementation when dealing with
single objects.
The table SPECTRUM itself should have a less specific managment than in the draft
in that case. It is only one class among others.
Such a generalization could address some of the concerns made by Anita Richards
in her mail of  September 21st

   Mireille Louys and I wrote an IVOA note about principles to map a data model
in VOTABle (Document ID: ModelVOTSer-20040522). The reader can infer what can
happen if we start from the xshema representation instead of the UML one.
We used these principles for the IDHA format in the AVO and Aladin metadatrees.
Some of these rules are also underlying the proposal made by T.Boch,  P.fernique,
M.Louys, P.Osuna , J.Salgado and myself for SIA Extesnsions.

If the authors of the draft are interested I can send a slightly modified version of the
proposed VOTABLE serialisation, which I think is more general 

Regards
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel at astro.u-strasbg.fr
---------------------------------------------------------------------