Dear all,
I will not speak about the Spectrum/SOAP compatibility problem, although I think we should concentrate on the model itself and may allow several implementations, the one proposed in the document being the first proposed solution, but not the only solution probably.
I looked to the spectrum data model and specifically to the utype list from the point of the view of the IVOA char datamodel. I think there is quite good agreement although I think there a couples of points to be quoted.
The main structural point is the lack of sampling". For me it is only apparent because, actually the SpectrumAxis.accuracy contains the BinSize.
But isn't this Spectrum.Char.SpectralAxis.Accuracy.BinSize the mean sampling Extent/Period ?
Other point Spectrum.Char.SpectralAxis.Accuracy.StatErr is distinguished from Spectrum.Char.SpectralAxis.Accuracy.StatErrLow at the same level, while in char StatErr (and SysErr) are containers containig a RefVal, and bounds.
There a few minor vocabulary points, but it is just a mapping issue I think:
eg : Spectrum.Char.SpatialAxis.Location.value is
Characterization.SpatialAxis.Location.coord in char because "coord" is actually implemented with stc type AstroCoordType.
Otherwise, it looks in quite good agreement as far as I saw *
Other matter the VOTABLE serialisation issues:
I think organising every relationships with embedded GROUPS is
little bit too much. It's fine for aggregations/compositions but not for simple associations (specially 1 to n) where two different tables "associated" by a common index FIELD are a solution with more flexibility.
See you soon in Moscow
Regards
François
Francois Bonnarel Observatoire Astronomique de Strasbourg CDS (Centre de donnees 11, rue de l'Universiteastronomiques de Strasbourg) F--67000 Strasbourg (France)
Tel: +33-(0)3 90 24 24 11 WWW: http://cdsweb.u-strasbg.fr/people/fb.html Fax: +33-(0)3 90 24 24 25 E-mail: bonnarel-at-astro.u-strasbg.fr ---------------------------------------------------------------------Received on 2006-09-16Z00:56:50