SIA evolution proposal

[Pedro Osuna]

Dear all,


we have the feeling that the discussion here is more on the line of
whether the SIAP should allow for structure or not. This is not the
point we were addressing in our note.

At the AVO demo, we were asked to include some structure in our SIAP
results, and the note we have sent proposes a solution to include _any_
type of hierarchy (not an explicit one) in them. 

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.

On the other hand, in the examples we are discussing, Alberto wanted to
model different observations for the same filter, and however it seems
to end up asking to _not_ include any hierarchy, as flat structure is
preferred which, in our view, implies repetition. Then, it is the client
who has to be able to _model_ (from a flat table) the structure from a
_not_ known data model. This looks cumbersome to us. 

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.

Cheers,
P&J



On Fri, 2004-04-16 at 16:28, Doug Tody wrote: 
> Hi All -
> 
> On Fri, 16 Apr 2004, Alberto Micol wrote:
> > What I think is important is to keep in mind that the user might want
> > to visualise "S?A" results her one way, regardless of the structure the
> > data provider has in mind.  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 this sense I'm inclined to think that it would be easier for the
> > client to be presented with a flat (and of course) normalised structure
> > to start with.  The hierarchy could then be built on-the-fly according
> > to user requirements.
> 
> Thank you, Alberto for making this point.
> 
> 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.
> The only exception might be if the hierarchy represents some real physical
> structuring of the data.  But then you probably have a structured object,
> ie another data model.
> 
> Tables within tables, or any object more complex than an array within a
> single table cell, are probably a bad idea.  This has been tried before
> in other software and has never been that successful.  In the VO context
> it is simply too complicated and I don't think the software would follow.
> All the advantages of generic table tools go away if tables are no longer
> tables.  Lets keep the table mechanism per se fairly simple, and use it for
> tabular data.  If we need a general container mechanism there are better
> ones than a table, e.g., the RESOURCE elements in VOTable provide a simple
> container mechanism.
> 
> 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.
> 
> 	- Doug

                                              
-- 
Pedro Osuna Alcalaya

 
Software Engineer
VILSPA Archive Development Team
e-mail: Pedro.Osuna at esa.int
Tel + 34 91 8131314
                                                                                
European Space Agency
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN