SIA Evolution Proposal
Alberto Micol
Alberto.Micol at eso.org
Fri Apr 16 04:02:24 PDT 2004
Dear Pedro,
>In our view, the CDS proposal using the current DTD allows for the
>inclusion of several "parallel" <RESOURCE> elements with metadata
>descriptions, but in the end does not solve the "structurization"
>problem, as the results keep on being somehow flat. Parallel (i.e., same
>level) <RESOURCE>s can not allow for structure inside. The CDS proposal
>gives a <RESOURCE> of type "Results" and several others at the same
>level. This is due to the fact that to allow for the inclusion of real
>data inside the resource (i.e., to allow for structure), the resource's
>TABLE _should_ allow to include inside it another RESOURCE (or another
>TABLE, as we propose).
As said, the previous CDS proposal included nested resources
and that allowed more structure. I hope Francois will comment on that.
But have you considered such option of nesting resourcing instead of tables?
I find that cleaner ...
>> Alberto wrote:
>>
>>The example by Pedro and Jesus shows a single record; but suppose that
>>multiple records (say 4) are returned, and suppose that 2 observations
>>were taken in energy band A and 2 observations were taken in energy band
>>B. The same Energy_Band_Table will be seen in two different records for
>>both the A filter and the B cases.
>
>Even when one filter appears in more than one "observation", the
>energyband table is not the same one. The energyband table contained in
>every observation row is the table which contains the different images
>for different filters for this observation. As the image for filter A
>for obs 0011020 is different than the image for filter A for obs 0011021
>there is no redundancy.
OK, I misunderstood your example.
Let me reformulate my concern using my own example:
Suppose that, along with giving access to all the observations resulting from
a SIA query, I want to provide Filter information (eg min and max wavelength of the filter).
Suppose that among all the N observations there are M observations
taken with the same filter (eg, F606W).
Obviously I do not want to repeat the same min and max wavelength for each of
the observations taken with the same filter.
How would you see this implemented in your scheme?
Regarding the grouping problem that you mentioned:
>How does the client "group" (and this is the key word we believe) the
>information coming from different projects, if we do not know _what_
>each of the resource tables inside it is describing?
I would say that the "type" attribute of a RESOURCE could be used for that,
in the "nested resources" model.
Again, I will ask Francois et al.(CDS) to comment on this.
Alberto
More information about the dm
mailing list