Dear all,
If you want to have a look to the Characterization schema already adressed in the characterisation Working draft it will be possible on Monday in the XML schema section of IVOA documents.
We revisited our schema since Moscow, complementing the documentation inside the schema document and taking carefull look once again to STC features reuse. The Examples document has been validated using xmlspy 2005 release and STC August 2006 version.
We also revisited Arnold's mail of last September, where he proposed to reuse high level STC structures like ObsDataLocation and ObservationLocation to implement the Characterisation schema. We think the necessary linkage between fondamental Stc bricks, as I already answered late September ,is actually present in our characterisation schema.
But anyway, to complement this discussion , we tried to build an example
where we should be
able to reuse something at the level of stc ObsDataLocation, which may
be usefull for collaborative work between Char based applications and pure Stc
based ones .
This example can be seen at the following URL
http://alinda.u-strasbg.fr/Model/Characterisation/examples/Char-STC.xml
Discussion:
ObsDataLocation is the gathering of one ObservatoryLocation ,one ObservationLocation and one PixelLocation
1 ) We actually do not need the PixelLocation in Characterization =20
, because
we consider the data as much calibrated as possible. In any case when the
data are calibrated we do not describe the mapping. This description=20
should be part of "Provenance", in the future I think , or a more complex
characterisation model....
2 ) ObservatoryLocation will be generally borrowed from an STC library
3 ) So the only part to consider in more detail is "ObservationLocatio= n"
ObservationLocation gathers (several) AstroCoordSys, (several) AstroCoo=
rds
and (several) AstroCoordArea. Lack of any of them is also allowed.
Characterization distinguishes Bounds and Support, and this distinction is really fundamental for the semantics of the model.
So what we would actually need is to define a restriction of
ObservationLocation with a sequence of two AstroCoordArea (one for=20
the Bounds,
and the other one for the Support),
Now we should need also to describe sensitivity at the same level (her=
e
and not in AstroCoordArea, as Arnold suggested, because AstroCoordArea
is always defining "contours" on the sky, but cannot describe maps
-that is values everywhere inside the contour- which sensitivity
is supposed to be doing.)
So derivating a new type from ObservationLocation by restriction +=20
extension
to add this sensitivity we obtain a new type which we can call=20
ObservationCoverage,
because I think it's Arnold's view on what a coverage is.
4 ) Using this modified version, I tried to figure out what a=20
Characterization
axis first xml document will look like, and I obtained the=20
example shown on the alinda site, where:
5 ) This is of course only a partial work, just to show what it=20 would look like
a ) in the example I have no Support and Sensitivity at=20 the moment
b ) no ObsDataLocation solution is proposed for Resolution, Accuracy and Sampling which remains exatly implemented like in the original=20 characterisation!!!
I think it could be an alternative implementation if people prefer, but
in order to reuse ObsDataLocation features in the characterization=20
context I would prefer
to develop a software conversion routine, which I could describe if=20
people are eager to examine that
François Bonnarel
PS: Thanks to Mireille for commenting
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-10-29Z10:25:48