SIA Evolution Proposal

[Doug Tody]

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