SIA Evolution Proposal

[Francois Bonnarel]

Dear All,
    I try to comment or answer to all the mails sent in reply to SIA Evolution proposal since Thursday.
This will probably not be complete, but anyway.
I start by the end (nearly, because I will  adress Martin's one only on Monday)  
Pedro and Jesus:
--------------------------------------------------------------------------------------------------------------------------
If the IVOA decides not to put any hierarchy in the SIAP results, fine 
for us. It seemed, however, logical to us to evolve the SIAP in the 
direction of the Data Model. 
....
Again, if the question is "should we put structure in SIAP results?" 
then it is not us who should answer neither do we claim to be in the 
position to impose a specific way to follow
-------------------------------------------------------------------------------------------------------------------------------
No, Pedro I don't think anybody here (apart from Clive, maybe: I will answer to this later if necessary)
 is refusing to put structure in SIA or whatever IVOA DAL protocol. Even Doug if I remember well
some long discussions I had with him does'nt refuse some structuration. And he concludes:
------------------------------------------------------------------------------------------------------------------------------------
This is not to say that we can't map a data model into the fields of 
a table. Any catalog of any complexity is probably already doing this. 
Just that we don't want to map a complex structured object into a single 
field of a table. 
----------------------------------------------------------------------------------------------------------------------------------------
The problem is to find the best way to do it. To clarify for other readers than the current protagonists,
I recall that they are three notes from CDS: A general one called "data model serialisation in VOTable"
(see this discussion list)
which explains very basic rules to structure a VOTable document according to a given datamodel.
These rules have been applied for the AVO demo metadatree since 2002, using the IDHA model, in the
 format we call "IDHA format" (ref in the previous note). THis format is hierarchical, using nested
 RESOURCES. The "SIA Evolution proposal" we are discussing here is also based on the same set of
 rules, and allows to build STRUCTURED documents but  they are not HIERARCHICAL. 
The main reason for doing this step "backwards" (would say some of you) was to try to take into
account the remarks made by Doug and confirmed by Alberto:
----------------------------------------------------------------------------------------------------------------------------------------
The problem with an explicit hierarchy is that you have to pick one. 
There are always multiple ways to visualize the same data. It is 
better to have a flat collection of data elements, and put the suggested 
hierarchy in some sort of "view" element. This also makes it easier for 
generic tools which don't care about the hierarchy to navigate the data. 

That is, it is the client that should decide 
> how to represent the data; the default might be the "data provider way", 
> but it shall be possible for the user to group things in a different way. 
> Some user might want to group by waveband, some other by field of view, 
> some other by limiting magnitude, etc. It depends very much on the science 
> s/he has in mind. 
> 
------------------------------------------------------------------------------------------
In our "SIA Evolution proposal" where is the structure coming from ? Answer: from the references: 
references  from FIELDS to FIELDS ID for associations and references from FIELDS to TABLES ID for 
composition (The "Packaging" Table referenced in the "acref" field of our example is of this kind)
 And this is the key of the solution of the CDS/VILSPA debate I think: Pedro and Jesus if you use
 references to tables in the "complex fields" instead of  nested tables you achieve the same result,
I guess. I will try to rewrite your example next Monday, using this idea, which do not requires any 
change to the VOTable DTD.
BTW, Alberto this is also the answer to this question:
------------------------------------------------------------------------------------------------------------------------------
What is also not clear is how, with the new proposed CDS structure, one 
could describe multiple members of observations. In the previous IDHA 
version 
that was achieved with "nested resources"; but now? 
-------------------------------------------------------------------------------------------------------------------------
In the packaging we can have a field referencing to a table of subobservations ( These two
tables probably have to be grouped in the same RESOURCE in that case.)
 
One last answer to Alberto:
-------------------------------------------------------------------------------------------------------------------------------
I would say that the "type" attribute of a RESOURCE could be used for that, 
in the "nested resources" model. 
----------------------------------------------------------------------------
Yes Alberto: "type" (or "name") of RESOURCES are the good attributes
to use to tell which kind of data we have there. Because you can repeat 
as many RESOURCES you want like that in the document, as if it were
different instances of the same class.

Regards to all
François   
SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

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