SIA Evolution Proposal

[Pedro Osuna]

Ciao Alberto,


with respect to using RESOURCEs inside RESOURCEs (as opposed to TABLES
inside TABLES) it is, in fact, the first option we considered when
looking at how to include IDHA structure in our XMM-Newton data after
the AVO demo.

However, we later realized that the RESOURCEs inside RESOURCEs would
allow for loads of description of metadata, but _not_ for inclusion of
proper hierarchy, as the TABLE data inside a RESOURCE can _not_ contain
another resource (as we said before) (FIELD elements inside TABLE can
_not_ have RESOURCEs inside, neither TABLEs) and therefore, you would
not be able to model any structure below a certain resource.

That's why we proposed the tables inside tables which solves the problem easily.


With respect to your filter example, maybe we are not understanding the problem 
correctly, but the answer for us would be clear: if you have several observations 
in the same filter, in your "display data model" (as we call it) 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".

This "Display Data Model", as we say in our note, does _not_ have to be identical
to your actual Data Model: it only has to reflect the way you want the SIAP results
to be structured. It is up to the Data providers to structure the way they want their
SIAP results to look like.


I hope this helps. Keep on waiting for more.....



Cheers,
P&J


On Fri, 2004-04-16 at 13:02, Alberto Micol wrote: 
> 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
> 

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