Comments on Spectrum Data Model 0.9

[Francois Bonnarel]

 Dear Marcus, dear dal-people,
In answer to your mail of Sept the 29th

<> 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.
<
<Nope.
<PARAM elements are a shortcut for table columns which contain only a 
<single distinct value in all cells. In practice all PARAM elements could 
<become columns.
<
<In the given example most attributes are given as PARAM elements rather 
<than FIELDs, since otherwise it would be a very wide table, and 
<therefore impracticle for a human reader of the document. In practice 
<when a software client consumes the data this will be different, of course.

Now That I had the opportunity to discuss orally with you last week:
(and also with Pedro Osuna)
I must say that I understand better where we differ. 
The VOTABLE serialization you were proposing is intended , lets'say
for the RETRIEVAL method of SSA and not for the QUERY response.

I always believed  that the Query response could also be based on
the data model and some Data Model --> VOTABLE translation rules.
It is because I had the SSA Query reponse in mind that I thought 
that most of the PARAMS should be allowed to become FIELDS
If I understand well my recent discussions with Doug (by email),
I think this also our roadmap for SIA1.1: How do we go from
ivoa:OBservation/characterization data model to a Votable Image
Query Response is a large part of it.
And I consider that although separeted as two different tasks for
the DAL working group, SIA and SSA should not diverge too much.
Currently a draft for some mechanisms of Extensions in SIA is
circulating between Osuna/Salgado, CDS and Doug. 
It will be published on the list as soon as possible, but
I understood it was  urgent to react on SSA now, although
It would have been better for clarity to present the adaptations 
I am proposing in the files referenced here AFTER publication
of the draft.


<
<> 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 
<
<Surely yes.
<There's a sample file on the Wiki which got updated a few days ago:
<http://www.ivoa.net/internal/IVOA/IvoaDAL/ssample1.xml
<
<Cheers,
<Markus
<

I took your example file and adapted it to produce four different
files.
 The two basic ideas are:
    - a) Associations , or one to n relationships in the model are 
translated by either an index/key mechanism using the "ref" Feature
of VOTAble (3 first files), or recursive inclusion of VOTABLE RESOURCES. 
GROUPS are better for aggregation (or one to one relationships)
    - b) Forcing some Organisation of the response VOTABLE helps the 
client software to define immediatly appropriate data structures based 
on the model with appropriate relationships, while keeping the simplicity 
of VOTABLE parsing. 
It allows also some normalisation and avoid redondancy.
It can eventually allow a simple software to use a main table and to
ignore details hidden in extensions.

    1 ) The first file is a possible query response (without "Access 
reference field)
(http://alinda.u-strasbg.fr/SSA/ssaquery1.xml)
based on the Spectrum data model, closer as possible to your example
(http://www.ivoa.net/internal/IVOA/IvoaDAL/ssample1.xml)  where the main 
table is containing the descriptions of the (SED / Target)s metadata, and
where individual segments are placed in an extension table indexed
by the "Target Name" field.  

    2) The second file http://alinda.u-strasbg.fr/SSA/ssaquery2.xml)
is taking into account the debate about what should be in the
main section of the query response, by letting in the main table the 
individual segment metadata.
     Details on the general SED/Target common to (several of) them are  
in an Extension Table, indexed again by the "Target Name".


   3) The third file shows how the mechanism proposed can be extended
up to the retrieval of several full spectra. 
     http://alinda.u-strasbg.fr/SSA/ssample2.xml
    is just the same as 
      http://alinda.u-strasbg.fr/SSA/ssaquery1.xml
     with a "Point" section, where each individual Data table is hooked
to the appropriate segment metadata using the "DataSet ID" FIELD.

   4) the fourth file http://alinda.u-strasbg.fr/SSA/ssample3.xml
is an alternative to the third one using the recursive inclusion of
RESOURCES instead of indexing mechanisms.

I added a few commentary sections in the files to help the 
reader to see the changes. The general SED sections and general
segment metadata are all considered as FIELDS instead of PARAMS
in order to avoid repetitions of PARAM definitions and attributes.    

In conclusion, I think the document should not say that the
VOTABLE serialization it proposes is the unique way to 
serialize a data model, (the document serialization  is more adapted to 
the Retrieval case actually) and should let open other 
serializations more adapated to the Query Response case .

Best 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
---------------------------------------------------------------------