Characterisation Working Draft submitted as IVOA document
bonnarel at alinda.u-strasbg.fr
Sun Oct 29 01:20:27 PST 2006
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
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
ObsDataLocation is the gathering of one ObservatoryLocation ,one
ObservationLocation and one PixelLocation
1 ) We actually do not need the PixelLocation in Characterization =20
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
2 ) ObservatoryLocation will be generally borrowed from an STC library
3 ) So the only part to consider in more detail is "ObservationLocatio=
ObservationLocation gathers (several) AstroCoordSys, (several) AstroCoo=
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
and the other one for the Support),
Now we should need also to describe sensitivity at the same level (her=
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
to add this sensitivity we obtain a new type which we can call=20
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
axis first xml document will look like, and I obtained the=20
example shown on the alinda site, where:
- An ObsdataLocation structure including an ObservatoryLocation
and an ObservationCoverage defined as explained above comes first.
- This is followed by the specific characterisation structure with=20
stc structures in coverage replaced by xml references.
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
b ) no ObsDataLocation solution is proposed for Resolution, Accuracy
and Sampling which remains exatly implemented like in the original=20
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
PS: Thanks to Mireille for commenting
Francois Bonnarel Observatoire Astronomique de Strasbourg
CDS (Centre de donnees 11, rue de l'Universite
astronomiques 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
More information about the dm