SIA Evolution proposal

[Alberto Micol]

Just a very brief summary,  a question to Pedro and Jesus (VILSPA),
and, for "par condicio", a question to Thomas, Francois and Mireille (CDS),
on the SIA evolution proposals:

http://www.ivoa.net/forum/dal/0145.htm (VILSPA)
http://www.ivoa.net/forum/dal/0150.htm (CDS)

Both proposals manifest the same requirement: the need
to provide enhanced metadata to a user of a S?A service (being it a SIA, 
SSA, etc).

The different is in the implementation, whereby:

 - VILSPA uses VOTable "nested tables"

 - CDS, which used VOTable "nested resources" in a previous version,
   in the last proposal simply uses a second GeneralFeatures resource
   parallel to the "main" resource (the one containing the S?A results).
   Such resource contains as many tables as needed to describe properties
   that otherwise would get repeated (eg filter descriptions, telescope 
location, etc).
   Very much like one would design his/her relational database.

   NOTE: In the CDS document that processed is labeled "factorisation",
   which is probably coming from some french translation, I would call 
it "normalization"
   (from the relational word), but I'm italian ...

The VILSPA proposal will require a modification of the VOTable schema
to allow TABLE as a possible datatype for a FIELD element.

CDS does not require any change, and indeed is already used by various 
data providers.

What is not clear to me, in the VILSPA proposal, how to avoid 
unnecessary repetitions.
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.

In the CDS case that is done by putting all the Energy_Band (filter in 
the cds case) definitions
into a single filter table in the GeneralFeatures resource, and by 
referring to it.
(btw, the link should not be done on the filtername, but on a filter 
identifier instead,
since the same filter name could be used by two different instruments 
(see F555W for
both WFPC2 and ACS)).

Pedro or Jesus, could you please clarify that?


What is also not clear is how, with the new proposed CDS structure, one
could describe multiple members of observations. In the previous IDHA 
version
that was achieved with "nested resources"; but now?

Francois et al., could you please clarify that?


A side comment more for the VOTable WG:
 I like the capability of nesting tables; that would allow a one to one 
mapping between
some special FITS file and VOTable. The HST/STIS  extracted spectra are 
organised
in nested tables (a table cell contains a spectrum) indeed!

Thanks,

Alberto