Dear Pedro,
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.
>you could model your data as:
>
>results -- Filter -- Observation
>
>instead of
>
>results -- Observation -- Filter
>
>such that you could put:
>
>
>results ---- F6006W ------ Obs 1
> | |----- Obs 2
> | |----- Obs 3
> |---- F8906G ------ Obs 2
> |------ Obs 12
> |------ Obs 5
>
>i.e., you would be "inverting" your display data model.
>
>The description of the Filter, including filter-range, would appear only once in the
>Filter's table "header".
>
I see, so in this case the sw handling the results will find the
wavelengths min and max
in the PARAMs of each Filter table, not in a central place (table) where
all the filter
characteristics are stored as in the CDS proposal.
It looks to me that your model is indeed imposing the data provider view
to the users.
Alberto Received on 2004-04-16Z13:53:26